• 关于 学习自动机可以做什么 的搜索结果

问题

我应该这种情况在北京能找什么样工作。? 报错

优选2 2020-06-04 21:20:26 1 浏览量 回答数 1

回答

DK8从2019年1月开始就要收费了,怎么办呢?其实这个问题本身就是有问题的,因为收费的并不是JDK8 , 而是JDK8后续的update (更新) 。什么是update? 如果你下载过JDK, 就会看到那些8u191, 8u192这样的东西,191,192就是update 的编号。这些update中通常会包含对JDK bug的fix ,或者一些功能的改变,增强, 拿update 172为例:这个update 修改了下面两个方法的文档,让文档描述和方法的实现一致:java.awt.Toolkit.getImage(URL u)java.awt.Toolkit.createimage(URL u)增加了在Windows8 及以上版中,对Swing/AWT 文本组件自动显示触摸键盘的功能36个Bug Fix假设JDK 8u192是2018年的最后一个update , 你下载并且安装了,那可以继续免费使用下去,没有任何问题。但是从2019年1月开始,如果你还想获取JDK的update , 对不起,你需要付费订阅。这个订阅服务的价格是这样的:对于PC, 每用户每月是2.5美元,对于服务器/云部署,每个processor 每月是25美元, 当然,数量多的话可以打折。Oracle 为什么要这么干呢?我推测有两个原因, 第一个原因可以理解: Oracle JDK8 2014年3月发布, 到2019年1月正式进入“End of Public Updates”, 这个版本Oracle支持了将近5年时间,一个版本的软件不可能无限期地支持下去,那样维护成本太高。第二个原因可能是没有多少人购买它的Java SE Advanced, Java SE Advanced Desktop 或者Java SE Suite, 这三个家伙是什么东西? 我们稍后解释。你也许注意到了, 我刚才再说JDK的时候,特别加上了Oracle 这个词,这是因为Java虚拟机的规范是开放的,任何人都可以去实现。老刘在2017年编程提高群第一季中,不就和大家一起实现了一个极为简单的版本吗? 当然那不能称为JVM ,只实现了对Class文件的解析,和一个能实现顺序,分支,循环,多态的简单执行引擎。其实现在的JDK提供者非常多,不像微软的.NET,独此一家,别无分号。Open JDK这个不多说,免费的开源实现,以GPL License发布,很多Linux发行版中都会包含这个Open JDK 。参与开发的大佬们有Oracle, RedHat (已被IBM收购), Azul System, IBM , Apple , SAP。Oracle JDK就是我们常说的Java JDK , 也是最常用的一个,是Oracle公司(收购了开发Java的Sun公司)对Java SE的实现。如果更详细分的话,可以分为Oracle JDK和 Oracle JRE。比如你想玩Minecraft 这样需要Java的游戏, 那只需要从java.com下载一个JRE就够了。如果你想基于Java做开发,那就需要从Oracle Technology Network(OTN)网站上下载JDK了。其他公司提供的JDK有实力的大公司,都有可能开发自己的JDK , 比如IBM ,肯定要为自家的操作系统AIX,还有z/OS开发SDK。我在IBM工作的时候,根本就没有用过Oracle JDK,公司也不让用啊。HP,SAP也有自己的JDK , 可以为自己的硬件和软件做定制。Oracle Java SE Advanced, Java SE Advanced Desktop, Java SE Suite这名字老长了,也有点费解,简单来说,这是个收费的服务, 是Oracle 为企业级用户提供的高级工具和功能,可以监控、部署、管理企业级的Java程序,与此同时,你还可以下载那些老版本的JDK及其update。换句话说,如果你购买了这个服务,自然就不用担心什么JDK update 收费的问题。但是问题在于,到底有多少公司再使用这个服务? 如果你的公司在使用,欢迎告知。所以我猜测Oracle耍了一点小手段, 以后不要这个收费的服务了,把这些高级的功能加上JDK update 打包,统一成一个新的服务,就是之前说的订阅服务。总结一下如果你的公司已经买了这个Java SE Advanced (或者 Advanced Desktop), Java SE Suite的License, 什么都不用担心,你很安全。如果你的公司正在使用Oracle JDK 8 并且还想在2019年1月之后获得那些更新和支持,你需要购买Orace 的订阅服务。如果你的公司一直在在升级你的Oracle JDK ,比如说已经升级到JDK9了,你什么服务都不用购买, 因为那个订阅服务主要解决的是老版本的Update 的问题。或者可以选择一个没有public update的Oracle JDK , 这也很常见,很多JDK已经非常稳定了, 比如Oracle JDK 7 发布日期是2011年7月, “End of Public Updates” 是2015年4月, 我估计现在还有不少公司还在使用JDK7这个已经没有public update的版本吧!如果真的出现了巨大的安全漏洞,你又没法升级JDK ,那只好去购买订阅服务去Fix了。当然,你的公司也可以选择纯开源OpenJDK。注意,我这里说的都是公司,都是商业用途,如果只是个人学习Java的话,没什么影响!

wangccsy 2019-12-02 01:47:21 0 浏览量 回答数 0

问题

【精品问答】Java技术1000问(1)

问问小秘 2019-12-01 21:57:43 34170 浏览量 回答数 10

Linux运维学习路线 20门免费课程

从事云计算运维相关工作必备技能

问题

Apache Flink常见问题汇总【精品问答】

黄一刀 2020-05-19 17:51:47 28 浏览量 回答数 1

问题

【iOS学习全家桶】190道iOS热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:23 5197 浏览量 回答数 1

回答

一 容器 在学习k8s前,首先要了解和学习容器概念和工作原理。 什么是容器? 容器是一种轻量级、可移植、自包含的软件打包技术,使应用程序可以在几乎任何地方以相同的方式运行。开发人员在自己笔记本上创建并测试好的容器,无需任何修改就能够在生产系统的虚拟机、物理服务器或公有云主机上运行。 容器的优势 容器使软件具备了超强的可移植能力。 对于开发人员 – Build Once, Run Anywhere 容器意味着环境隔离和可重复性。开发人员只需为应用创建一次运行环境,然后打包成容器便可在其他机器上运行。另外,容器环境与所在的 Host 环境是隔离的,就像虚拟机一样,但更快更简单。 对于运维人员 – Configure Once, Run Anything 只需要配置好标准的 runtime 环境,服务器就可以运行任何容器。这使得运维人员的工作变得更高效,一致和可重复。容器消除了开发、测试、生产环境的不一致性。 Docker概念 “Docker” 一词指代了多个概念,包括开源社区项目、开源项目使用的工具、主导支持此类项目的公司 Docker Inc. 以及该公司官方支持的工具。技术产品和公司使用同一名称,的确让人有点困惑。 我们来简单说明一下: IT 软件中所说的 “Docker” ,是指容器化技术,用于支持创建和使用容器。 开源 Docker 社区致力于改进这类技术,并免费提供给所有用户,使之获益。 Docker Inc. 公司凭借 Docker 社区产品起家,它主要负责提升社区版本的安全性,并将技术进步与广大技术社区分享。此外,它还专门对这些技术产品进行完善和安全固化,以服务于企业客户。 借助 Docker,您可将容器当做轻巧、模块化的虚拟机使用。同时,您还将获得高度的灵活性,从而实现对容器的高效创建、部署及复制,并能将其从一个环境顺利迁移至另一个环境,从而有助于您针对云来优化您的应用。 Docker有三大核心概念: 镜像(Image)是一个特殊的文件系统,提供容器运行时所需的程序、库、配置等,构建后不会改变 容器(Container)实质是进程,拥有自己独立的命名空间。 仓库(Repository)一个仓库可以包含多个标签(Tag),每个标签对应一个镜像 容器工作原理 Docker 技术使用 Linux 内核和内核功能(例如 Cgroups 和 namespaces)来分隔进程,以便各进程相互独立运行。这种独立性正是采用容器的目的所在;它可以独立运行多种进程、多个应用,更加充分地发挥基础设施的作用,同时保持各个独立系统的安全性。 二 Kubernetes入门知识指南 Kubernets的知识都可以在官方文档查询,网址如下: https://kubernetes.io/zh/docs/home/ Kubernetes基础知识 Kubernetes是什么? Kubernetes 是一个可移植的、可扩展的开源平台,用于管理容器化的工作负载和服务,可促进声明式配置和自动化。Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。 为什么需要 Kubernetes 容器是打包和运行应用程序的好方式。在生产环境中,您需要管理运行应用程序的容器,并确保不会停机。例如,如果一个容器发生故障,则需要启动另一个容器。如果由操作系统处理此行为,会不会更容易? Kubernetes 为您提供: 服务发现和负载均衡 Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器,如果到容器的流量很大,Kubernetes 可以负载均衡并分配网络流量,从而使部署稳定。 存储编排 Kubernetes 允许您自动挂载您选择的存储系统,例如本地存储、公共云提供商等。 自动部署和回滚 您可以使用 Kubernetes 描述已部署容器的所需状态,它可以以受控的速率将实际状态更改为所需状态。例如,您可以自动化 Kubernetes 来为您的部署创建新容器,删除现有容器并将它们的所有资源用于新容器。 自动二进制打包 Kubernetes 允许您指定每个容器所需 CPU 和内存(RAM)。当容器指定了资源请求时,Kubernetes 可以做出更好的决策来管理容器的资源。 自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器,并且在准备好服务之前不将其通告给客户端。 密钥与配置管理 Kubernetes 允许您存储和管理敏感信息,例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置,也无需在堆栈配置中暴露密钥。 Kubernetes 组件 初学者首先要了解Kubernetes的基本概念,包括master、node、pod等。 Master Master是Kubernetes集群的大脑,运行着的守护进程服务包括kube-apiserver、kube-scheduler、kube-controller-manager、etcd和Pod网络等。 kube-apiserver 主节点上负责提供 Kubernetes API 服务的组件;它是 Kubernetes 控制面的前端。 kube-apiserver 在设计上考虑了水平扩缩的需要。 换言之,通过部署多个实例可以实现扩缩。 etcd etcd 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。 您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 kube-scheduler 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。 调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。 kube-controller-manager 在主节点上运行控制器的组件。 从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。 这些控制器包括: 节点控制器(Node Controller): 负责在节点出现故障时进行通知和响应。 副本控制器(Replication Controller): 负责为系统中的每个副本控制器对象维护正确数量的 Pod。 端点控制器(Endpoints Controller): 填充端点(Endpoints)对象(即加入 Service 与 Pod)。 服务帐户和令牌控制器(Service Account & Token Controllers): 为新的命名空间创建默认帐户和 API 访问令牌. 云控制器管理器-(cloud-controller-manager) cloud-controller-manager 运行与基础云提供商交互的控制器 cloud-controller-manager 仅运行云提供商特定的控制器循环。您必须在 kube-controller-manager 中禁用这些控制器循环,您可以通过在启动 kube-controller-manager 时将 --cloud-provider 参数设置为 external 来禁用控制器循环。 cloud-controller-manager 允许云供应商的代码和 Kubernetes 代码彼此独立地发展。在以前的版本中,核心的 Kubernetes 代码依赖于特定云提供商的代码来实现功能。在将来的版本中,云供应商专有的代码应由云供应商自己维护,并与运行 Kubernetes 的云控制器管理器相关联。 以下控制器具有云提供商依赖性: 节点控制器(Node Controller): 用于检查云提供商以确定节点是否在云中停止响应后被删除 路由控制器(Route Controller): 用于在底层云基础架构中设置路由 服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器 数据卷控制器(Volume Controller): 用于创建、附加和装载卷、并与云提供商进行交互以编排卷 Node 节点组件在每个节点上运行,维护运行 Pod 并提供 Kubernetes 运行环境。 kubelet 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中。 kubelet 接收一组通过各类机制提供给它的 PodSpecs,确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。 kube-proxy kube-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。 kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。 如果有 kube-proxy 可用,它将使用操作系统数据包过滤层。否则,kube-proxy 会转发流量本身。 容器运行环境(Container Runtime) 容器运行环境是负责运行容器的软件。 Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。 Pod 在Kubernetes中,最小的管理元素不是一个个独立的容器,而是Pod。Pod是管理,创建,计划的最小单元. 一个Pod相当于一个共享context的配置组,在同一个context下,应用可能还会有独立的cgroup隔离机制,一个Pod是一个容器环境下的“逻辑主机”,它可能包含一个或者多个紧密相连的应用,这些应用可能是在同一个物理主机或虚拟机上。 Pod 的context可以理解成多个linux命名空间的联合 PID 命名空间(同一个Pod中应用可以看到其它进程) 网络 命名空间(同一个Pod的中的应用对相同的IP地址和端口有权限) IPC 命名空间(同一个Pod中的应用可以通过VPC或者POSIX进行通信) UTS 命名空间(同一个Pod中的应用共享一个主机名称) 同一个Pod中的应用可以共享磁盘,磁盘是Pod级的,应用可以通过文件系统调用。 由于docker的架构,一个Pod是由多个相关的并且共享磁盘的容器组成,Pid的命名空间共享还没有应用到Docker中 和相互独立的容器一样,Pod是一种相对短暂的存在,而不是持久存在的,正如我们在Pod的生命周期中提到的,Pod被安排到结点上,并且保持在这个节点上直到被终止(根据重启的设定)或者被删除,当一个节点死掉之后,上面的所有Pod均会被删除。特殊的Pod永远不会被转移到的其他的节点,作为替代,他们必须被replace. 三 通过kubeadm方式创建一个kubernetes 对kubernetes的概念和组件有所了解以后,就可以通过kubeadm的方式创建一个kubernetes集群。 安装前准备工作 创建虚拟机 创建至少2台虚拟机,可以在本地或者公有云。 下载部署软件 需要下载的软件包括calico、demo-images、docker-ce、kube、kube-images、kubectl、metrics-server 安装部署 具体安装过程参考官网文档: https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm/ 四 安装后的练习 安装后详读官方文档,做下面这些组件的练习操作,要达到非常熟练的程度。 Node Namespace Pod Deployment DaemonSet Service Job Static Pod ConfigMap Secrets Volume Init-containers Affinity and Anti-Affinity Monitor and logs Taints and Tolerations Cordon and Drain Backing up etcd 这些内容都非常熟练以后,基本就达到了入门的水平。

红亮 2020-03-02 11:09:17 0 浏览量 回答数 0

问题

【Java学习全家桶】1460道Java热门问题,阿里百位技术专家答疑解惑

管理贝贝 2019-12-01 20:07:15 27612 浏览量 回答数 19

问题

支付宝小程序云训练营优秀学员提问来啦

问问小秘 2020-06-15 15:57:38 159 浏览量 回答数 1

问题

报检员及相关岗位工资待遇介绍

a7713092 2019-12-01 20:15:40 7985 浏览量 回答数 0

回答

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念,不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持,这里可能会有疑惑,前面我们在介绍MongoDB时,说MongoDB是一个NoSQL数据库,不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事,如果你已经非常了解关系型数据库的事务,通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID? 1)MongoDB对原子性(Atomicity)的支持 原子性在Mongodb中到底是一个什么概念呢?为什么说支持但又说Mongodb的原子性是单行/文档级原子性,这里提供了一个MongoDB更新语句样例,如下图: MongoDB是如何实现事务的ACID? 更新“username”等于“tj.tang”的文档,更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新,这个概念在MySQL中可能你没有考虑过,但在MongoDB中由于文档可以嵌套子文档可以很复杂,所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的,如下情况: MongoDB是如何实现事务的ACID? MongoDB更新条件为工资小于50万的人都把工资调整为50万,这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时,出现宕机,服务器重启之后是无法像关系型数据库那样做到数据回滚的,也就是说处理这种多文档关系型数据库事务的支持,但MongoDB不支持。那么怎么解决Mongodb这个问题呢?可以通过建模,MongoDB不是范式而是反范式的设计,通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2)MongoDB对一致性(consistency)的支持 对于数据一致性来说,传统数据库(单机)跟分布式数据库(MongoDB)对于数据一致性是不太一样的,怎么理解呢?如下图: MongoDB是如何实现事务的ACID? 对于传统型数据库来说,数据一致性主要是在单机上,单机的问题主要是数据进来时的规则检验,数据不能被破坏掉。而在分布式数据库上,因为他们都是多节点分布式的,我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的,MongoDB支持强一致性或最终一致性(弱一致性),MongoDB的数据一致性也叫可调一致性,什么意思呢?如下图: MongoDB是如何实现事务的ACID? MongoDB的可调一致性,也就是可以自由选择强一致性或最终一致性,如果你的应用场景是前台的方式可以选择强一致性,如果你的应用场景是后台的方式(如报表)可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载,下面我们来看看这样做引发的一个问题:保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难,同步节点可能会故障,甚至会无法恢复,网络可能会有延迟或者丢包,网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中,通常有两个层次的一致性:第一种是强一致性,既集群中的所有机器状态同步保持一致。第二种是最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。我们先来讲一下,在分布式集群中,为什么最终一致性通常是更合理的选择,然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢?其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出,称为CAP理论,尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳: 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性(P):集群中的某些节点在无法联系后,集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。 要保证数据强一致性,最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功,也就是同步概念。而这时如果某个结点出现故障,那么写操作就成功不了了,需要一直等到这个节点恢复。也就是说,如果要保证强一致性,那么就无法提供7×24的高可用性。 而要保证可用性的话,就意味着节点在响应请求时,不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功,这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然,事实上还有其它的选择,比如在Yahoo的PNUTS中,采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现,所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证,要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的,但是作为一个整体,当客户端发起对某个key的数据请求时,整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中,一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时,需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系:R+W>N 下面举个实在的例子。比如我们设定N=3(数据会备份到A、B、C三个结点)。比如值 employee30:salary 当前的值是20000,我们想将其修改为30000。我们设定W=2,下面我们会对A、B、C三个节点发起写操作(employee30:salary, 30000),当A、B两个节点返回写成功后,协调器就会返回给客户端说写成功了。至于节点C,我们可以假设它从来没有收到这个写请求,他保存的依然是20000那个值。之后,当一个协调器执行一个对employee30:salary的读操作时,他还是会发三个请求给A、B、C三个节点: 如果设定R=1,那么当C节点先返回了20000这个值时,那我们客户端实际得到了一个错误的值。 如果设定R=2,则当协调器收到20000和30000两个值时,它会发现数据不太正确,并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性,在上面的应用场景中,我们需要设定R=2,W=2 如果写操作不能收到W个节点的成功返回,或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败,或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定,会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功,既W=N,那么只要有一个备份节点故障,写操作就失败了。一般设定是R+W = N+1,这是保证强一致性的最小设定了。一些强一致性的系统设定W=N,R=1,这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前,写操作是不会返回成功的。也就是说它的W=N,而读操作只需要读到一个值即可,也就是说它R=1。为了不至于让写操作太慢,对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后,会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort,Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W 3)MongoDB对隔离性(isolation)的支持 在关系型数据库中,SQL2定义了四种隔离级别,分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准,比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改,哪些在事务内核事务外是可见的,哪些是不可见的。为了尽可能减少事务间的影响,事务隔离级别越高安全性越好但是并发就越差;事务隔离级别越低,事务请求的锁越少,或者保持锁的时间就越短,这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID? MongoDB在3.2之前使用的是“读未提交”,这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题: READ-UNCOMMITTED(读尚未提交的数据) 在这个级别,一个事务的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为“脏读(dirty read)”。这个级别会导致很多问题,从性能上来说,READ UNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。 READ-COMMITTED(读已提交的数据) 在这个级别,能满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读(non-repeatable read)”,因为两次执行同样的查询,可能会得到不一样的结果。 REPEATABLE-READ(可重复读) 在这个级别,保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC(multiversion concurrency control)解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息,也就是说这些数据数据库当前状态,这在一些对于数据的时效特别敏感的业务中,就很可能会出问题。 SERIALIZABLE(串行化) 在这个级别,它通过强制事务串行执行,避免了前面说的一系列问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别,主要应用在InnoDB存储引擎的分布式事务中。 4)MongoDB对持久性(durability)的支持 对于数据持久性来说,在传统数据库中(单机)的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题,因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID? 从上图可以看出,MongoDB同样是使用数据进来先写日志(日志刷盘的速度是非常快)然后在写入到数据库中的这种方式来保证数据的持久性,如果出现服务器宕机,当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging(预写日志系统),而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好,MongoDB的复制默认节点就是三节点以上的复制集群,当数据到达主节点之后会马上同步到从节点上去。

景凌凯 2019-12-02 02:05:12 0 浏览量 回答数 0

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C

auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

问题

浅谈GPU虚拟化技术(三)GPU SRIOV及vGPU调度

福利达人 2019-12-01 22:04:32 4047 浏览量 回答数 0

回答

1、对不合理权限说“NO!” 发现了吗?许多应用在下载完成后首次启动过程中,都会弹出“三板斧”——获取地理位置信息、获取手机通讯录、获取存储权限。 令人不解的是,娱乐影音类应用获取通讯录信息想做什么?教育学习类应用又为什么要获取相册信息?应用真的有与这些权限对应的使用场景吗?遇到这样的问题我们应该如何应对呢? 华为软件安全工程部的专家称:用户对不合理权限应该果断说No!如果应用权限申请遭到拒绝而无法启用,则可以怀疑该应用存在恶意行为,可以直接对其进行卸载。 2、慎用公共WiFi 在公共场所,“蹭网”已经成为一种习惯,但在早些年的央视3·15晚会上就已经演示过黑客如何利用虚假WiFi盗取晚会现场观众手机系统、品牌型号、自拍照片、邮箱帐号密码等各类隐私数据。 那么,在公共区域使用公共WiFi该注意些什么呢? (1)手机用户连接免费WiFi可先通过一些可靠的手机管家类应用进行网络安全检测,对所链接的免费WiFi进行“DNS劫持”、“ARP欺骗攻击”、“虚假钓鱼WiFi”等多项安全检测,确保接入的免费WiFi安全无风险; (2)在公共场合使用免费WiFi时,不要登录没有密码的WiFi; (3)尽量不要在公共WiFi下网购或登录网银、第三方支付平台,防止用户个人信息、重要账号、密码泄露等。 (4)不使用一些破解WiFi密码的手机工具,谨防被此类工具盗取隐私。 3、安装靠谱的安全防护类应用 选择一款知名、靠谱的安全防护类应用安装在手机上,但如果你的手机本身自带安全防护类软件,则可以不再另外下载应用。 手机拥有一款这样的软件,如同穿上了一套铠甲,好处颇多: (1)能有效拦截恶意软件的攻击; (2)能很好的保护手机隐私和网络账号的财产安全; (3)能自动识别诈骗、骚扰短信和电话,有效防止被骚扰; (4)可以限制后台自启和无故后台唤醒; (5)还能随时监控手机流量。 该类应用请尽量保持开启状态;用户需定期对手机查毒、杀毒;一旦手机发现了木马病毒,不要进行其他操作,一定第一时间对病毒进行查杀。 4、开启浏览器无痕浏览模式 在使用手机浏览器查询、阅览网页时,尽量启用“无痕浏览”,这样,浏览器便不会将访问过的任何网站添加到历史记录中,也不会记录用户曾经搜索的内容,更不会保存用户在线填写的任何表单信息,以保护个人隐私。 5、开启安全输入功能 如果您是华为手机用户,在输入密码的场景下,可以使用EMUI提供的安全输入功能。 在【手机设置-系统-语言和输入法中开启“安全输入”】即可,在这种场景下,当用户输入密码,手机会自动切换到系统提供的安全输入法。 安全输入法不会联想和记忆用户以往的输入,也不会收集用户的输入信息。在使用安全输入法的同时,系统会禁用后台截屏录屏功能,防止密码被非法截取,提升安全性。 但需要注意的是,部分应用会使用自己定制开发的输入方式,这时安全输入法可能不会生效。 6选择带有绿色应用标记的应用优先下载 在华为应用市场上,不难发现,有的应用名称后标记有一个绿色盾形标志(如下图),这类应用被称为“绿色应用”。 那么带有标记的绿色应用与普通应用之间有什么区别呢? 原来,这个绿色盾形标志是符合安卓绿色联盟应用体验标准的应用标识,这项标准涉及兼容性、稳定性、功耗、性能和安全五大方面,并在应用权限申请等与用户隐私安全相关的项目上着重发力,对应用行为进行了明确要求和严格限制。 华为应用市场率先根据安卓绿色联盟发布的最新标准——《安卓绿色联盟应用体验标准2.0》为应用打标上架进行检测,拥有这项标志,才意味着这是一款能够为用户带来放心舒心的体验、在品质和体验上都更胜一筹的“绿色应用”! 所以,我们在同类应用选择下载时,一定要认准“绿色盾形”标志,优先下载“绿色应用”。 上面的6大招式你都学会了吗?赶紧动手试试吧!这个3·15,让我们一起,手机天天安全、生活日日轻松

游客6j3ztv6vbre5k 2020-01-07 15:09:47 0 浏览量 回答数 0

问题

Docker怎么入门

boxti 2019-12-01 21:49:35 2878 浏览量 回答数 0

回答

DevOps 这个概念最早是在 2007 年提出的,那时云计算基础设施的概念也才刚刚提出没多久,而随着互联网的逐渐普及,应用软件的需求爆发式增长,软件开发的理念也逐渐从瀑布模型(waterfall)转向敏捷开发(agile)。传统的软件交付模式(应用开发人员专注于软件开发、IT 运维人员负责将软件部署到服务器运行),再也无法满足互联网软件快速迭代的需求。于是,DevOps 作为一种打破研发和运维之间隔阂、加快软件交付流程、提高软件交付质量的文化理念和最佳实践 逐渐普及至今。 DevOps 的现状 DevOps 的流行得益于业界对于应用软件敏捷开发、高质量交付的诉求,所以为开发和运维开辟了一块“公共的空间”,让双方可以在这里紧密合作。那时软件研发依旧属于一个新兴行业,人们习惯于向成熟的制造业学习,制造业解决大规模生产的方式,就是构建流水线,通过流水线规范化每个步骤对接的内容,而流水线上的工人们则只需要各司其职,快速熟练的完成自己这部分生产内容。 所以,DevOps 借鉴了制造业的经验,开始构建持续集成 / 持续交付(CI/CD)的流水线,催生出了一系列自动化 / 半自动化工具(如 puppet、chef、ansible 等),结合编写脚本的可扩展能力,将研发和运维的大量操作规范化,从而达到彼此协作的目标。但是最终还是要有人投入到这些工具的构建中,于是就出现了 DevOps 团队。DevOps 团队构建的工具和平台,帮助研发更容易地接近生产环境,让研发在持续集成、持续交付的过程中可以一键部署、快速试错,从而很大程度提前暴露和避免了软件在实际运行过程中的问题。 从本质上讲,DevOps 是为运维服务的。 它把生产环境的运维流程通过自动化的工具提供出来了,屏蔽了基础设施细节,同时让软件本身的问题更容易暴露,从而把这些问题尽量提前交给研发去解决。这些,其实都是在帮助运维减轻负担。 这一套模式在一开始运转良好,但是问题也随着时间的推移慢慢暴露出来了。DevOps 本身不为企业带来直接的利润,也不增加产品的功能,它们是企业的成本中心,所以许多企业不愿意为 DevOps 投入太多的成本。久而久之,DevOps 的能力便无法与研发人员增长的需求所匹配,不愿意继续伴随着云和开源社区的发展向前演进,反而成为软件研发的瓶颈。试想一下,有多少大公司的技术人员,对自己公司里的“研发效能”工具表示满意呢? 云计算的普及 聪明的企业总能从自己的需求中发现业界共有的需求,AWS 便是这么诞生的,他们早在 2006 年便首次把软件部署需要的网络、计算、存储等基础设施当做服务提供给用户,允许任何人在不购买服务器等物理硬件的情况下构建互联网应用程序,规模化使得整体的成本比用户自建更低。而云计算 IaaS、PaaS、SaaS 的概念也正是在那一年开始逐渐清晰的。 云计算的初期,用户主要使用的是 IaaS 服务,如虚拟机、存储等,使用云计算服务的企业依旧需要运维来管理这一类基础设施,只是运维管理的对象从物理机切换到虚拟机而已,并没有太本质的区别。 而随着云计算的快速发展,云的能力不断补充、增强,渐渐将原先由运维提供的方方面面的能力都转换成为了云上的服务,这其中自然包含了管理软件完整生命周期的各类服务,从代码托管、持续集成、持续交付,到监控、报警、自动扩缩容等一系列的能力,均能在云上找到对应的服务。品类之多、数量之巨,令人瞠目结舌。 但是 DevOps 依然有着用武之地。云的对接难度实在太大了,涉及到的云服务又多,不同云厂商提供的服务还不统一,为了使用云上的产品不得不投入大量的时间学习,而为了防止云厂商的绑定又不得不做多厂商的适配,DevOps 依旧需要像过去一样为开发屏蔽实际环境的复杂性,只不过这次他们要负责管理的基础设施变成了云资源。 改变一切的 Kubernetes Kubernetes 的本质是现代应用基础设施,它关注如何将应用与“云”天然地集成在一起,将“云”的最大价值发挥出来。Kubernetes 强调让基础设施能更好的配合应用、以更高效的方式为应用“输送”基础设施能力,而不是反之。在这个过程中,Kubernetes 、Docker、Operator 等在云原生生态中起到了关键作用的开源项目,正在在把应用管理与交付推上一个跟以前完全不一样的境况:Kubernetes 的使用者只通过声明式的方式描述自己应用的终态是什么,然后一切就结束了。Kubernetes 会处理后面的所有事情。 这也是为什么 Kubernetes 非常强调声明式 API。通过这种方式,Kubernetes 本身接入的基础设施能力越强,Kubernetes 的使用者能够声明的终态就越丰富,他的职责也就约单纯。现在,我们不仅能够通过 Kubernetes 声明应用的运行终态,比如;“这个应用需要 10 个实例”,我们还能够声明应用的很多运维终态,比如:“这个应用使用金丝雀发布策略进行升级”,以及 “当它的 CPU 使用量大于 50% 时,请自动扩展 2 个实例出来”。 这就让传统的 DevOps 工具和团队受到了挑战:如果一个业务研发自己只需要通过声明式 API 声明他的应用的所有终态甚至包括完整的 SLA,后面的一切就都会有 Kubernetes 来自动的搞定,那么他还有什么理由去对接和学习各式各样的 DevOps 流水线呢? 换句话说,长久以来,DevOps 实际上是在充当研发与基础设施之间的那一层“胶水”。而现在,Kubernetes 通过它极具生命力的声明式 API 和无限接入的应用基础设施能力,正在完美的扮演这个“胶水层”的作用。这也提醒了我们,上一个正在被 Kubernetes 体系强烈挑战的“胶水层”,其实叫做“传统中间件”:它正遭受到 Service Mesh 的巨大冲击。 DevOps 会消失吗? 近几年,Kubernetes 项目经常被描述成 DevOps 的“最佳拍档”。类似的观点认为, Kubernetes 跟 Docker 一样,解决的是软件运行时的问题。这意味着 Kubernetes 更像一种“时髦”的 IaaS,只不过运行时从虚拟机变成了容器。所以,只要能够将现有 DevOps 思想和流程对接到 Kubernetes 上来,就可以享受到容器技术带来的轻量级与弹性。这对于提倡“敏捷”的 DevOps 来说,显然是最好的组合。 不过,至少目前看来,Kubernetes 的发展路径并不是一个类 IaaS 的角色。它虽然关注接入底层的基础设施能力,但它本身却又不是基础设施能力的提供方。而且,相比于软件运行时,Kubernetes 似乎更关心软件的生命周期和状态流转。不仅如此,它还提供了一种叫做“控制器模型”的机制来将软件的实际状态与期望状态不断逼近,这显然都已经超出了一个“软件运行时”的范畴。 Kubernetes 项目对应用本身的“额外关注”,让它与一个类 IaaS 基础设施有着明显的区别,也让它“胶水”的定位更加明显。而如果 Kubernetes 的能力足够强大,那么作为研发与基础设施之间现有的“胶水层”, DevOps 是否还有必要存在?在所谓的云原生时代,应用研发与交付是不是真的会走向“一次声明”就可以“撒手不管”,从而让 DevOps 彻底消失呢? 不过,至少目前看来,Kubernetes 项目距离这个愿景,还有不少困难需要克服。 “Platform for Platform” API 的局限性 Kubernetes 是一个典型的 “Platform for Platform”项目,所以它的 API,距离纯研发视角还是非常遥远的。就比如一个 Deployment 对象,就既包括了研发侧关心的镜像,也包括了基础设施侧的资源配置,甚至是容器安全配置。此外, Kubernetes API 并没有提供出对“运维能力”的描述与定义方式,这也使得声明之后的“撒手不管”变得遥不可及。这也是为什么目前 DevOps 依然被需要的原因:Kubernetes 的大多数字段,还是必须经过研发和运维共同协作的流程来进行填充。 无法对更多的云资源进行描述 K8s 的原生 API 只包含了云资源的很少一部分,比如用 PV/PVC 表达存储,用 Ingress 表达负载均衡,但这对于一个完全声明式的应用描述来说是完全不够的。比如,研发希望在 K8s 上找到一个概念来表达数据库、VPC、消息队列等需求的时候,就会感到非常困惑。而现有的所有方案则完全依赖于云厂商的实现从而带来了新的 vendor lock-in 困惑。 Operator 体系缺乏互操作性 Kubernetes 的 Operator 机制是这个项目的能力能够无限增长的公开秘密。但令人遗憾的是,目前所有 Operator 之间的关系,就像是一个又一个的烟囱,互相之间没有任何交互与协作的可能。比如,我们把云上的 RDS 通过 CRD 和 Operator 扩展到了 K8s 声明式 API 的体系中,但是当第三方希望写一个定时备份 RDS 持久化文件的 CRD Operator 去配合的时候,却往往无从下手。这就又需要 DevOps 的体系介入来解决问题。 未来? 显然,现在的 Kubernetes 项目,依然需要借助 DevOps 体系来真正完成软件的高效迭代与交付工作。这是不可避免的:尽管 Kubernetes 声称自己是“以应用为中心”的基础设施,但它作为一个从 Google Borg 衍生出来的系统级项目,其本身的设计和工作层次还是更多的基础设施领域徘徊。但另一方面,我们绝不可否认的是,Kubernetes 在它的关键路径上,始终保持着对研发侧 “NoOps” 的追求。这种渴望,从它第一天提出“声明式应用管理”理论的时候就已经“昭然若揭”,而 CRD 和 Operator 体系的建立,更让这种应用级别的关心终于有了落地的机会。我们已经看到很多 DevOps 流程正在“下沉”为 Kubernetes 里的声明式对象与控制循环,比如 Tekton CD 项目。 如果 Kubernetes 的未来是 100% 的声明式应用管理,那么我们有理由相信 DevOps 最终会从技术领域消失然后彻底蜕变成一种文化。毕竟,那个时候的运维工程师,可能都会成为 Kubernetes Controller/Operator 的编写者或者设计者。而研发呢?他们可能根本不会知道原来 Kubernetes 这个东西曾经如此显赫的存在过。

有只黑白猫 2020-01-07 11:35:38 0 浏览量 回答数 0

回答

一、 Afinal官方介绍:Afinal是一个Android的ioc,orm框架,内置了四大模块功能:FinalAcitivity,FinalBitmap,FinalDb,FinalHttp。通过finalActivity,我们可以通过注解的方式进行绑定ui和事件。通过finalBitmap,我们可以方便的加载bitmap图片,而无需考虑oom等问题。通过finalDB模块,我们一行代码就可以对android的sqlite数据库进行增删改查。通过FinalHttp模块,我们可以以ajax形式请求http数据。详情请通过以下网址查看。Afinal 是一个android的sqlite orm 和 ioc 框架。同时封装了android中的http框架,使其更加简单易用;使用finalBitmap,无需考虑bitmap在android中加载的时候oom的问题和快速滑动的时候图片加载位置错位等问题。Afinal的宗旨是简洁,快速。约定大于配置的方式。尽量一行代码完成所有事情。项目地址:https://github.com/yangfuhai/afinal功能:一个android的ioc,orm框架,内置了四大模块功能:FinalAcitivity,FinalBitmap,FinalDb,FinalHttp。通过finalActivity,我们可以通过注解的方式进行绑定ui和事件。通过finalBitmap,我们可以方便的加载bitmap图片,而无需考虑oom等问题。通过finalDB模块,我们一行代码就可以对android的sqlite数据库进行增删改查。通过FinalHttp模块,我们可以以ajax形式请求http数据。优点:功能比较全面,文档完善,代码效率比较高。缺点:没有项目demo,框架的时间比较久,代码冗余比较多(这也是无可避免的),文档比较老跟不上代码更新进度。(这个评价是其他高人评的,他自己也有写了框架。我个人觉得以前Afinal算是经典了 用的人多)。二、 xUtilsGit地址:https://github.com/wyouflf/xUtilsxUtils:可以说是Afinal的升级版。xUtils 包含了很多实用的android工具。xUtils 支持大文件上传,更全面的http请求协议支持(10种谓词),拥有更加灵活的ORM,更多的事件注解支持且不受混淆影响...xUitls 最低兼容android 2.2 (api level 8)三、 ThinkAndroid项目地址:https://github.com/white-cat/ThinkAndroid官方介绍:ThinkAndroid是一个免费的开源的、简易的、遵循Apache2开源协议发布的Android开发框架,其开发宗旨是简单、快速的进行Android应用程序的开发,包含Android mvc、简易sqlite orm、ioc模块、封装Android httpclitent的http模块,具有快速构建文件缓存功能,无需考虑缓存文件的格式,都可以非常轻松的实现缓存,它还基于文件缓存模块实现了图片缓存功能,在android中加载的图片的时候,对oom的问题,和对加载图片错位的问题都轻易解决。他还包括了一个手机开发中经常应用的实用工具类,如日志管理,配置文件管理,android下载器模块,网络切换检测等等工具优点:功能看起来比较完善。个人觉得名字起的好。缺点:从2013年就停止维护了,没有项目文档。四、 LoonAndroid官方介绍:如果你想看ui方面的东西,这里没有,想要看牛逼的效果这里也没有。这只是纯实现功能的框架,它的目标是节省代码量,降低耦合,让代码层次看起来更清晰。整个框架一部分是网上的,一部分是我改的,为了适应我的编码习惯,还有一部分像orm完全是网上的组件。在此感谢那些朋友们。 整个框架式的初衷是为了偷懒,之前都是一个功能一个jar,做项目的时候拉进去,这样对于我来说依然还是比较麻烦。最后就导致我把所有的jar做成了一个工具集合包。 有很多框架都含有这个工具集合里的功能,这些不一定都好用,因为这是根据我个人使用喜欢来实现的,如果你们有自己的想法,可以自己把架包解压了以后,源码拉出来改动下。 目前很多框架都用到了注解,除了androidannotations没有入侵我们应用的代码以外,其他的基本上都有,要么是必须继承框架里面的activity,要么是必须在activity的oncreat里面调用某个方法。 整个框架式不同于androidannotations,Roboguice等ioc框架,这是一个类似spring的实现方式。在整应用的生命周期中找到切入点,然后对activity的生命周期进行拦截,然后插入自己的功能。开源地址:https://github.com/gdpancheng/LoonAndroid功能:1自动注入框架(只需要继承框架内的application既可)2图片加载框架(多重缓存,自动回收,最大限度保证内存的安全性)3网络请求模块(继承了基本上现在所有的http请求)4 eventbus(集成一个开源的框架)5验证框架(集成开源框架)6 json解析(支持解析成集合或者对象)7 数据库(不知道是哪位写的 忘记了)8 多线程断点下载(自动判断是否支持多线程,判断是否是重定向)9 自动更新模块10 一系列工具类有点:功能多缺点:文档方面五、 KJFrameForAndroid项目地址:https://github.com/kymjs/KJFrameForAndroid官方介绍:KJFrameForAndroid 又叫KJLibrary,是一个android的orm 和 ioc 框架。同时封装了android中的Bitmap与Http操作的框架,使其更加简单易用;KJFrameForAndroid的设计思想是通过封装Android原生SDK中复杂的复杂操作而达到简化Android应用级开发,最终实现快速而又安全的开发APP。我们提倡用最少的代码,完成最多的操作,用最高的效率,完成最复杂的功能。功能:一个android的orm 和 ioc 框架。同时封装了android中的Bitmap与Http操作的框架,使其更加简单易用; KJFrameForAndroid开发框架的设计思想是通过封装Android原生SDK中复杂的复杂操作而达到简化Android应用级开发,最终实现快速而又安全的开发APP。总共分为五大模块:UILibrary,UtilsLibrary,HttpLibrary,BitmapLibrary,DBLibrary。优点:功能比较全面,代码效率很高,文档完善,有项目demo,出来的比较晚借鉴了很多大型框架经验。缺点:项目文档是html页面,查看起来很不方便,项目交流平台没多少人说话(难道大神都是不说话的?)(这两个评价是KJFrameForAndroid的作者对自己的评价,个人觉得作者是个天才。他的评价可能刚写完网上发布后写的。我在给他更新评价。因为现在已经过去了几个月一直在时不时更新。功能很全,项目文档也很全面,而且代码里注释最多 这方面这个很难得。交流平台人很多挺热闹,作者希望更热闹这样框架越来越完善。对于初学者希望看到Demo更完善)六、 dhroid官方介绍:dhroid 是基于android 平台, 极速开发框架,其核心设计目标是开发迅速、代码量少、学习简单、功能强大、轻量级、易扩展.使你更快,更好的开发商业级别应用开源地址: http://git.oschina.net/tengzhinei/dhroid功能:1.Ioc容器: (用过spring的都知道)视图注入,对象注入,接口注入,解决类依赖关系2.Eventbus: android平台事件总线框架,独创延时事件,事件管理轻松3.Dhnet: 网络http请求的解决方案,使用简单,减少代码,自带多种网络访问缓存策略4.adapter模块: 数据绑定轻松,不用写多余的adapter,天生网络支持(一行代码搞定加载,刷新问题)5.DhDb: android中sqlite的最轻量orm框架(增删改查轻松搞定)6.Perference: android自带Perference 升级版,让你的Perference更强大,更方便工具集合 JSONUtil(安全处理json),ViewUtil(数据绑定更快) ThreadWorker(异步任务工具)...优点:功能全面,有demo,作者也是为公司开发的框架。缺点:文档方面现在不是很好,就eoe上的那些。七、 SmartAndroid项目地址:http://www.aplesson.com/smartAndroid/demos官方介绍:SmartAndroid是一套给 Android开发者使用的应用程序开发框架和工具包。它提供一套丰富的标准库以及简单的接口和逻辑结构,其目的是使开发人员更快速地进行项目开发。使用 SmartAndroid可以减少代码的编写量,并将你的精力投入到项目的创造性开发上。功能:SmartAndroid 拥有全范围的类库,可以完成大多数通常需要的APP开发任务,包括: 异步网络操作相关所有功能、强大的图片处理操作、轻量级ORM数据库Sqlite库、zip操作 、动画特效、Html等解析采集、事件总线EventBus/Otto、Gson(Json)、AQuery、主流所有UI控件(例如:ActionbarSherlock,SlidingMenu,BottomView,Actionbar,DragListView等10多种UI库)等。优点:功能非常全,超出你索要、文档完善(作者很全面,官方网站是web响应式网站,框架里功能有UI各种特效应该最全了,一直更新中)缺点:jar包大点?(功能多不可避免,不是问题),在线文档(随响应式的手机访问也方便,但是网速慢就不好了,页面打开不是很流畅)八、 andBase官方介绍:andbase是为Android开发者量身打造的一款开源类库产品开源地址:https://code.jd.com/zhaoqp2010_m/andbase功能:1.andbase中包含了大量的开发常用手段。如网络下载,多线程与线程池的管理,数据库ORM,图片缓存管理,图片文件下载上传,Http请求工具,常用工具类(字符串,日期,文件处理,图片处理工具类等),能够使您的应用在团队开发中减少冗余代码,很大的提高了代码的维护性与开发高效性,能很好的规避由于开发疏忽而导致常犯的错误。2.andbase封装了大量的常用控件。如list分页,下拉刷新,图片轮播,表格,多线程下载器,侧边栏,图片上传,轮子选择,图表,Tab滑动,日历选择器等。3.强大的AbActivity,您没有理由不继承它。继承它你能够获得一个简单强大可设置的操作栏,以及一系列的简单调用,如弹出框,提示框,进度框,副操作栏等。4.提供效率较高图片缓存管理策略,使内存大幅度节省,利用率提高,效率提高。程序中要管理大量的图片资源,andbase提供简单的方法,几步完成下载与显示,并支持缩放,裁剪,缓存功能。5.封装了大量常见工具类。包括日期,字符,文件,图片等各种处理函数,多而全。6.用andbase大量减少handler的使用,而采用回调函数,代码更整洁。handler会产生大量代码,并且不好维护,andbase对handler进行了封装。7.简单轻量支持注解自动建表的ORM框架(支持一/多对多的关联操作)。写sql,建表,工作量大,andbase提供更傻瓜异步增删改查工具类。8.异步请求http框架,网络请求标准化,支持文件上传下载,get,post,进度显示。包含了异步与http请求的工具类,实用。9.热情的支持群体。优点:功能很全,demo做的好 、API文档完善、接近完美缺点:希望文档更详细些。九、 AndroidAnnotations项目地址:https://github.com/excilys/androidannotations功能:完全注解框架,一切皆为注解:声明控件,绑定控件,设置监听,setcontentview,长按事件,异步线程,全部通过注解实现。优点:完全的注解,使开发起来更加便利,程序员写的代码也更少。缺点:文档是全英文的加上功能比较少没有具体研究,由于一切都是注解,感觉效率不高,不过根据官方介绍说并不是使用的反射加载,所以效率比一般注解高很多。十、 volley项目地址: https://github.com/smanikandan14/Volley-demo功能:Volley是Android平台上的网络通信库,能使网络通信更快,更简单,更健壮异步加载网络图片、网络数据优点:Google官方推荐,请看去年的开发者大会介绍。缺点:功能比较少,只有网络数据加载和网络图片加载十一、 android-async-http项目地址:https://github.com/loopj/android-async-http文档介绍:http://loopj.com/android-async-http/ (1) 在匿名回调中处理请求结果 (2) 在UI线程外进行http请求 (3) 文件断点上传 (4) 智能重试 (5) 默认gzip压缩 (6) 支持解析成Json格式 (7) 可将Cookies持久化到SharedPreferences 有点:很简单很实用缺点:功能比较少, (只是针对的功能不是什么缺点)最后来个总结吧: 以上的开发框架网上都可以下载源码,也有demo实例的。当然我没分析和对比框架的效率性能,但是都非常实用,其作者大部分是个人,都是些牛人或天才。你可以直接使用,也可以把有用跳出来用,至少有很多使用工具。如果有发现Bug,作者希望把bug交给他。 Afinal 和 xUtils简单实用但是demo和更新的问题。 KJFrameForAndroid 算是新出的,功能也多,效率也应该好,代码也注释多 用起来也很方便。Dhroid 作者自己公司的框架,也可以直接请教。SmartAndroid 强劲的框架功能俱全。andBase 出来早各个方面算是完整的吧。转自:http://blog.csdn.net/buddyuu/article/details/40503471

元芳啊 2019-12-02 00:55:54 0 浏览量 回答数 0

回答

【徐寅-南京大学- 阿里实习心得】 现在的心情非常复杂,因为小姐姐说看中了我的研究成果才让我参加这个实习心得分享的,但是我环顾四周只有我一个人的成果还没有发表出来!有一种青铜误入王者局的错乱感,不过在小姐姐大大的“不准退出”四个字面前,还得强撑着分享一点我的搬砖经历。 技术落地 来到菜鸟实习给了我在学校科研完全不一样的体验。这点感觉大家应该都深有体会。在学校是设计一个漂亮的齿轮,而在公司需要把这个齿轮安装到巨大的机器上,还要保证能够正常运行。结果就是来了菜鸟以后我花了很多时间在算法无关的事情上,比如说上线代码的编写和调试,比如说符合rtp接口的模型的训练和装载,比如和仓库运维人员的沟(扯)通(皮),争取更多的流量给我们的算法测试等等。在仓库这种大规模的现实复杂环境进行落地,为了数据的准确,只有到仓库实地考察测算以后你才能安下心来。 快乐工作 在我来阿里之前,关于阿里只听过马老师的“福报论”,因此以为可能会是一个从黑夜干到黑夜的血汗工厂。不过没想到实际上是10-6-5的八小时工作制,马老师的“福报论”只是鼓励大家要多奋斗而已。虽然大家都习惯了自愿加班到9点,不过有学长借的工牌,能够每天吃20块的夜宵。不过要是夜宵的种类能更丰富一点就好了,那种精致的小蛋糕总是可遇不可求。 回想一下,在杭州已经去过不少次西湖了,不过都是团建的活动。菜鸟ai部的团建应该是我最喜欢的团建类型了。在西湖的茶园美景边上,享受着清风和茶香,大家悠闲地玩着桌游或者聊天,让我这个ktv残疾人终于享受到了团建的快乐。 希望成果没事 半年多的实习一共攒出来两个工作,一个是偏理论的强化学习多目标环境自动分解技术,另一个是强化学习应用在仓库进行拣选单全局优化的工作,目前即将投稿Neurips20和NMI,希望能有一个好结果吧! 【杨亚涛-中山大学- 我的RI实习经历和感受】 现在回想还能非常清晰的记得当初实习第一天的那个场景,经过一系列入职流程之后,在杭州那高温的鬼天气下,我和师兄搬着台式机从四号楼走到了七号楼。由于我属于那种营养过剩的体型,机器搬到七号楼时,我的整个上衣都感觉被汗打湿了。进入大厅中,好不容易从被高温天气折磨的懵逼的状态下解脱出来。我又进入到了一个新的懵逼阶段。师兄带着我掠过了无数个工位之后转身进入了最角落的一个小房间。嗯,没错,我在实习的第一天就被拉进阿里特色的双十一项目室了。环顾着周围的大佬,心中还是有些胆怯。懵逼的在各位大佬面前做完自我介绍。 之后,在师兄的帮助下装完各种实验环境。师兄带着我到了走廊并在玻璃上描绘着大家做的事情以及我要做的事情。呃。。。懵逼过后的我开始接触了一个全新的令我再次懵逼的研究内容-Query改写。简单来说就是淘宝的用户常常输入的Query和商品标题描述之间会存在GAP。如何消除这个GAP是需要Query改写来做的。举个例子,用户搜索“大容量冰箱”,很多相关的商品标题不会用“大容量”来描述。会用多少升来写。单用用户输入的Query进行商品召回,会有很多相关产品会被忽略,并且还有可能面临不相关产品被召回展示。为了增加相关商品召回以及准确度,就需要对用户输入的原始Query进行改写。呃。。。听完师兄的介绍之后,师兄说希望能在双十一检验下效果。那个时候的感觉就是,哪有时间懵逼啊,抓紧做吧。 接下来,每天就在师兄发资料、阅读资料、实验、分析数据中度过。实验结果逐渐从坏变成了好。不过最后还是很遗憾没有在双十一时候检测模型效果。不过,在双十一之后师兄上线测试效果。还是有明显的改进的。在看到师兄周报中线上指标的提升之后,我的内心不由的升起了些许成就感。之后就开始了写论文投论文。经过一轮SIGIR的Reject之后,该工作被CIKM接收。总体谈下实习的感受。在来到阿里做RI实习之前,在实验室都是做一些偏向于研究性质的工作。呃。。。简单来说就是做了很多脱离应用场景的的工作。就是为了发论文而发论文。在阿里做的都是实用的、能够迅速看到实际效果的工作。既能够发论文,自己每次打开淘宝搜索时又能获得满满的成就感。 【张心怡-北京大学- 在阿里数据库科研团队实习是种怎样的体验?】 作者简介: 张心怡,北京大学前沿交叉研究院研究生,中国人民大学信息学院本科生。从18年底开始在POLARDB-X团队智能数据库组的实习,现已在阿里度过了一年多的时光。 心怡说,对于有志于数据库领域研究的小伙伴,这里是最好的学习和工作平台。 优秀的同行人,助我成长 我所在组的研究方向是智能数据库,目标是利用机器学习和统计优化等技术,实现数据库系统各个组件的自动优化,如存储引擎,并发控制,SQL优化器等,以减少系统成本,提升系统性能,以实现一个self-driving的数据库系统。 这是一个很有前景的方向。大四上学期,初来实习的我内心其实颇为忐忑,面对组里的同事前辈,“跟不上进度”成了我最担心的事情。然而,进入到工作状态之后,我心里的石头落了地:mentor给实习生安排的任务是循序渐进的,一次次讨论与指导,使我能够快速上手。经过和mentor的讨论,我选择把“智能查询优化”作为第一个研究项目,并且与大四学期的毕设结合,基于阿里线上平台的实际问题,展开研究。查询优化属于数据库比较底层的部分,之前我没有很深的了解。在开展研究的过程中,除了自己阅读文献,同事成为了我的“知识宝库”。遇到场景落地问题时,我会请教PolarDB-X优化器开发的同事,他们往往能够一针见血地指出实际问题。 我的成长离不开组里各位老师的帮助与分享,组内还会定期或不定期组织reading group,讲解工作成果与学界进展。在这里,你会发现身边的同事大多对深耕于某一领域,实力扎实,与他们交流会收获很多! 快乐工作,认真生活 “快乐工作,认真生活”,记得我刚刚入职时HR提到了这个观点,入职之后我发现这是阿里人身体力行的一句话。 在工作上,身边的人都很努力。在这种氛围的感召下,遇到难题,我也会情不自禁地在工位上多坐一会。暑期实习的时候,时常9点之后结束工作,打车回宿舍。生活上,团队里组织了丰富多彩的活动。聚餐已经成为了常规项目。工作间隙还可以去健身房锻炼一波,园区的按摩椅也成为了养生女孩的午休项目。印象最深的是团队组织的运动会,女子项目是平板支撑。听到这个消息之后,我基本每天都进行练习。运动会那天,杭州base、北京base、硅谷base进行了三地PK,在同事的加油下,我坚持了平板支持7分25秒,最后拿到了女子组冠军。 大家的工作与生活模式都很健康充实。在阿里,我见识到了工作发展的可持续性与优秀的团队交互模式。 阿里实习,带我打开科研大门 来到阿里之前,我是一个对科研比较懵懂的门外汉。特别幸运的是,在这里我遇到了很棒的mentor们指导我进行研究工作。不论是基础的代码风格还是研究思路、遇到的问题,mentor都会事无巨细地进行引导。以前我写代码,能跑起来、自己看得懂就行。 我在阿里提交的第一次merge request,有不少随意的空行和一些tricky且难以维护的逻辑。印象很深的是,当时mentor逐行写了comment指出问题。我认识到了代码的规范性和可维护性,以及别人是否能够理解自己的代码都是要考虑的问题。 2019年我从中国人民大学毕业,来到北京大学攻读数据科学研究生,感谢我的研究生导师崔斌老师对我在阿里实习的支持。当时,我在阿里研究的第一个课题,也画上了圆满的句号:我在NDBC(CCF National Database Conference)进行了课题报告,投稿论文并被评为best student paper。 我在阿里参与研究的第二个课题是数据库的智能调参。传统的数据库调参中DBA基于经验与尝试推荐参数值,而我们要做的是基于机器学习算法自动高效给出推荐。这个课题在进行过程中遇到了不少困难,算法的适用性与有效性是我们重点考虑的。在进行了很久的实验之后,会发现一些坑和问题,挫败感是有的,但是会马上被新的尝试与期待替代。 我发现,在这里的研究并不是为了学术灌水而做,有意义研究是问题导向的。mentor时常强调要找到可复现的场景和实际问题,这样才有实际意义。我的mentor base在硅谷,因为时差我时不时在早上收到消息和反馈,这成为了我起床开启新的一天的最大动力。mentor是我科研路上的引路人,也是并肩作战的战友,大家一起为了攻克问题而努力! 阿里的实习经历,帮我找到了打开科研大门的钥匙,让我从对科研的懵懵懂懂,到爱上了这一发现问题、攻克问题的过程。我希望将来能继续数据库领域的研究工作,在玉洁冰清的逻辑世界继续追寻。 【张亚斌-华南理工大学- 搬砖有感之研究吐槽】 首先声明这是一份任务性报告,大家如果赶去吃饭就可以先撤了。大家如果正在排队,可以一起吐槽一下。 作为一名即将硕士毕业&博士入学的研究生,我的研究经验有限,所以以下感悟吐槽仅供大家茶余饭后一笑,偶有雷同,纯属巧合~ 选题 提到学术研究,首当其冲的就是选题啦。选题并不仅仅是选择自己喜欢的热点题目,要综合考虑很多其他因素: - Supervisor or coauthor的研究背景。该项涉及到可预期的帮助 - 可使用的硬件资源。对于cv和ml来说,有的课题需要占用很大的计算资源,如 - -ImageNet based NAS。硬件资源基本决定了试错的时间成本。 - 研究课题的研究价值。当时火的课题,有些做1-2年之后可能就过时了,有些1-2年之后可能更加火。决定性因素很大程度是其潜在应用空间。 该研究课题在工业界的价值。在阿里工作实习的我们的研究课题当然和公司项目有千丝万缕的联系。 自己的兴趣。 除了上述的热点课题或潜在热点课题,还有如下的选择: 自创新的课题,俗称挖坑。该方面需要对整个研究领域比较全面和比较深入的理解,然后对整个研究领域的研究方向进行建设性的预测。一般都是大佬在挖坑。 方法 选好课题之后,得到对应的解决问题的方法一般经由如下步骤: 1. 发现问题的能力:一般来说,对于新问题会有一个或几个直接的处理方法,此时就是比手速的时候了;不过很多时候这里真正较量的是发现问题的能力。 2.发现问题的能力again:后续像我这样的大多数研究人员都是在该框架上修修改改,当然也会有大牛直接开辟新的basic pipelines。如果我们聚焦在对现有框架的修改,首先第一步要做的是分析现有框架有什么遗留问题,然后针对该问题设计改进方法。 3.Naïve idea:我们一般会发现其实做出少量改进并发表论文是相对容易的,因为simple idea是比较容易获得的:如 https://mp.weixin.qq.com/s/vnyra_xcg9D6NUNVpKtP0Q所调侃,单纯的做方法A+方法B,或者A方法用于B领域就可以实现(或许这就是多看论文的巨大优势?调侃脸)。不过对于非入门同学来说,该method combine的方式形同饮鸩止渴。 4.Mature idea:相对于直接将其他论文中的方法“借”为己用,借鉴其他论文方法提出过程中的研究思路是一个更加合理的选择。也就是要分析出:该作者发现了哪些问题?对该问题提出了怎样的思考?如何从思考过渡到实际算法改进?甚至对于算法改进过程中碰到的问题的处理方法。这个分析过程是重要的也是必要的,我觉得这个过程是研究人员提升的过程,即发现问题,解决问题能力的全面提升。 5.Advanced idea: 特指原创性很强的,从无到有的idea。和上面说的大牛的basic pipelines应该基本重叠吧。 写作 基本方法验证之后,接下来论文写作了。 英文写作约等于逻辑+英文本身,其中逻辑占绝大比重。逻辑就是讲故事,如何条理分明将自己的工作讲给别人听,并让听者觉得该工作在整个研究的领域是重要的,有意义的。写作能力很重要,例如即使naive的idea 如果写作很好也是很有机会发表的。那么如何练习呢?我导师给的朴素建议是:多练习,每天把自己的工作进展和想法用英文formal 的写出来。 最后,也是最重要的,祝各位同学抱紧大腿,大腿紧抱。

问问小秘 2020-05-19 13:01:37 0 浏览量 回答数 0

问题

阿里云与Linode对比测试-阿里云与Linode选哪个好

roye888 2019-12-01 21:31:31 22266 浏览量 回答数 5

回答

在这个信息时代高速发展的情况下,很多人会对自己该往哪个方向发展感到迷茫,下面我就浅显的给大家介绍一下五大流行区域的发展前景。大数据的发展前景:当前大数据行业真的是人才稀缺吗?学了几年后,大数据行业会不会产能过剩?大数据行业最终需要什么样的人才?接下来就带你们看看分析结果:当前大数据行业真的是人才稀缺吗?对!未来人才缺口150万,数据分析人才最稀缺。先看大数据人才缺口有多大?根据LinkedIn(领英)发布的《2016年中国互联网最热职位人才报告》显示,研发工程师、产品经理、人力资源、市场营销、运营和数据分析是当下中国互联网行业需求最旺盛的六类人才职位。其中数据分析人才最为稀缺、供给指数最低。同时,数据分析人才跳槽速度也最快,平均跳槽速度为19.8个月。而清华大学计算机系教授武永卫去年透露了一组数据:未来3-5年,中国需要180万数据人才,但目前只有约30万人。大数据行业未来会产能过剩吗?提供大数据技术与应用服务的第三方公司面临调整,未来发展会趋集中关于“大数据概念是否被过度炒作”的讨论,其实2013年的夏季达沃斯就有过。彼时支持“炒作”观点的现场观众达54.5%。对此,持反对意见的北京大学光华管理学院副教授苏萌提出了三个理由:不同机构间的数据还未真正流动起来,目前还只是数据“孤岛”;完整的生态产业链还未形成,尽管通过行为数据分析已能够分辨出一个消费者的喜好,但从供应到购买的链条还没建成;数据分析人才仍然极度匮乏。4年之后,舆论热点已经逐渐从大数据转向人工智能,大数据行业也历经整合。近一年间,一些大数据公司相继出现裁员、业务大调整等情况,部分公司出现亏损。那都是什么公司面临危机呢?基于数据归属,涉及大数据业务的公司其实有两类:一类是自身拥有数据的甲方公司,如亚马逊、阿里巴巴等;另一类是整合数据资源,提供大数据技术与应用服务的第三方公司。目前行业整合出现盈利问题的公司多集中在第三方服务商。对此,LinkedIn(领英)中国技术副总裁王迪表示,第三方服务商提供的更多的是技术或平台,大数据更多还是让甲方公司获益。在王迪看来,大数据业务要产生规模效益,至少要具备三点:算法、计算平台以及数据本身。“第三方大数据创业公司在算法上有一技之长,而计算能力实际上已经匀化了,传统企业如果用好了,和大数据创业公司没有区别,甚至计算能力更强,而数据获取方面,很多数据在传统行业内部并没有共享出来,第三方大数据公司获取这些数据是比较困难的,最后可能谁有数据,谁产生的价值更高。”说白了,数据为王。在2013年,拿到千万级A轮融资的大数据企业不足10家,到2015年,拿到千万级以上A轮融资的企业已经超过30家。直到2016年互联网资本寒冬,大数据行业投资热度有所减退,大数据行业是否也存在产能过剩?王迪认为,目前的行业整合属于正常现象,“经过市场的优胜劣汰,第三方服务领域会出现一些做得比较好的公司,其他公司可能被淘汰或转型做一些垂直行业应用。从社会来看,总的需求量一定是增加的,而对于供给侧,经过行业自然的洗牌,最终会集中在几家优秀的行业公司。”需要什么样的大数据人才?今年3月份,教育部公布了第二批获准开设“数据科学与大数据技术”的高校名单,加上第一批获批的北京大学、对外经济贸易大学、中南大学,一共35所高校获批该专业。今年开始,部分院校将招收第一届大数据专业本科生。大数据人才培养涉及到两方面问题:交叉性学科的人才培养方案是否与市场需求相匹配;学科建设的周期与行业快速更新之间的差距怎样弥合。对于第一个问题,“电商热”时期开设的电子商务专业是一个可吸取经验的样本。2000年,教育部高教司批准了第一批高校开设电子商务本科专业。作为一个复合型专业,电子商务的本科教学涵盖了管理、技术、营销三方面的课程。电子商务领域人才需求量大,但企业却无法从电子商务专业中找到合适的人才,原因何在?职业规划专家姜萌认为,并不是某一个专业对应一个行业热点,而是一个专业集群对应一个行业热点。“比如电子商务专业,我们到电子商务公司里会发现,不是学电子商务的人在做这些工作,而是每个专业各司其职,比如计算机、设计、物流管理、营销、广告、金融等等。现在行业的复合型工作都是由一个专业集群来完成的,而不是一个人来复合一堆专业特点。”大数据专业的人才培养也同样走复合型路线,复旦大学大数据学院的招生简章显示,学院本科人才培养以统计学、计算机科学和数学为三大基础支撑性学科,以生物学、医学、环境科学、经济学、社会学、管理学等为应用拓展性学科,具备典型的交叉学科特征。LinkedIn(领英)中国技术副总裁王迪指出,“从企业应用的角度来看,大数据行业里从事相关职能的同学背景是各异的,大数据作为一个人才培养方向还在探索中,在这个阶段,高校尝试开设硕士课程是很好的实践,但开设一类的本科专业还为时过早。”另一方面,专业人才培养的周期较长,而行业热点不断更新轮替,中间产生的时间差使得新兴专业的志愿填报具备了一定风险。王迪认为,“从今天的产业实践上看,大数据领域依然是从现有专业中挑选人才,教育和市场发展总是有一定差距的,学生本科四年,加上硕士阶段已经是七年之后的事情了,产业已经演进了很多,而教学大纲并不会跟进得那么快。”因此,尽管大数据的应用前景毋庸置疑,但在人才培养层面,复合型人才培养方案会不会重走电子商务专业的老路?学校教育如何赶上行业发展速度?这些都是值得进一步商榷的问题。面对热门专业,志愿填报需要注意啥?了解了大数据行业、公司和大数据专业后,姜萌对于考生填报像大数据相关的热门专业,提出了几条建议:报考热的专业和就业热的专业并不一定是重合的,比如软件、计算机、金融,这些专业的就业率实际并没有那么高,地质勘探、石油、遥感等专业,虽然报考上是冷门,但行业需求大,就业率更高。选择热门专业,更需要考虑就业质量。专业就业好,是统计学意义,指的是平均收入水平高,比如金融专业的收入,比其他纯文科专业的平均收入较高,但落实到个体层面,就业情况就不一样了,尤其像金融专业是典型的名校高学历好就业,但对于考试成绩较低的同学来说,如果去一些普通院校、专科院校学习金融,最后就业情况可能还不如会计专业。志愿填报,除了专业,城市因素也很重要:如果想从事金融、互联网的工作,更适合去一线城市,如果是去三、四线城市的学生可以考虑应用面比较广的专业,就是各行各业都能用到的专业,比如会计专业,专科层次的会计和985层次的会计都有就业渠道。如果先选择报考城市,也可以针对所在城市的行业特点选择专业,比如沿海城市外贸相对发达,选择国际贸易、外语类专业就业情况更好,比如武汉有光谷,选择光电类专业更好就业。最终家长和考生更需要考虑个人与专业匹配的问题,金融、计算机等热门专业不是所有人都适合学,好专业不见得对所有个体都是好的。java的发展前景:由于Java的诸多优点,Java的发展前景十分广泛。比如,在我们中国的市场,Java无论在企业级应用,还是在面向大众的服务方面都取得了不少进展,在中国的电信、金融等关键性业务中发挥着举足轻重的作用。由于SUN、TBM、Oracle等国际厂商相继推出各种基于Java技术的应用服务器以及各种应用软件,推动了Java在金融、电信、制造等领域日益广泛的应用,如清华大学计算机系利用Java、XML和Web技术研制开发了多个软件平台,东方科技的TongWeb、中创的Inforweb等J2EE应用服务器。由此可见,在巨大市场需求下,企业对于Java人才的渴求已经是不争的事实。你问我火了这么多年的Java语言的发展前景怎么样?那来看看吧Java在WEB、移动设备以及云计算方面前景广阔,随着云计算以及移动领域的扩张,更多的企业在考虑将其应用部署在Java平台上。无论是本地主机,公共云,Java都是目前最适合的选择。;另外在Oracle的技术投资担保下,Java也是企业在云应用方面回避微软平台、在移动应用方面回避苹果公司的一个最佳选择。Java可以参与制作大部分网络应用程序系统,而且与如今流行的WWW浏览器结合很好,这一优点将促进Java的更大范围的推广。因为在未来的社会,信息将会传送的更加快速,这将推动程序向WEB程序方向发展,由于Java具有编写WEB程序的能力,并且Java与浏览器结合良好,这将使得Java前景充满光明的发展。Python的发展前景:Python程序员的发展前景是怎样的?随着Python的技术的流行, Python在为人们带来工作与生活上的便捷后,关注者们开始慢慢关心Python的发展前景与方向。从自身特性看Python发展Python自身强大的优势决定其不可限量的发展前景。Python作为一种通用语言,几乎可以用在任何领域和场合,角色几乎是无限的。Python具有简单、易学、免费、开源、可移植、可扩展、可嵌入、面向对象等优点,它的面向对象甚至比java和C#、.net更彻底。它是一种很灵活的语言,能帮你轻松完成编程工作。强大的类库支持,使编写文件处理、正则表达式,网络连接等程序变得相当容易。能运行在多种计算机平台和操作系统中,如各位unix,windows,MacOS,OS/2等等,并可作为一种原型开发语言,加快大型程序的开发速度。从企业应用来看Python发展Python被广泛的用在Web开发、运维自动化、测试自动化、数据挖掘等多个行业和领域。一项专业调查显示,75%的受访者将Python视为他们的主要开发语言,反之,其他25%受访者则将其视为辅助开发语言。将Python作为主要开发语言的开发者数量逐年递增,这表明Python正在成为越来越多开发者的开发语言选择。目前,国内不少大企业都已经使用Python如豆瓣、搜狐、金山、腾讯、盛大、网易、百度、阿里、淘宝、热酷、土豆、新浪、果壳等;国外的谷歌、NASA、YouTube、Facebook、工业光魔、红帽等都在应用Python完成各种各样的任务。从市场需求与薪资看Python发展Python得到越来越多公司的青睐,使得Python人才需求逐年增加,从市场整体需求来看,Python在招聘市场上的流行程度也是在逐步上升的,工资水平也是水涨船高。据统计Python平均薪资水平在12K,随着经验的提升,薪资也是逐年增长。学习Python的程序员,除去Python开发工程师、Python高级工程师、Python自动化测试外,也能够朝着Python游戏开发工程师、SEO工程师、Linux运维工程师等方向发展,发展方向较为多元化。随着Python的流行,带动的是它的普及以及市场需求量,所以现在学习Python是个不错的时机。区块链的发展前景:区块链开发 ? 155---0116---2665 ?可是区块链技术到底是什么,大多数人都是模糊没有概念。通俗来讲,如果我们把数据库假设成一本账本,读写数据库就可以看做一种记账的行为,区块链技术的原理就是在一段时间内找出记账最快最好的人,由这个人来记账,然后将账本的这一页信息发给整个系统里的其他所有人。区块链技术也称分布式账本(或账簿)技术,属于互联网数据库技术,由参与者共同完成数据库记录,特点是去中心化和公开透明。此外,在每个区块的信息写入并获得认可后,整个区块链数据库完整保存在互联网的节点中,难以被修改,因此数据库的安全性极高。人们普遍认为,区块链技术是实现数字产品(如货币和知识产权)快速、安全和透明地对等(P2P)转账或转让的重要手段。在以色列Zen Protocol公司,区块链应用软件开发专家阿希尔·曼宁介绍说,他们公司正在开发Zen区块链平台,其将用于支持金融产品在无中介的环境下自动和自由交易。通常,人们将钱存放在银行,依靠银行管理自己的资金。但是,在支配资金时往往会受到银行规定的限制,或在汇款时存在耗时长、费用高等问题。区块链技术平台将让人们首次拥有自己管理和支配钱财的能力,他相信去中心化金融管理体系具有广阔的市场,有望极大地改变传统的金融市场。2018年伊始这一轮区块链的热潮,主要起源于虚拟货币的炒作热情。站在风口,区块链技术被认为是继蒸汽机、电力、互联网之后,下一代颠覆性的核心技术。很多人不禁要问“区块链又和比特币又是什么关系?”记者查询了大量资料发现,比特币2009年被一位名叫中本聪的人提出,之后比特币这套去中心化的机制一直稳定运行,这引起很多人对这套历史上并不存在的运行机制强烈关注。于是人们把从比特币技术抽象提取出来的技术运用于其他领域,称之为区块链。这过程就好像人们先发明了面条,然后人们发现其背后面粉不仅可以做面条还可以做馒头、面包。比特币是面条,区块链是面粉。也就是说,区块链和比特币的关系即比特币算是区块链技术的一种应用,或者说一种使用了区块链技术的产品形态。而说到区块链不得不说的就是ICO,它是一种公开发行的初始数字货币。对于投资人来说,出于对市场信号的敏感和长期关注价值投资项目,目前炙手可热的区块链也成为诸多投资人关注的新兴项目之一。“区块链对于我们来说就是省去了中间环节,节约了交易成本,节省了交易时间,但是目前来看各方面环境还不够成熟,有待观望。”一位投资人这样说道。记者发现,在春节期间,不少互金圈的朋友熬夜到凌晨进入某个探讨区块链的微信群热聊,此群还吸引了不少知名人士,诸如明星加入,同时还有大咖在群里解读区块链的投资方式和未来发展等等。一时间,关于区块链的讨论群接二连三出现,也引发了各个行业对区块链的关注。出于对于区块链技术懵懂的状态,记者追问了身边的一些互金圈的朋友,为何如此痴迷区块链?多数朋友认为“区块链能赚钱,抱着试试看的心态,或许能像之前比特币一样从中获取收益。”显然,区块链技术具有广阔的应用潜力,但是在其逐步进入社会改善民众生活的过程中,也面临许多的问题,需要积极去寻求相应的对策,最终让其发挥出潜力。只有这样,10年或20年后人们才能真正享受区块链技术创造的美好环境。人工智能的发展前景:人工智能产业是智能产业发展的核心,是其他智能科技产品发展的基础,国内外的高科技公司以及风险投资机构纷纷布局人工智能产业链。科技部部长万钢3月10日表示,加快实施新一代人工智能科学基础的关键技术系统集成研发,使那些研发成果尽快能够进入到开放平台,在开放使用中再一次把它增强完善。万钢称,马上就要发布人工智能项目指南和细则,来突破基础前沿理论关键部分的技术。人工智能发展趋势据前瞻产业研究院《人工智能行业市场前瞻与投资战略规划分析报告》指出,2017年中国人工智能核心产业规模超过700亿元,随着国家规划的出台,各地人工智能相关建设将逐步启动,预计到2020年,中国人工智能核心产业规模将超过1600亿元,增长率达到26.2%。报告认为,从产业投资回报率分析,智能安防、智能驾驶等领域的快速发展都将刺激计算机视觉分析类产品的需求,使得计算机视觉领域具备投资价值;而随着中国软件集成水平和人们生活水平的提高,提供教育、医疗、娱乐等专业化服务的服务机器人和智能无人设备具备投资价值。人工智能现状当前,人工智能受到的关注度持续提升,大量的社会资本和智力、数据资源的汇集驱动人工智能技术研究不断向前推进。从发展层次来看,人工智能技术可分为计算智能、感知智能和认知智能。当前,计算智能和感知智能的关键技术已经取得较大突破,弱人工智能应用条件基本成熟。但是,认知智能的算法尚未突破,前景仍不明朗。今年,随着智力资源的不断汇集,人工智能核心技术的研究重点可能将从深度学习转为认知计算,即推动弱人工智能向强人工智能不断迈进。一方面,在人工智能核心技术方面,在百度等大型科技公司和北京大学、清华大学等重点院校的共同推动下,以实现强人工智能为目标的类脑智能有望率先突破。另一方面,在人工智能支撑技术方面,量子计算、类脑芯片等核心技术正处在从科学实验向产业化应用的转变期,以数据资源汇集为主要方向的物联网技术将更加成熟,这些技术的突破都将有力推动人工智能核心技术的不断演进。工业大数据2022 年我国工业大数据有望突破 1200 亿元, 复合增速 42%。 工业大数据是提升制造智能化水平,推动中国制造业转型升级的关键动力,具体包括企业信息化数据、工业物联网数据,以及外部跨界数据。其中,企业信息化和工业物联网中机器产生的海量时序数据是工业数据的主要来源。工业大数据不仅可以优化现有业务,实现提质增效,而且还有望推动企业业务定位和盈利模式发生重大改变,向个性化定制、智能化生产、网络化协同、服务化延伸等智能化场景转型。预计到 2022 年,中国工业大数据市场规模有望突破 1200亿元,年复合增速 42%。IT的未来是人工智能这是一个指数级增长的时代。过去几十年,信息技术的进步相当程度上归功于芯片上晶体管数目的指数级增加,及由此带来的计算力的极大提升。这就是所谓的摩尔定律。在互联网时代,互联的终端数也是超线性的增长,而网络的效力大致与联网终端数的平方成正比。今天,大数据时代产生的数据正在呈指数级增加。在指数级增长的时代,我们可能会高估技术的短期效应,而低估技术的长期效应。历史的经验告诉我们,技术的影响力可能会远远的超过我们的想象。未来的计算能力人工智能需要强大的计算能力。计算机的性能过去30年提高了一百万倍。随着摩尔定律逐渐趋于物理极限,未来几年,我们期待一些新的技术突破。先谈一下类脑计算。传统计算机系统,长于逻辑运算,不擅长模式识别与形象思维。构建模仿人脑的类脑计算机芯片,我们今天可以以极低的功耗,模拟100万个神经元,2亿5千万个神经突触。未来几年,我们会看到类脑计算机的进一步的发展与应用随着互联网的普及、传感器的泛在、大数据的涌现、电子商务的发展、信息社区的兴起,数据和知识在人类社会、物理空间和信息空间之间交叉融合、相互作用,人工智能发展所处信息环境和数据基础发展了巨大的变化。伴随着科学基础和实现载体取得新的突破,类脑计算、深度学习、强化学习等一系列的技术萌芽预示着内在动力的成长,人工智能的发展已进入一个新的阶段。发展发展前景好,代表你现在学习会比后来者起步快,占有更大的优势,当然,你也要明白兴趣是最好的老师,选择自己感兴趣的相信你学的会更加而牢固。记住,最重要的一点:方向最重要!!!希望大家多多关注. ,加微信zhanglindashuju 可以获取更多资料哦作者:失色的瞳孔链接:https://juejin.im/post/5b1a6531e51d45067e6fc24a来源:掘金著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

孟志昂 2019-12-02 01:45:13 0 浏览量 回答数 0

问题

见证阿里云服务器成长路程

supper800 2019-12-01 20:25:20 10163 浏览量 回答数 1

问题

H5技术百问——不懂H5你就OUT啦

yq传送门 2019-12-01 20:27:41 42586 浏览量 回答数 47

问题

【精品问答】python百大常见问题与答案详解

祖安文状元 2020-02-24 17:56:41 363 浏览量 回答数 1

回答

你好,这里有208份资料,详情请参考:https://github.com/ty4z2008/Qix/blob/master/ds.md 《Reconfigurable Distributed Storage for Dynamic Networks》介绍:这是一篇介绍在动态网络里面实现分布式系统重构的paper.论文的作者(导师)是MIT读博的时候是做分布式系统的研究的,现在在NUS带学生,不仅仅是分布式系统,还有无线网络.如果感兴趣可以去他的主页了解. 《Distributed porgramming liboratory》介绍:分布式编程实验室,他们发表的很多的paper,其中不仅仅是学术研究,还有一些工业界应用的论文. 《MIT Theory of Distributed Systems》介绍:麻省理工的分布式系统理论主页,作者南希·林奇在2002年证明了CAP理论,并且著《分布式算法》一书. 《Notes on Distributed Systems for Young Bloods》介绍:分布式系统搭建初期的一些建议 《Principles of Distributed Computing》介绍:分布式计算原理课程 《Google's Globally-Distributed Database》介绍:Google全球分布式数据介绍,中文版 《The Architecture Of Algolia’s Distributed Search Network》介绍:Algolia的分布式搜索网络的体系架构介绍 《Build up a High Availability Distributed Key-Value Store》介绍:构建高可用分布式Key-Value存储系统 《Distributed Search Engine with Nanomsg and Bond》介绍:Nanomsg和Bond的分布式搜索引擎 《Distributed Processing With MongoDB And Mongothon》介绍:使用MongoDB和Mongothon进行分布式处理 《Salt: Combining ACID and BASE in a Distributed Database》介绍:分布式数据库中把ACID与BASE结合使用. 《Makes it easy to understand Paxos for Distributed Systems》介绍:理解的Paxos的分布式系统,参考阅读:关于Paxos的历史 《There is No Now Problems with simultaneity in distributed systems》介绍:There is No Now Problems with simultaneity in distributed systems 《Distributed Systems》介绍:伦敦大学学院分布式系统课程课件. 《Distributed systems for fun and profit》介绍:分布式系统电子书籍. 《Distributed Systems Spring 2015》介绍:卡内基梅隆大学春季分布式课程主页 《Distributed Systems: Concepts and Design (5th Edition)》介绍: 电子书,分布式系统概念与设计(第五版) 《走向分布式》介绍:这是一位台湾网友 ccshih 的文字,短短的篇幅介绍了分布式系统的若干要点。pdf 《Introduction to Distributed Systems Spring 2013》介绍:清华大学分布式系统课程主页,里面的schedule栏目有很多宝贵的资源 《Distributed systems》介绍:免费的在线分布式系统书籍 《Some good resources for learning about distributed computing》介绍:Quora上面的一篇关于学习分布式计算的资源. 《Spanner: Google’s Globally-Distributed Database》介绍:这个是第一个全球意义上的分布式数据库,也是Google的作品。其中介绍了很多一致性方面的设计考虑,为了简单的逻辑设计,还采用了原子钟,同样在分布式系统方面具有很强的借鉴意义. 《The Chubby lock service for loosely-coupled distributed systems》介绍:Google的统面向松散耦合的分布式系统的锁服务,这篇论文详细介绍了Google的分布式锁实现机制Chubby。Chubby是一个基于文件实现的分布式锁,Google的Bigtable、Mapreduce和Spanner服务都是在这个基础上构建的,所以Chubby实际上是Google分布式事务的基础,具有非常高的参考价值。另外,著名的zookeeper就是基于Chubby的开源实现.推荐The google stack,Youtube:The Chubby lock service for loosely-coupled distributed systems 《Sinfonia: a new paradigm for building scalable distributed systems》介绍:这篇论文是SOSP2007的Best Paper,阐述了一种构建分布式文件系统的范式方法,个人感觉非常有用。淘宝在构建TFS、OceanBase和Tair这些系统时都充分参考了这篇论文. 《Data-Intensive Text Processing with MapReduce》介绍:Ebook:Data-Intensive Text Processing with MapReduce. 《Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System》介绍:Design and Implementation of a Query Processor for a Trusted Distributed Data Base Management System. 《Distributed Query Processing》介绍:分布式查询入门. 《Distributed Systems and the End of the API》介绍:分布式系统和api总结. 《Distributed Query Reading》介绍:分布式系统阅读论文,此外还推荐github上面的一个论文列表The Distributed Reader。 《Replication, atomicity and order in distributed systems》介绍:Replication, atomicity and order in distributed systems 《MIT course:Distributed Systems》介绍:2015年MIT分布式系统课程主页,这次用Golang作为授课语言。6.824 Distributed Systems课程主页 《Distributed systems for fun and profit》介绍:免费分布式系统电子书。 《Ori:A Secure Distributed File System》介绍:斯坦福开源的分布式文件系统。 《Availability in Globally Distributed Storage Systems》介绍:Google论文:设计一个高可用的全球分布式存储系统。 《Calvin: Fast Distributed Transactions For Partitioned Database Systems》介绍:对于分区数据库的分布式事务处理。 《Distributed Systems Building Block: Flake Ids》介绍:Distributed Systems Building Block: Flake Ids. 《Introduction to Distributed System Design》介绍:Google Code University课程,如何设计一个分布式系统。 《Sheepdog: Distributed Storage System for KVM》介绍:KVM的分布式存储系统. 《Readings in Distributed Systems Systems》介绍:分布式系统课程列表,包括数据库、算法等. 《Tera》介绍:来自百度的分布式表格系统. 《Distributed systems: for fun and profit》介绍:分布式系统的在线电子书. 《Distributed Systems Reading List》介绍:分布式系统资料,此外还推荐Various articles about distributed systems. 《Designs, Lessons and Advice from Building Large Distributed Systems》介绍:Designs, Lessons and Advice from Building Large Distributed Systems. 《Testing a Distributed System》介绍:Testing a distributed system can be trying even under the best of circumstances. 《The Google File System》介绍: 基于普通服务器构建超大规模文件系统的典型案例,主要面向大文件和批处理系统, 设计简单而实用。 GFS是google的重要基础设施, 大数据的基石, 也是Hadoop HDFS的参考对象。 主要技术特点包括: 假设硬件故障是常态(容错能力强), 64MB大块, 单Master设计,Lease/链式复制, 支持追加写不支持随机写. 《Bigtable: A Distributed Storage System for Structured Data》介绍:支持PB数据量级的多维非关系型大表, 在google内部应用广泛,大数据的奠基作品之一 , Hbase就是参考BigTable设计。 Bigtable的主要技术特点包括: 基于GFS实现数据高可靠, 使用非原地更新技术(LSM树)实现数据修改, 通过range分区并实现自动伸缩等.中文版 《PacificA: Replication in Log-Based Distributed Storage Systems》介绍:面向log-based存储的强一致的主从复制协议, 具有较强实用性。 这篇文章系统地讲述了主从复制系统应该考虑的问题, 能加深对主从强一致复制的理解程度。 技术特点: 支持强一致主从复制协议, 允许多种存储实现, 分布式的故障检测/Lease/集群成员管理方法. 《Object Storage on CRAQ, High-throughput chain replication for read-mostly workloads》介绍:分布式存储论文:支持强一直的链式复制方法, 支持从多个副本读取数据,实现code. 《Finding a needle in Haystack: Facebook’s photo storage》介绍:Facebook分布式Blob存储,主要用于存储图片. 主要技术特色:小文件合并成大文件,小文件元数据放在内存因此读写只需一次IO. 《Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency》介绍: 微软的分布式存储平台, 除了支持类S3对象存储,还支持表格、队列等数据模型. 主要技术特点:采用Stream/Partition两层设计(类似BigTable);写错(写满)就封存Extent,使得副本字节一致, 简化了选主和恢复操作; 将S3对象存储、表格、队列、块设备等融入到统一的底层存储架构中. 《Paxos Made Live – An Engineering Perspective》介绍:从工程实现角度说明了Paxo在chubby系统的应用, 是理解Paxo协议及其应用场景的必备论文。 主要技术特点: paxo协议, replicated log, multi-paxo.参考阅读:关于Paxos的历史 《Dynamo: Amazon’s Highly Available Key-Value Store》介绍:Amazon设计的高可用的kv系统,主要技术特点:综和运用一致性哈希,vector clock,最终一致性构建一个高可用的kv系统, 可应用于amazon购物车场景.新内容来自分布式存储必读论文 《Efficient Replica Maintenance for Distributed Storage Systems》介绍:分布式存储系统中的副本存储问题. 《PADS: A Policy Architecture for Distributed Storage Systems》介绍:分布式存储系统架构. 《The Chirp Distributed Filesystem》介绍:开源分布式文件系统Chirp,对于想深入研究的开发者可以阅读文章的相关Papers. 《Time, Clocks, and the Ordering of Events in a Distributed System》介绍:经典论文分布式时钟顺序的实现原理. 《Making reliable distributed systems in the presence of sodware errors》介绍:面向软件错误构建可靠的分布式系统,中文笔记. 《MapReduce: Simplified Data Processing on Large Clusters》介绍:MapReduce:超大集群的简单数据处理. 《Distributed Computer Systems Engineering》介绍:麻省理工的分布式计算课程主页,里面的ppt和阅读列表很多干货. 《The Styx Architecture for Distributed Systems》介绍:分布式系统Styx的架构剖析. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上面的一个问答:有哪些关于分布式计算学习的好资源. 《RebornDB: The Next Generation Distributed Key-Value Store》介绍:下一代分布式k-v存储数据库. 《Operating System Concepts Ninth Edition》介绍:分布式系统归根结底还是需要操作系统的知识,这是耶鲁大学的操作系统概念书籍首页,里面有提供了第8版的在线电子版和最新的学习操作系统指南,学习分布式最好先学习操作系统. 《The Log: What every software engineer should know about real-time data's unifying abstraction》介绍:分布式系统Log剖析,非常的详细与精彩. 中文翻译 | 中文版笔记. 《Operating Systems Study Guide》介绍:分布式系统基础之操作系统学习指南. 《分布式系统领域经典论文翻译集》介绍:分布式系统领域经典论文翻译集. 《Maintaining performance in distributed systems》介绍:分布式系统性能维护. 《Computer Science from the Bottom Up》介绍:计算机科学,自底向上,小到机器码,大到操作系统内部体系架构,学习操作系统的另一个在线好材料. 《Operating Systems: Three Easy Pieces》介绍:<操作系统:三部曲>在线电子书,虚拟、并发、持续. 《Database Systems: reading list》介绍:数据库系统经典论文阅读列,此外推送github上面的db reading. 《Unix System Administration》介绍:Unix System Administration ebook. 《The Amoeba Distributed Operating System》介绍:分布式系统经典论文. 《Principles of Computer Systems》介绍:计算机系统概念,以分布式为主.此外推荐Introduction to Operating Systems笔记 《Person page of EMİN GÜN SİRER》介绍:推荐康奈尔大学的教授EMİN GÜN SİRER的主页,他的研究项目有分布式,数据存储。例如HyperDex数据库就是他的其中一个项目之一. 《Scalable, Secure, and Highly Available Distributed File Access》介绍:来自卡内基梅隆如何构建可扩展的、安全、高可用性的分布式文件系统,其他papers. 《Distributed (Deep) Machine Learning Common》介绍:分布式机器学习常用库. 《The Datacenter as a Computer》介绍:介绍了如何构建仓储式数据中心,尤其是对于现在的云计算,分布式学习来说很有帮助.本书是Synthesis Lectures on Computer Architecture系列的书籍之一,这套丛书还有 《The Memory System》,《Automatic Parallelization》,《Computer Architecture Techniques for Power Efficiency》,《Performance Analysis and Tuning for General Purpose Graphics Processing Units》,《Introduction to Reconfigurable Supercomputing》,Memory Systems Cache, DRAM, Disk 等 《helsinki:Distributed Systems Course slider》介绍:来自芬兰赫尔辛基的分布式系统课程课件:什么是分布式,复制,一致性,容错,同步,通信. 《TiDB is a distributed SQL database》介绍:分布式数据库TiDB,Golang开发. 《S897: Large-Scale Systems》介绍:课程资料:大规模系统. 《Large-scale L-BFGS using MapReduce》介绍:使用MapReduce进行大规模分布式集群环境下并行L-BFGS. 《Twitter是如何构建高性能分布式日志的》介绍:Twitter是如何构建高性能分布式日志的. 《Distributed Systems: When Limping Hardware Is Worse Than Dead Hardware》介绍:在分布式系统中某个组件彻底死了影响很小,但半死不活(网络/磁盘),对整个系统却是毁灭性的. 《Tera - 高性能、可伸缩的结构化数据库》介绍:来自百度的分布式数据库. 《SequoiaDB is a distributed document-oriented NoSQL Database》介绍:SequoiaDB分布式文档数据库开源. 《Readings in distributed systems》介绍:这个网址里收集了一堆各TOP大学分布式相关的课程. 《Paxos vs Raft》介绍:这个网站是Raft算法的作者为教授Paxos和Raft算法做的,其中有两个视频链接,分别讲上述两个算法.参考阅读:关于Paxos的历史 《A Scalable Content-Addressable Network》介绍:A Scalable Content-Addressable Network. 《500 Lines or Less》介绍:这个项目其实是一本书( The Architecture of Open Source Applications)的源代码附录,是一堆大牛合写的. 《MIT 6.824 Distributed System》介绍:这只是一个课程主页,没有上课的视频,但是并不影响你跟着它上课:每一周读两篇课程指定的论文,读完之后看lecture-notes里对该论文内容的讨论,回答里面的问题来加深理解,最后在课程lab里把所看的论文实现。当你把这门课的作业刷完后,你会发现自己实现了一个分布式数据库. 《HDFS-alike in Go》介绍:使用go开发的分布式文件系统. 《What are some good resources for learning about distributed computing? Why?》介绍:Quora上关于学习分布式的资源问答. 《SeaweedFS is a simple and highly scalable distributed file system》介绍:SeaweedFS是使用go开发的分布式文件系统项目,代码简单,逻辑清晰. 《Codis - yet another fast distributed solution for Redis》介绍:Codis 是一个分布式 Redis 解决方案, 对于上层的应用来说, 连接到 Codis Proxy 和连接原生的 Redis Server 没有明显的区别 《Paper: Coordination Avoidance In Distributed Databases By Peter Bailis》介绍:Coordination Avoidance In Distributed Databases. 《从零开始写分布式数据库》介绍:本文以TiDB 源码为例. 《what we talk about when we talk about distributed systems》介绍:分布式系统概念梳理,为分布式系统涉及的主要概念进行了梳理. 《Distributed locks with Redis》介绍:使用Redis实现分布式锁. 《CS244b: Distributed Systems》介绍: 斯坦福2014年秋季分布式课程. 《RAMP Made Easy》介绍: 分布式的“读原子性”. 《Strategies and Principles of Distributed Machine Learning on Big Data》介绍: 大数据分布式机器学习的策略与原理. 《Distributed Systems: What is the CAP theorem?》介绍: 分布式CAP法则. 《How should I start to learn distributed storage system as a beginner?》介绍: 新手如何步入分布式存储系统. 《Cassandra - A Decentralized Structured Storage System》介绍: 分布式存储系统Cassandra剖析,推荐白皮书Introduction to Apache Cassandra. 《What is the best resource to learn about distributed systems?》介绍: 分布式系统学习资源. 《What are some high performance TCP hacks?》介绍: 一些高性能TCP黑客技巧. 《Maintaining performance in distributed systems》介绍:分布式系统性能提升. 《A simple totally ordered broadcast protocol》介绍:Benjamin Reed 和 Flavio P.Junqueira 所著论文,对Zab算法进行了介绍,zab算法是Zookeeper保持数据一致性的核心,在国内有很多公司都使用zookeeper做为分布式的解决方案.推荐与此相关的一篇文章ZooKeeper’s atomic broadcast protocol: Theory and practice. 《zFS - A Scalable Distributed File System Using Object Disk》介绍:可扩展的分布式文件系统ZFS,The Zettabyte File System,End-to-end Data Integrity for File Systems: A ZFS Case Study. 《A Distributed Haskell for the Modern Web》介绍:分布式Haskell在当前web中的应用. 《Reasoning about Consistency Choices in Distributed Systems》介绍:POPL2016的论文,关于分布式系统一致性选择的论述,POPL所接受的论文,github上已经有人整理. 《Paxos Made Simple》介绍:Paxos让分布式更简单.译文.参考阅读:关于Paxos的历史,understanding Paxos part1,Understanding Paxos – Part 2.Quora: What is a simple explanation of the Paxos algorithm?,Tutorial Summary: Paxos Explained from Scratch,Paxos algorithm explained, part 1: The essentials,Paxos algorithm explained, part 2: Insights 《Consensus Protocols: Paxos》介绍:分布式系统一致性协议:Paxos.参考阅读:关于Paxos的历史 《Consensus on Transaction Commit》介绍:事务提交的一致性探讨. 《The Part-Time Parliaments》介绍:在《The Part-Time Parliament》中描述了基本协议的交互过程。在基本协议的基础上完善各种问题得到了最终的议会协议。 为了让人更容易理解《The Part-Time Parliament》中描述的Paxos算法,Lamport在2001发表了《Paxos Made Simple》,以更平直的口头语言描述了Paxos,而没有包含正式的证明和数学术语。《Paxos Made Simple》中,将算法的参与者更细致的划分成了几个角色:Proposer、Acceptor、Learner。另外还有Leader和Client.参考阅读:关于Paxos的历史 《Paxos Made Practical》介绍:看这篇论文时可以先看看理解Paxos Made Practical. 《PaxosLease: Diskless Paxos for Leases》介绍:PaxosLease:实现租约的无盘Paxos算法,译文. 《Paxos Made Moderately Complex》介绍:Paxos算法实现,译文,同时推荐42 Paxos Made Moderately Complex. 《Hadoop Reading List》介绍:Hadoop学习清单. 《Hadoop Reading List》介绍:Hadoop学习清单. 《2010 NoSQL Summer Reading List》介绍:NoSQL知识清单,里面不仅仅包含了数据库阅读清单还包含了分布式系统资料. 《Raft: Understandable Distributed Consensus》介绍:Raft可视化图帮助理解分布式一致性 《Etcd:Distributed reliable key-value store for the most critical data of a distributed system》介绍:Etcd分布式Key-Value存储引擎 《Understanding Availability》介绍:理解peer-to-peer系统中的可用性究竟是指什么.同时推荐基于 Peer-to-Peer 的分布式存储系统的设计 《Process structuring, synchronization, and recovery using atomic actions》介绍:经典论文 《Programming Languages for Parallel Processing》介绍:并行处理的编程语音 《Analysis of Six Distributed File Systems》介绍:此篇论文对HDFS,MooseFS,iRODS,Ceph,GlusterFS,Lustre六个存储系统做了详细分析.如果是自己研发对应的存储系统推荐先阅读此篇论文 《A Survey of Distributed File Systems》介绍:分布式文件系统综述 《Concepts of Concurrent Programming》介绍:并行编程的概念,同时推荐卡内基梅隆FTP 《Concurrency Control Performance Modeling:Alternatives and Implications》介绍:并发控制性能建模:选择与意义 《Distributed Systems - Concepts and Design 5th Edition》介绍:ebook分布式系统概念与设计 《分布式系统设计的形式方法》介绍:分布式系统设计的形式方法 《互斥和选举算法》介绍:互斥和选举算法 《Actors:A model Of Concurrent Cornputation In Distributed Systems》介绍:经典论文 《Security Engineering: A Guide to Building Dependable Distributed Systems》介绍:如何构建一个安全可靠的分布式系统,About the Author,Bibliography:文献资料,章节访问把链接最后的01换成01-27即可 《15-712 Advanced and Distributed Operating Systems》介绍:卡内基梅隆大学的分布式系统博士生课程主页,有很丰富的资料 《Dapper, Google's Large-Scale Distributed Systems Tracing Infrastructure》介绍:Dapper,大规模分布式系统的跟踪系统,译文,译文对照 《CS262a: Advanced Topics in Computer Systems》介绍:伯克利大学计算机系统进阶课程,内容有深度,涵盖分布式,数据库等内容 《Egnyte Architecture: Lessons Learned In Building And Scaling A Multi Petabyte Distributed System》介绍:PB级分布式系统构建/扩展经验 《CS162: Operating Systems and Systems Programming》介绍:伯克利大学计算机系统课程:操作系统与系统编程 《MDCC: Multi-Data Center Consistency》介绍:MDCC主要解决跨数据中心的一致性问题中间件,一种新的协议 《Research at Google:Distributed Systems and Parallel Computing》介绍:google公开对外发表的分布式系统与并行计算论文 《HDFS Architecture Guide》介绍:分布式文件系统HDFS架构 《ActorDB distributed SQL database》介绍:分布式 Key/Value数据库 《An efficient data location protocol for self-organizing storage clusters》介绍:是著名的Ceph的负载平衡策略,文中提出的几种策略都值得尝试,比较赞的一点是可以对照代码体会和实践,如果你还需要了解可以看看Ceph:一个 Linux PB 级分布式文件系统,除此以外,论文的引用部分也挺值得阅读的,同时推荐Ceph: A Scalable, High-Performance Distributed File System 《A Self-Organizing Storage Cluster for Parallel Data-Intensive Applications》介绍:Surrento的冷热平衡策略就采用了延迟写技术 《HBA: Distributed Metadata Management for Large Cluster-Based Storage Systems》介绍:对于分布式存储系统的元数据管理. 《Server-Side I/O Coordination for Parallel File Systems》介绍:服务器端的I/O协调并行文件系统处理,网络,文件存储等都会涉及到IO操作.不过里面涉及到很多技巧性的思路在实践时需要斟酌 《Distributed File Systems: Concepts and Examples》介绍:分布式文件系统概念与应用 《CSE 221: Graduate Operating Systems》介绍:加利福尼亚大学的研究生操作系统课程主页,论文很值得阅读 《S4: Distributed Stream Computing Platform》介绍:Yahoo出品的流式计算系统,目前最流行的两大流式计算系统之一(另一个是storm),Yahoo的主要广告计算平台 《Pregel: a system for large-scale graph processing》介绍:Google的大规模图计算系统,相当长一段时间是Google PageRank的主要计算系统,对开源的影响也很大(包括GraphLab和GraphChi) 《GraphLab: A New Framework for Parallel Machine Learning》介绍:CMU基于图计算的分布式机器学习框架,目前已经成立了专门的商业公司,在分布式机器学习上很有两把刷子,其单机版的GraphChi在百万维度的矩阵分解都只需要2~3分钟; 《F1: A Distributed SQL Database That Scales》介绍:这篇论文是Google 2013年发表的,介绍了F1的架构思路,13年时就开始支撑Google的AdWords业务,另外两篇介绍文章F1 - The Fault-Tolerant Distributed RDBMS Supporting Google's Ad Business .Google NewSQL之F1 《Cockroach DB:A Scalable, Survivable, Strongly-Consistent SQL Database》介绍:CockroachDB :一个可伸缩的、跨地域复制的,且支持事务的数据存储,InfoQ介绍,Design and Architecture of CockroachDb 《Multi-Paxos: An Implementation and Evaluation》介绍:Multi-Paxos实现与总结,此外推荐Paxos/Multi-paxos Algorithm,Multi-Paxos Example,地址:ftp://ftp.cs.washington.edu/tr/2009/09/UW-CSE-09-09-02.PDF 《Zab: High-performance broadcast for primary-backup systems》介绍:一致性协议zab分析 《A Distributed Hash Table》介绍:分布式哈希算法论文,扩展阅读Introduction to Distributed Hash Tables,Distributed Hash Tables 《Comparing the performance of distributed hash tables under churn》介绍:分布式hash表性能的Churn问题 《Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web》介绍:分布式系统的CAP问题,推荐Perspectives on the CAP Theorem.对CAP理论的解析文章,PODC ppt,A plain english introduction to CAP Theorem,IEEE Computer issue on the CAP Theorem 《F2FS: A New File System for Flash Storage》介绍:闪存存储文件系统F2FS 《Better I/O Through Byte-Addressable, Persistent Memory》介绍:微软发表的关于i/o访问优化论文 《tmpfs: A Virtual Memory File System》介绍:虚拟内存文件系统tmpfs 《BTRFS: The Linux B-tree Filesystem》介绍:Linux B-tree文件系统. 《Akamai technical publication》介绍:Akamai是全球最大的云计算机平台之一,承载了全球15-30%网络流量,如果你是做CDN或者是云服务,这个里面的论文会给你很有帮助.例如这几天看facebook开源的osquery。找到通过db的方式运维,找到Keeping Track of 70,000+ Servers: The Akamai Query System这篇论文,先看论文领会思想,然后再使用工具osquery实践 《BASE: An Acid Alternative》介绍:来自eBay 的解决方案,译文Base: 一种Acid的替代方案,应用案例参考保证分布式系统数据一致性的6种方案 《A Note on Distributed Computing》介绍:Jim Waldo和Sam Kendall等人共同撰写了一篇非常有名的论文“分布式计算备忘录”,这篇论文在Reddit上被人推荐为“每个程序员都应当至少读上两篇”的论文。在这篇论文中,作者表示“忽略本地计算与分布式计算之间的区别是一种危险的思想”,特别指出了Emerald、Argus、DCOM以及CORBA的设计问题。作者将这些设计问题归纳为“三个错误的原则”: “对于某个应用来说,无论它的部署环境如何,总有一种单一的、自然的面向对象设计可以符合其需求。” “故障与性能问题与某个应用的组件实现直接相关,在最初的设计中无需考虑这些问题。” “对象的接口与使用对象的上下文无关”. 《Distributed Systems Papers》介绍:分布式系统领域经典论文列表. 《Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web》介绍:Consistent Hashing算法描述. 《SIGMOD 2016: Accepted Research Papers》介绍:SIGMOD是世界上最有名的数据库会议之一,最具有权威性,收录论文审核非常严格.2016年的SIGMOD 会议照常进行,上面收录了今年SIGMOD收录的论文,把题目输入google中加上pdf就能找到,很多论文值得阅读,SIGMOD 2015 《Notes on CPSC 465/565: Theory of Distributed Systems》介绍:耶鲁大学的分布式系统理论课程笔记 《Distributed Operating System Doc PDF》介绍:分布式系统文档资源(可下载) 《Anatomy of a database system》介绍:数据库系统剖析,这本书是由伯克利大学的Joseph M. Hellerstein和M. Stonebraker合著的一篇论文.对数据库剖析很有深度.除此以外还有一篇文章Architecture of a Database System。数据库系统架构,厦门大学的数据库实验室教授林子雨组织过翻译 《A Relational Model of Data for Large Shared Data Banks》介绍:数据库关系模型论文 《RUC Innovative data systems reaserch lab recommand papers》介绍:中国人民大学数据研究实验室推荐的数据库领域论文 《A Scalable Distributed Information Management System》介绍:构建可扩展的分布式信息管理系统 《Distributed Systems in Haskell》介绍:Haskell中的分布式系统开发 《Large-scale cluster management at Google with Borg》介绍:Google使用Borg进行大规模集群的管理,伯克利大学ppt介绍,中文版 《Lock Free Programming Practice》介绍:并发编程(Concurrency Programming)资料,主要涵盖lock free数据结构实现、内存回收方法、memory model等备份链接 密码: xc5j 《Distributed Algorithms Lecture Notes for 6.852》介绍:Nancy Lynch's的分布式算法研究生课程讲义 《Distributed Algorithms for Topic Models》介绍:分布式算法主题模型. 《RecSys - ACM Recommender Systems》介绍:世界上非常有名的推荐系统会议,我比较推荐接收的PAPER 《All Things Distributed》介绍:推荐一个博客,博主是Amazon CTO Werner Vogels,这是一个关注分布式领域的博客.大部分博文是关于在工业界应用. 《programming, database, distributed system resource list》介绍:这个Git是由阿里(alibaba)的技术专家何登成维护,主要是分布式数据库. 《Making reliable distributed systems in the presence of sodware errors》介绍:Erlang的作者Joe Armstrong撰写的论文,面对软件错误构建可靠的分布式系统.中文译版 《CS 525: Advanced Distributed Systems[Spring 2016]》介绍:伊利诺伊大学的Advanced Distributed Systems 里把各个方向重要papers(updated Spring 2015)列举出来,可以参考一下 《Distributed Algorithms》介绍:这是一本分布式算法电子书,作者是Jukka Suomela.讲述了多个计算模型,一致性,唯一标示,并发等. 《TinyLFU: A Highly Efficient Cache Admission Policy》介绍:当时是在阅读如何设计一个缓存系统时看到的,然后通过Google找到了这一篇关于缓存策略的论文,它是LFU的改良版,中文介绍.如果有兴趣可以看看Golang实现版。结合起来可能会帮助你理解 《6.S897: Large-Scale Systems》介绍:斯坦福大学给研究生开的分布式系统课程。教师是 spark 作者 matei. 能把这些内容真正理解透,分布式系统的功力就很强了。 《学习分布式系统需要怎样的知识?》介绍:[怎么学系列]学习分布式系统需要怎样的知识? 《Distributed systems theory for the distributed systems engineer》介绍:分布式系统工程师的分布式系统理论 《A Distributed Systems Reading List》介绍:分布式系统论文阅读列表 《Distributed Systems Reading Group》介绍:麻省理工大学分布式系统小组,他们会把平时阅读到的优秀论文分享出来。虽然有些论文本页已经收录,但是里面的安排表schedule还是挺赞的 《Scalable Software Architecture》介绍:分布式系统、可扩展性与系统设计相关报告、论文与网络资源汇总. 《MapReduce&Hadoop resource》介绍:MapReduce&Hadoop相关论文,涉及分布式系统设计,性能分析,实践,优化等多个方面 《Distributed Systems: Principles and Paradigms(second edtion)》介绍:分布式系统原理与范型第二版,课后解答 《Distributed Systems Seminar's reading list for Spring 2017》介绍:分布式系统研讨会论文阅读列表 《A Critique of the CAP Theorem》介绍:这是一篇评论CAP定理的论文,学习CAP很有帮助,推荐阅读评论文章"A Critique of the CAP Theorem" 《Evolving Distributed Systems》介绍:推荐文章不断进化的分布式系统.

suonayi 2019-12-02 03:17:27 0 浏览量 回答数 0

回答

一 、iOS APP 上架流程简介 1. 申请开发者账号 苹果的开发者账号主要分为个人(Individual)、公司(Company)、企业(Enterprise)、高校(University)四种类型,每年资费分别为$99、$99、$299、免费)。一般开发者申请的都是个人或者公司的,企业的开发者账号开发应用不能发布到App Store,只能企业内部使用。这个申请过程一般可能需要一个星期左右。公司和企业的需要邓白氏码,如果邓白氏码未申请,请先申请邓白氏码,这个过程需要一到两个星期。 创建证书、AppID、生成描述文件 通过 Mac 的钥匙串工具,生成证书请求文件,下载证书,这里需要注意的是下载下来的证书只能在请求该证书的电脑上使用,如果想给其他开发者使用需要将已经导入的证书导出为个人信息交换(.p12)格式供他人使用。 AppID 的创建需要用到项目的 Bundle ID,之后便可以创建描述文件了。 在开发者中心的 iTunes Connect 中配置 App 相关信息 在开发者中心里的 iTunes Connect 里的 APP 选项中新建 APP 项目并配置相应的信息(需要各个版本的屏幕截图,运行模拟器,调到最大(command+1)用 command+s 截图,还有就是一个1024*1024的图标,不能有圆角) 使用 Xcode 打包上传 App 将 2 步骤中申请好的证书和描述文件正确配置到 Xcode 中,设置好Xcode 的一些属性: 在Xcode中选择iOS Device(这里不能选择模拟器) 如果应用不支持横屏,请在 General 选项中将 Landscape Left 和 Landscape Right 两项的勾选去掉 查看版本号和构建版本号 将断点、全局断点、僵尸模式等都去掉 设置为 Release 模式 之后便可选择 Xcode->Product->Archive 打包项目,打包完成后选择 Upload to App Store 上传。如果不想使用 Xcode 上传的话,也可以选择 Export 导出 ipa 文件, 需要注意的是在导出时,必须选择 Save for iOS App Store Deployment。然后通过Application Loader 工具上传 ipa 文件。 提交审核 以上步骤完成后,返回 iTunes Connect 上查看自己的 App 信息,在构建版本中选择刚刚上传的 App 版本,此时有可能显示正在处理,这时可能需要等几分钟再回来查看。选择好版本后点击提交以供审核,这时 App 会变成等待审核状态。 后续 后续就是等待苹果的审核人员审核应用了,如果一切顺利的话,这个过程需要一到两个工作日便可完成审核,当然前提是你的应用符合苹果的审核条款。如果审核不通过,请及时根据反馈信息修改应用,再次提交直到符合要求。审核通过后,如果之前选择已经选择好自动发布,便可在 AppStore 上查看和下载应用了。 二 、iOS 上架审核过程常见的坑与解决方法 1. 问题:用户生成内容(UGC)缺少必要的审核 为了防止非法滥用用户生成的内容,从而给用户提供虚假信息、盗取用户的知识产权,社交应用以及应用当中包含用户生成的信息的应用必须包括下述功能: 过滤不良内容 提供举报机制 后台服务可以提供阻止骚扰用户的行为 提供官方联系方式,让用户可以快速联系到开发商 解决方案: 维秀直播 App 提供了用户实时弹幕功能,所以涉及到了 UGC,他们的处理方法是增加关键词过滤,还有通过房管的方式人工审核,处理违规用户。 问题:应用中使用了 IDFA 被拒绝 IDFA 主要被用于广告中区分设备的作用。AppStore 禁止没有使用广告而采集 IDFA 的 App 上架,所以如果 App 本身没有广告的话,使用第三方 SDK 要注意检查是否含有 IDFA 广告模块。 解决方案: 如果应用本身有集成广告的话,只需要在提交审核的时候勾选正确的广告标识符选项即可。 如果应用本身未集成广告,却包含 IDFA 的话。这种情况一般都是集成的第三方 SDK 中包含 IDFA 导致的。首先寻找是否有不包含 IDFA 的 SDK 版本,如果没有的话可以参考 ShareSDK 的解决方法,通过后台配置在审核期间为应用添加广告,审核完成过后将广告展示去掉。 3. 问题:应用不支持 IPv6网络下使用 2016年6月1号起,苹果的审核人员会在 IPv6 网络上审核你的应用,所以如果你的应用程序无法使用 IPv6 协议,可能会被拒绝。 解决方案: 卓易夺宝和乐动听 App 上架过程中就因为 IPv6 的支持原因被拒。他们的解决方案是: 协调后端人员添加对 IPv6 网络的支持。 App 端更新相关的第三方 SDK,比如使用 ASI 或者 AFN 的版本太低,使用最新的 AFN 即可解决问题。 当然这些做完之后最好在Mac 上面搭建 IPv6网络供测试人员进行完测试再重新发布。 4. 问题:第三方登录、支付、分享未安装应用,提示下载被拒 这个问题其实被拒的原因有两种,第一种是未安装应用没有任何提示,这种情况下相当于应用有无效的按钮所以会被拒;第二种是提示下载对应的第三方 App,这也是苹果所不允许的。 解决方案: 最新的第三方登录等相关的 SDK 目前已知的(微信,QQ,微博)都已经对这种情况做了处理,在未安装的情况下会调用 web 进行登录,所以如果测试过程中发现可以成功在 web 上登录的话可以不做处理。以前在没有这种处理机制的情况下需要开发者调用对应接口,先判断是否安装了相应的第三方 APP,如果未安装,需要隐藏按钮,这样便可轻松过审。 问题:虚拟产品未使用应用内支付(IAP)被拒 根据苹果官方最新的审核条款:如果你希望通过付费才可以解锁你的应用当中的一些功能(例如,订阅内容,游戏货币,游戏关卡,获取优质内容,解锁完整版本),你必须使用应用内付费(IAP)。如果这种情况下,应用使用了其他的第三方支付,应用将被拒绝上架。 解决方案: 审核的时候,把相应的虚拟产品隐藏起来,通过后再放出来,此招有风险,可能会受到警告信,甚至被封号,如果用户量小就无所谓了,先把App 搞上架! 审核的时候,走 IAP 的支付方式,审核完成后再通过服务器配置动态切换到支付宝、微信等第三方支付。该法类似于方案1,也存在风险。 学习58同城,让用户去网站购买产品,买了产品的账号到移动端使用功能。 老老实实的使用 IAP 吧。 6. 问题:使用后台定位被拒 关于位置服务苹果的审核条款原文如下: 使用位置服务的应用程序必须提供和位置服务直接相关的功能。使用基于位置的API不允许用于提供紧急服务,或者实现自动控制车辆、飞行器以及其他设备(小型的设备例如小型无人机和玩具例外),远程控制汽车警报系统等。在收集、传输和使用用户的位置数据之前,请确保你已经取得了用户的同意。 如果应用程序使用了后台定位服务,务必在应用当中阐明其目的。并且使用后台定位的话需要提供一个明确的提醒告诉用户这么做会加快电量消耗。 一般应用在这一块被拒的原因有以下几种: 应用根本不需要定位功能。 应用需要定位功能,但是只需要短暂的获取少数的用户的位置,比如美团,新闻类的应用需要获得当前用户的所在城市,却使用了后台定位模式。 应用确实需要使用后台定位,比如打车类软件,但是应用中却没有任何界面展示这些定位数据。 解决方案: 如果你的应用根本不需要定位功能,但是还是在 info.plist 里面添加了 location in the UIBackgroundModes key ,那么在 plist 文件里面移除 UIBackgroundModes key 就可以,这中情况较少,新手小白会犯这种错误。 如果只是简单获取位置不需要使用后台定位,只需要去掉info.plist 的文件中的 UIBackgroundModes 即可。 这种情况比较复杂,推荐的做法是通过表格或者轨迹展示出后台定位的数据,再提交审核的时候告诉苹果那个功能需要后台定位,具体展示后台定位的 数据在那个界面,最后需要 Continued use of GPS running in the background can dramatically decrease battery life加到 App 描述里 面,可以参考滴滴出行的描述,否则也会被拒绝。 7. 问题:info.plist 权限配置被拒 iOS 10 之后如果需要调用相机,蓝牙等设备时,需要在 info.plist 文件中进行相应的配置,否则应用会直接崩溃,在 iOS 10 之前则是无法访问。另外,如果在 info.plist 中调用了配置了权限在应用中却没有使用到也是会被拒的。 解决方案: 一定要注意自己的 App 在使用中用到了哪些权限,不要添加无用的权限,也不要缺少必要的权限。 问题:应用提示更新被拒 应用内不能有任何提示更新应用的字样,且应用的更新只能通过 AppStore。因为苹果对于应用的更新有自己的一套策略,所以禁止应用本身提供更新方式,只要应用内出现。 解决方案: 如果不是很必要的话,尽量将应用内涉及到应用更新的部分去掉。如果真的需要使用应用更新,推荐的方法是应用启动的时候获取下应用在 AppStore 上面的版本号,与自己的版本号进行比较,当自己的版本号小于 AppStore 上面的版本号时,提示更新,否则的话不显示更新相关的内容。 问题:夺宝(抽奖)类应用被拒 根据 AppStore 审核准则 20.4 的规定,抽奖卷或抽奖参与权的购买,不论是透过第三方支付渠道或者余额扣款实现,都不能够在 app 内执行。 解决方案: 卓易夺宝 App 上架过程中遇到的问题,最后的解决方法是在审核过程中,所有的支付行为都跳转到 Safari 浏览器上面进行,审核完成后再使用支付宝等 app 平台支付。 问题:隐私条款问题被拒 在未获得用户事先允许,或未告知用户信息将被如何,在哪里使用的情况下,应用不可以传输用户数据。 解决方案: 《网站服务协议》《隐私条款》这些都不要少,注册时候让用户可勾选。另外注明需要的用户信息用来做什么。 问题:未提供测试账号被拒 如果应用中有需要用到账号或者其他资源的(例如:一个二维码)才能使用的一些功能,但未提供给苹果,可能会被拒绝上架。原因是苹果审核人员无法测试这些功能。 解决方案: 提供一个有效的测试帐号以及登录信息,并提供测试功能必要的的硬件和资源(例如,一个测试用的二维码) 问题:未通过 HTTPS 访问被拒 App Transport Security(ATS) 是 Apple 为增强 iOS App 网络通信安全提出的安全功能,适用于 iOS App 和 App Extension;在启用 ATS 之后,它会强制应用通过 HTTPS(而不是 HTTP )连接网络服务。 WWDC 2016上提出,2016年底或2017年初,具体时间未定。App Store 上架审核加强对 ATS 配置的 review,即强制应用必须通过 HTTPS 连接网络服务,而不是随手将 NSAllowsArbitraryLoads 置为 YES,否则审核不予通过。 解决方案: ATS 的提出,是为了在系统层面保障 iOS APP 网络通信的安全;Apple 只所以加强对 ATS 配置的审核,是为了防止开发者们遇到ATS相关的场景时,只是简单地将 ATS完全关闭(只要没有强制性措施,开发者会这么做);在此基础上,App 审核同样会遵循原则:App Review will require "reasonable justification" for most ATS exceptions。 Apple 官方给出的可以通过审核的声明 demo 如下: 必须使用第三方提供的服务,但是其没有支持 HTTPS; 必须通过域名连接到设备,但该设备不能支持安全连接; 必须展示不同来源的网页内容,但是不能基于 NSAllowsArbitraryLoadsInWebContent 支持的类(UIWebView / WKWebView)实现; 载入加密的媒体资源并且其中不涉及个人信息。 由于 Apple 官方并没有给出 ATS 审核的完整说明,ATS 审核时什么才是合适合理的声明也没有明确的客观定义,以上 demo 描述仅能作为参照。 参考文章: http://www.jianshu.com/p/b1b77d804254 https://github.com/wg689/Solve-App-Store-Review-Problem 22人点赞 iOS 作者:Jon1993 链接:https://www.jianshu.com/p/a992c88087a5 来源:简书

一只刺猬 2020-03-27 10:03:40 0 浏览量 回答数 0

回答

92题 一般来说,建立INDEX有以下益处:提高查询效率;建立唯一索引以保证数据的唯一性;设计INDEX避免排序。 缺点,INDEX的维护有以下开销:叶节点的‘分裂’消耗;INSERT、DELETE和UPDATE操作在INDEX上的维护开销;有存储要求;其他日常维护的消耗:对恢复的影响,重组的影响。 需要建立索引的情况:为了建立分区数据库的PATITION INDEX必须建立; 为了保证数据约束性需要而建立的INDEX必须建立; 为了提高查询效率,则考虑建立(是否建立要考虑相关性能及维护开销); 考虑在使用UNION,DISTINCT,GROUP BY,ORDER BY等字句的列上加索引。 91题 作用:加快查询速度。原则:(1) 如果某属性或属性组经常出现在查询条件中,考虑为该属性或属性组建立索引;(2) 如果某个属性常作为最大值和最小值等聚集函数的参数,考虑为该属性建立索引;(3) 如果某属性经常出现在连接操作的连接条件中,考虑为该属性或属性组建立索引。 90题 快照Snapshot是一个文件系统在特定时间里的镜像,对于在线实时数据备份非常有用。快照对于拥有不能停止的应用或具有常打开文件的文件系统的备份非常重要。对于只能提供一个非常短的备份时间而言,快照能保证系统的完整性。 89题 游标用于定位结果集的行,通过判断全局变量@@FETCH_STATUS可以判断是否到了最后,通常此变量不等于0表示出错或到了最后。 88题 事前触发器运行于触发事件发生之前,而事后触发器运行于触发事件发生之后。通常事前触发器可以获取事件之前和新的字段值。语句级触发器可以在语句执行前或后执行,而行级触发在触发器所影响的每一行触发一次。 87题 MySQL可以使用多个字段同时建立一个索引,叫做联合索引。在联合索引中,如果想要命中索引,需要按照建立索引时的字段顺序挨个使用,否则无法命中索引。具体原因为:MySQL使用索引时需要索引有序,假设现在建立了"name,age,school"的联合索引,那么索引的排序为: 先按照name排序,如果name相同,则按照age排序,如果age的值也相等,则按照school进行排序。因此在建立联合索引的时候应该注意索引列的顺序,一般情况下,将查询需求频繁或者字段选择性高的列放在前面。此外可以根据特例的查询或者表结构进行单独的调整。 86题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 85题 存储过程是一组Transact-SQL语句,在一次编译后可以执行多次。因为不必重新编译Transact-SQL语句,所以执行存储过程可以提高性能。触发器是一种特殊类型的存储过程,不由用户直接调用。创建触发器时会对其进行定义,以便在对特定表或列作特定类型的数据修改时执行。 84题 存储过程是用户定义的一系列SQL语句的集合,涉及特定表或其它对象的任务,用户可以调用存储过程,而函数通常是数据库已定义的方法,它接收参数并返回某种类型的值并且不涉及特定用户表。 83题 减少表连接,减少复杂 SQL,拆分成简单SQL。减少排序:非必要不排序,利用索引排序,减少参与排序的记录数。尽量避免 select *。尽量用 join 代替子查询。尽量少使用 or,使用 in 或者 union(union all) 代替。尽量用 union all 代替 union。尽量早的将无用数据过滤:选择更优的索引,先分页再Join…。避免类型转换:索引失效。优先优化高并发的 SQL,而不是执行频率低某些“大”SQL。从全局出发优化,而不是片面调整。尽可能对每一条SQL进行 explain。 82题 如果条件中有or,即使其中有条件带索引也不会使用(要想使用or,又想让索引生效,只能将or条件中的每个列都加上索引)。对于多列索引,不是使用的第一部分,则不会使用索引。like查询是以%开头。如果列类型是字符串,那一定要在条件中将数据使用引号引用起来,否则不使用索引。如果mysql估计使用全表扫描要比使用索引快,则不使用索引。例如,使用<>、not in 、not exist,对于这三种情况大多数情况下认为结果集很大,MySQL就有可能不使用索引。 81题 主键不能重复,不能为空,唯一键不能重复,可以为空。建立主键的目的是让外键来引用。一个表最多只有一个主键,但可以有很多唯一键。 80题 空值('')是不占用空间的,判断空字符用=''或者<>''来进行处理。NULL值是未知的,且占用空间,不走索引;判断 NULL 用 IS NULL 或者 is not null ,SQL 语句函数中可以使用 ifnull ()函数来进行处理。无法比较 NULL 和 0;它们是不等价的。无法使用比较运算符来测试 NULL 值,比如 =, <, 或者 <>。NULL 值可以使用 <=> 符号进行比较,该符号与等号作用相似,但对NULL有意义。进行 count ()统计某列的记录数的时候,如果采用的 NULL 值,会被系统自动忽略掉,但是空值是统计到其中。 79题 HEAP表是访问数据速度最快的MySQL表,他使用保存在内存中的散列索引。一旦服务器重启,所有heap表数据丢失。BLOB或TEXT字段是不允许的。只能使用比较运算符=,<,>,=>,= <。HEAP表不支持AUTO_INCREMENT。索引不可为NULL。 78题 如果想输入字符为十六进制数字,可以输入带有单引号的十六进制数字和前缀(X),或者只用(Ox)前缀输入十六进制数字。如果表达式上下文是字符串,则十六进制数字串将自动转换为字符串。 77题 Mysql服务器通过权限表来控制用户对数据库的访问,权限表存放在mysql数据库里,由mysql_install_db脚本初始化。这些权限表分别user,db,table_priv,columns_priv和host。 76题 在缺省模式下,MYSQL是autocommit模式的,所有的数据库更新操作都会即时提交,所以在缺省情况下,mysql是不支持事务的。但是如果你的MYSQL表类型是使用InnoDB Tables 或 BDB tables的话,你的MYSQL就可以使用事务处理,使用SET AUTOCOMMIT=0就可以使MYSQL允许在非autocommit模式,在非autocommit模式下,你必须使用COMMIT来提交你的更改,或者用ROLLBACK来回滚你的更改。 75题 它会停止递增,任何进一步的插入都将产生错误,因为密钥已被使用。 74题 创建索引的时候尽量使用唯一性大的列来创建索引,由于使用b+tree做为索引,以innodb为例,一个树节点的大小由“innodb_page_size”,为了减少树的高度,同时让一个节点能存放更多的值,索引列尽量在整数类型上创建,如果必须使用字符类型,也应该使用长度较少的字符类型。 73题 当MySQL单表记录数过大时,数据库的CRUD性能会明显下降,一些常见的优化措施如下: 限定数据的范围: 务必禁止不带任何限制数据范围条件的查询语句。比如:我们当用户在查询订单历史的时候,我们可以控制在一个月的范围内。读/写分离: 经典的数据库拆分方案,主库负责写,从库负责读。垂直分区: 根据数据库里面数据表的相关性进行拆分。简单来说垂直拆分是指数据表列的拆分,把一张列比较多的表拆分为多张表。水平分区: 保持数据表结构不变,通过某种策略存储数据分片。这样每一片数据分散到不同的表或者库中,达到了分布式的目的。水平拆分可以支撑非常大的数据量。 72题 乐观锁失败后会抛出ObjectOptimisticLockingFailureException,那么我们就针对这块考虑一下重试,自定义一个注解,用于做切面。针对注解进行切面,设置最大重试次数n,然后超过n次后就不再重试。 71题 一致性非锁定读讲的是一条记录被加了X锁其他事务仍然可以读而不被阻塞,是通过innodb的行多版本实现的,行多版本并不是实际存储多个版本记录而是通过undo实现(undo日志用来记录数据修改前的版本,回滚时会用到,用来保证事务的原子性)。一致性锁定读讲的是我可以通过SELECT语句显式地给一条记录加X锁从而保证特定应用场景下的数据一致性。 70题 数据库引擎:尤其是mysql数据库只有是InnoDB引擎的时候事物才能生效。 show engines 查看数据库默认引擎;SHOW TABLE STATUS from 数据库名字 where Name='表名' 如下;SHOW TABLE STATUS from rrz where Name='rrz_cust';修改表的引擎alter table table_name engine=innodb。 69题 如果是等值查询,那么哈希索引明显有绝对优势,因为只需要经过一次算法即可找到相应的键值;当然了,这个前提是,键值都是唯一的。如果键值不是唯一的,就需要先找到该键所在位置,然后再根据链表往后扫描,直到找到相应的数据;如果是范围查询检索,这时候哈希索引就毫无用武之地了,因为原先是有序的键值,经过哈希算法后,有可能变成不连续的了,就没办法再利用索引完成范围查询检索;同理,哈希索引也没办法利用索引完成排序,以及like ‘xxx%’ 这样的部分模糊查询(这种部分模糊查询,其实本质上也是范围查询);哈希索引也不支持多列联合索引的最左匹配规则;B+树索引的关键字检索效率比较平均,不像B树那样波动幅度大,在有大量重复键值情况下,哈希索引的效率也是极低的,因为存在所谓的哈希碰撞问题。 68题 decimal精度比float高,数据处理比float简单,一般优先考虑,但float存储的数据范围大,所以范围大的数据就只能用它了,但要注意一些处理细节,因为不精确可能会与自己想的不一致,也常有关于float 出错的问题。 67题 datetime、timestamp精确度都是秒,datetime与时区无关,存储的范围广(1001-9999),timestamp与时区有关,存储的范围小(1970-2038)。 66题 Char使用固定长度的空间进行存储,char(4)存储4个字符,根据编码方式的不同占用不同的字节,gbk编码方式,不论是中文还是英文,每个字符占用2个字节的空间,utf8编码方式,每个字符占用3个字节的空间。Varchar保存可变长度的字符串,使用额外的一个或两个字节存储字符串长度,varchar(10),除了需要存储10个字符,还需要1个字节存储长度信息(10),超过255的长度需要2个字节来存储。char和varchar后面如果有空格,char会自动去掉空格后存储,varchar虽然不会去掉空格,但在进行字符串比较时,会去掉空格进行比较。Varbinary保存变长的字符串,后面不会补\0。 65题 首先分析语句,看看是否load了额外的数据,可能是查询了多余的行并且抛弃掉了,可能是加载了许多结果中并不需要的列,对语句进行分析以及重写。分析语句的执行计划,然后获得其使用索引的情况,之后修改语句或者修改索引,使得语句可以尽可能的命中索引。如果对语句的优化已经无法进行,可以考虑表中的数据量是否太大,如果是的话可以进行横向或者纵向的分表。 64题 建立索引的时候一般要考虑到字段的使用频率,经常作为条件进行查询的字段比较适合。如果需要建立联合索引的话,还需要考虑联合索引中的顺序。此外也要考虑其他方面,比如防止过多的所有对表造成太大的压力。这些都和实际的表结构以及查询方式有关。 63题 存储过程是一些预编译的SQL语句。1、更加直白的理解:存储过程可以说是一个记录集,它是由一些T-SQL语句组成的代码块,这些T-SQL语句代码像一个方法一样实现一些功能(对单表或多表的增删改查),然后再给这个代码块取一个名字,在用到这个功能的时候调用他就行了。2、存储过程是一个预编译的代码块,执行效率比较高,一个存储过程替代大量T_SQL语句 ,可以降低网络通信量,提高通信速率,可以一定程度上确保数据安全。 62题 密码散列、盐、用户身份证号等固定长度的字符串应该使用char而不是varchar来存储,这样可以节省空间且提高检索效率。 61题 推荐使用自增ID,不要使用UUID。因为在InnoDB存储引擎中,主键索引是作为聚簇索引存在的,也就是说,主键索引的B+树叶子节点上存储了主键索引以及全部的数据(按照顺序),如果主键索引是自增ID,那么只需要不断向后排列即可,如果是UUID,由于到来的ID与原来的大小不确定,会造成非常多的数据插入,数据移动,然后导致产生很多的内存碎片,进而造成插入性能的下降。总之,在数据量大一些的情况下,用自增主键性能会好一些。 60题 char是一个定长字段,假如申请了char(10)的空间,那么无论实际存储多少内容。该字段都占用10个字符,而varchar是变长的,也就是说申请的只是最大长度,占用的空间为实际字符长度+1,最后一个字符存储使用了多长的空间。在检索效率上来讲,char > varchar,因此在使用中,如果确定某个字段的值的长度,可以使用char,否则应该尽量使用varchar。例如存储用户MD5加密后的密码,则应该使用char。 59题 一. read uncommitted(读取未提交数据) 即便是事务没有commit,但是我们仍然能读到未提交的数据,这是所有隔离级别中最低的一种。 二. read committed(可以读取其他事务提交的数据)---大多数数据库默认的隔离级别 当前会话只能读取到其他事务提交的数据,未提交的数据读不到。 三. repeatable read(可重读)---MySQL默认的隔离级别 当前会话可以重复读,就是每次读取的结果集都相同,而不管其他事务有没有提交。 四. serializable(串行化) 其他会话对该表的写操作将被挂起。可以看到,这是隔离级别中最严格的,但是这样做势必对性能造成影响。所以在实际的选用上,我们要根据当前具体的情况选用合适的。 58题 B+树的高度一般为2-4层,所以查找记录时最多只需要2-4次IO,相对二叉平衡树已经大大降低了。范围查找时,能通过叶子节点的指针获取数据。例如查找大于等于3的数据,当在叶子节点中查到3时,通过3的尾指针便能获取所有数据,而不需要再像二叉树一样再获取到3的父节点。 57题 因为事务在修改页时,要先记 undo,在记 undo 之前要记 undo 的 redo, 然后修改数据页,再记数据页修改的 redo。 Redo(里面包括 undo 的修改) 一定要比数据页先持久化到磁盘。 当事务需要回滚时,因为有 undo,可以把数据页回滚到前镜像的状态,崩溃恢复时,如果 redo log 中事务没有对应的 commit 记录,那么需要用 undo把该事务的修改回滚到事务开始之前。 如果有 commit 记录,就用 redo 前滚到该事务完成时并提交掉。 56题 redo log是物理日志,记录的是"在某个数据页上做了什么修改"。 binlog是逻辑日志,记录的是这个语句的原始逻辑,比如"给ID=2这一行的c字段加1"。 redo log是InnoDB引擎特有的;binlog是MySQL的Server层实现的,所有引擎都可以使用。 redo log是循环写的,空间固定会用完:binlog 是可以追加写入的。"追加写"是指binlog文件写到一定大小后会切换到下一个,并不会覆盖以前的日志。 最开始 MySQL 里并没有 InnoDB 引擎,MySQL 自带的引擎是 MyISAM,但是 MyISAM 没有 crash-safe 的能力,binlog日志只能用于归档。而InnoDB 是另一个公司以插件形式引入 MySQL 的,既然只依靠 binlog 是没有 crash-safe 能力的,所以 InnoDB 使用另外一套日志系统,也就是 redo log 来实现 crash-safe 能力。 55题 重做日志(redo log)      作用:确保事务的持久性,防止在发生故障,脏页未写入磁盘。重启数据库会进行redo log执行重做,达到事务一致性。 回滚日志(undo log)  作用:保证数据的原子性,保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC),也即非锁定读。 二进 制日志(binlog)    作用:用于主从复制,实现主从同步;用于数据库的基于时间点的还原。 错误日志(errorlog) 作用:Mysql本身启动,停止,运行期间发生的错误信息。 慢查询日志(slow query log)  作用:记录执行时间过长的sql,时间阈值可以配置,只记录执行成功。 一般查询日志(general log)    作用:记录数据库的操作明细,默认关闭,开启后会降低数据库性能 。 中继日志(relay log) 作用:用于数据库主从同步,将主库发来的bin log保存在本地,然后从库进行回放。 54题 MySQL有三种锁的级别:页级、表级、行级。 表级锁:开销小,加锁快;不会出现死锁;锁定粒度大,发生锁冲突的概率最高,并发度最低。 行级锁:开销大,加锁慢;会出现死锁;锁定粒度最小,发生锁冲突的概率最低,并发度也最高。 页面锁:开销和加锁时间界于表锁和行锁之间;会出现死锁;锁定粒度界于表锁和行锁之间,并发度一般。 死锁: 是指两个或两个以上的进程在执行过程中。因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。 死锁的关键在于:两个(或以上)的Session加锁的顺序不一致。 那么对应的解决死锁问题的关键就是:让不同的session加锁有次序。死锁的解决办法:1.查出的线程杀死。2.设置锁的超时时间。3.指定获取锁的顺序。 53题 当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况。若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性(脏读,不可重复读,幻读等),可能产生死锁。 乐观锁:乐观锁不是数据库自带的,需要我们自己去实现。 悲观锁:在进行每次操作时都要通过获取锁才能进行对相同数据的操作。 共享锁:加了共享锁的数据对象可以被其他事务读取,但不能修改。 排他锁:当数据对象被加上排它锁时,一个事务必须得到锁才能对该数据对象进行访问,一直到事务结束锁才被释放。 行锁:就是给某一条记录加上锁。 52题 Mysql是关系型数据库,MongoDB是非关系型数据库,数据存储结构的不同。 51题 关系型数据库优点:1.保持数据的一致性(事务处理)。 2.由于以标准化为前提,数据更新的开销很小。 3. 可以进行Join等复杂查询。 缺点:1、为了维护一致性所付出的巨大代价就是其读写性能比较差。 2、固定的表结构。 3、高并发读写需求。 4、海量数据的高效率读写。 非关系型数据库优点:1、无需经过sql层的解析,读写性能很高。 2、基于键值对,数据没有耦合性,容易扩展。 3、存储数据的格式:nosql的存储格式是key,value形式、文档形式、图片形式等等,文档形式、图片形式等等,而关系型数据库则只支持基础类型。 缺点:1、不提供sql支持,学习和使用成本较高。 2、无事务处理,附加功能bi和报表等支持也不好。 redis与mongoDB的区别: 性能:TPS方面redis要大于mongodb。 可操作性:mongodb支持丰富的数据表达,索引,redis较少的网络IO次数。 可用性:MongoDB优于Redis。 一致性:redis事务支持比较弱,mongoDB不支持事务。 数据分析:mongoDB内置了数据分析的功能(mapreduce)。 应用场景:redis数据量较小的更性能操作和运算上,MongoDB主要解决海量数据的访问效率问题。 50题 如果Redis被当做缓存使用,使用一致性哈希实现动态扩容缩容。如果Redis被当做一个持久化存储使用,必须使用固定的keys-to-nodes映射关系,节点的数量一旦确定不能变化。否则的话(即Redis节点需要动态变化的情况),必须使用可以在运行时进行数据再平衡的一套系统,而当前只有Redis集群可以做到这样。 49题 分区可以让Redis管理更大的内存,Redis将可以使用所有机器的内存。如果没有分区,你最多只能使用一台机器的内存。分区使Redis的计算能力通过简单地增加计算机得到成倍提升,Redis的网络带宽也会随着计算机和网卡的增加而成倍增长。 48题 除了缓存服务器自带的缓存失效策略之外(Redis默认的有6种策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种: 1.定时去清理过期的缓存; 2.当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。 两者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪种方案,可以根据应用场景来权衡。 47题 Redis提供了两种方式来作消息队列: 一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列,一旦消息到达,消费者马上消费,谁先抢到算谁的,如果队列里没有消息,则消费者继续监听 。另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道,只要发布者发布消息,所有订阅者都能收到消息,订阅者都是平等的。 46题 Redis的数据结构列表(list)可以实现延时队列,可以通过队列和栈来实现。blpop/brpop来替换lpop/rpop,blpop/brpop阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。Redis的有序集合(zset)可以用于实现延时队列,消息作为value,时间作为score。Zrem 命令用于移除有序集中的一个或多个成员,不存在的成员将被忽略。当 key 存在但不是有序集类型时,返回一个错误。 45题 1.热点数据缓存:因为Redis 访问速度块、支持的数据类型比较丰富。 2.限时业务:expire 命令设置 key 的生存时间,到时间后自动删除 key。 3.计数器:incrby 命令可以实现原子性的递增。 4.排行榜:借助 SortedSet 进行热点数据的排序。 5.分布式锁:利用 Redis 的 setnx 命令进行。 6.队列机制:有 list push 和 list pop 这样的命令。 44题 一致哈希 是一种特殊的哈希算法。在使用一致哈希算法后,哈希表槽位数(大小)的改变平均只需要对 K/n 个关键字重新映射,其中K是关键字的数量, n是槽位数量。然而在传统的哈希表中,添加或删除一个槽位的几乎需要对所有关键字进行重新映射。 43题 RDB的优点:适合做冷备份;读写服务影响小,reids可以保持高性能;重启和恢复redis进程,更加快速。RDB的缺点:宕机会丢失最近5分钟的数据;文件特别大时可能会暂停数毫秒,或者甚至数秒。 AOF的优点:每个一秒执行fsync操作,最多丢失1秒钟的数据;以append-only模式写入,没有任何磁盘寻址的开销;文件过大时,不会影响客户端读写;适合做灾难性的误删除的紧急恢复。AOF的缺点:AOF日志文件比RDB数据快照文件更大,支持写QPS比RDB支持的写QPS低;比RDB脆弱,容易有bug。 42题 对于Redis而言,命令的原子性指的是:一个操作的不可以再分,操作要么执行,要么不执行。Redis的操作之所以是原子性的,是因为Redis是单线程的。而在程序中执行多个Redis命令并非是原子性的,这也和普通数据库的表现是一样的,可以用incr或者使用Redis的事务,或者使用Redis+Lua的方式实现。对Redis来说,执行get、set以及eval等API,都是一个一个的任务,这些任务都会由Redis的线程去负责执行,任务要么执行成功,要么执行失败,这就是Redis的命令是原子性的原因。 41题 (1)twemproxy,使用方式简单(相对redis只需修改连接端口),对旧项目扩展的首选。(2)codis,目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数改变情况下,旧节点数据可恢复到新hash节点。(3)redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。(4)在业务代码层实现,起几个毫无关联的redis实例,在代码层,对key进行hash计算,然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的代替算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。 40题 (1) Master最好不要做任何持久化工作,如RDB内存快照和AOF日志文件 (2) 如果数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次 (3) 为了主从复制的速度和连接的稳定性,Master和Slave最好在同一个局域网内 (4) 尽量避免在压力很大的主库上增加从库 (5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3...这样的结构方便解决单点故障问题,实现Slave对Master的替换。如果Master挂了,可以立刻启用Slave1做Master,其他不变。 39题 比如订单管理,热数据:3个月内的订单数据,查询实时性较高;温数据:3个月 ~ 12个月前的订单数据,查询频率不高;冷数据:1年前的订单数据,几乎不会查询,只有偶尔的查询需求。热数据使用mysql进行存储,需要分库分表;温数据可以存储在ES中,利用搜索引擎的特性基本上也可以做到比较快的查询;冷数据可以存放到Hive中。从存储形式来说,一般情况冷数据存储在磁带、光盘,热数据一般存放在SSD中,存取速度快,而温数据可以存放在7200转的硬盘。 38题 当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。 37题 分层架构设计,有一条准则:站点层、服务层要做到无数据无状态,这样才能任意的加节点水平扩展,数据和状态尽量存储到后端的数据存储服务,例如数据库服务或者缓存服务。显然进程内缓存违背了这一原则。 36题 更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个 jvm 内部队列中。读取数据的时候,如果发现数据不在缓存中,那么将重新读取数据+更新缓存的操作,根据唯一标识路由之后,也发送同一个 jvm 内部队列中。一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行。 35题 redis分布式锁加锁过程:通过setnx向特定的key写入一个随机值,并同时设置失效时间,写值成功既加锁成功;redis分布式锁解锁过程:匹配随机值,删除redis上的特点key数据,要保证获取数据、判断一致以及删除数据三个操作是原子的,为保证原子性一般使用lua脚本实现;在此基础上进一步优化的话,考虑使用心跳检测对锁的有效期进行续期,同时基于redis的发布订阅优雅的实现阻塞式加锁。 34题 volatile-lru:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选最近最少使用的数据淘汰。 volatile-ttl:当内存不足以容纳写入数据时,从已设置过期时间的数据集中挑选将要过期的数据淘汰。 volatile-random:当内存不足以容纳写入数据时,从已设置过期时间的数据集中任意选择数据淘汰。 allkeys-lru:当内存不足以容纳写入数据时,从数据集中挑选最近最少使用的数据淘汰。 allkeys-random:当内存不足以容纳写入数据时,从数据集中任意选择数据淘汰。 noeviction:禁止驱逐数据,当内存使用达到阈值的时候,所有引起申请内存的命令会报错。 33题 定时过期:每个设置过期时间的key都需要创建一个定时器,到过期时间就会立即清除。该策略可以立即清除过期的数据,对内存很友好;但是会占用大量的CPU资源去处理过期的数据,从而影响缓存的响应时间和吞吐量。 惰性过期:只有当访问一个key时,才会判断该key是否已过期,过期则清除。该策略可以最大化地节省CPU资源,却对内存非常不友好。极端情况可能出现大量的过期key没有再次被访问,从而不会被清除,占用大量内存。 定期过期:每隔一定的时间,会扫描一定数量的数据库的expires字典中一定数量的key,并清除其中已过期的key。该策略是前两者的一个折中方案。通过调整定时扫描的时间间隔和每次扫描的限定耗时,可以在不同情况下使得CPU和内存资源达到最优的平衡效果。 32题 缓存击穿,一个存在的key,在缓存过期的一刻,同时有大量的请求,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。如何避免:在访问key之前,采用SETNX(set if not exists)来设置另一个短期key来锁住当前key的访问,访问结束再删除该短期key。 31题 缓存雪崩,是指在某一个时间段,缓存集中过期失效。大量的key设置了相同的过期时间,导致在缓存在同一时刻全部失效,造成瞬时DB请求量大、压力骤增,引起雪崩。而缓存服务器某个节点宕机或断网,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。如何避免:1.redis高可用,搭建redis集群。2.限流降级,在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。3.数据预热,在即将发生大并发访问前手动触发加载缓存不同的key,设置不同的过期时间。 30题 缓存穿透,是指查询一个数据库一定不存在的数据。正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并把查询到的对象,放进缓存。如果数据库查询对象为空,则不放进缓存。一些恶意的请求会故意查询不存在的 key,请求量很大,对数据库造成压力,甚至压垮数据库。 如何避免:1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该 key 对应的数据 insert 了之后清理缓存。2:对一定不存在的 key 进行过滤。可以把所有的可能存在的 key 放到一个大的 Bitmap 中,查询时通过该 bitmap 过滤。 29题 1.memcached 所有的值均是简单的字符串,redis 作为其替代者,支持更为丰富的数据类型。 2.redis 的速度比 memcached 快很多。 3.redis 可以持久化其数据。 4.Redis支持数据的备份,即master-slave模式的数据备份。 5.Redis采用VM机制。 6.value大小:redis最大可以达到1GB,而memcache只有1MB。 28题 Spring Boot 推荐使用 Java 配置而非 XML 配置,但是 Spring Boot 中也可以使用 XML 配置,通过spring提供的@ImportResource来加载xml配置。例如:@ImportResource({"classpath:some-context.xml","classpath:another-context.xml"}) 27题 Spring像一个大家族,有众多衍生产品例如Spring Boot,Spring Security等等,但他们的基础都是Spring的IOC和AOP,IOC提供了依赖注入的容器,而AOP解决了面向切面的编程,然后在此两者的基础上实现了其他衍生产品的高级功能。Spring MVC是基于Servlet的一个MVC框架,主要解决WEB开发的问题,因为 Spring的配置非常复杂,各种xml,properties处理起来比较繁琐。Spring Boot遵循约定优于配置,极大降低了Spring使用门槛,又有着Spring原本灵活强大的功能。总结:Spring MVC和Spring Boot都属于Spring,Spring MVC是基于Spring的一个MVC框架,而Spring Boot是基于Spring的一套快速开发整合包。 26题 YAML 是 "YAML Ain't a Markup Language"(YAML 不是一种标记语言)的递归缩写。YAML 的配置文件后缀为 .yml,是一种人类可读的数据序列化语言,可以简单表达清单、散列表,标量等数据形态。它通常用于配置文件,与属性文件相比,YAML文件就更加结构化,而且更少混淆。可以看出YAML具有分层配置数据。 25题 Spring Boot有3种热部署方式: 1.使用springloaded配置pom.xml文件,使用mvn spring-boot:run启动。 2.使用springloaded本地加载启动,配置jvm参数-javaagent:<jar包地址> -noverify。 3.使用devtools工具包,操作简单,但是每次需要重新部署。 用

游客ih62co2qqq5ww 2020-03-27 23:56:48 0 浏览量 回答数 0

问题

【案例】从hadoop框架与MapReduce模式中谈海量数据处理

jack.cai 2019-12-01 21:00:28 15859 浏览量 回答数 3

问题

词汇表是什么样的?(S-V)

轩墨 2019-12-01 22:06:08 2089 浏览量 回答数 0

问题

Git 改变了分布式 Web 开发规则:报错

kun坤 2020-06-08 11:09:24 3 浏览量 回答数 1

回答

Re会打字就会建网站:不限流量,免备案,免费试用。 现在是5G空间了。。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。     从网上找的网站程序不好维护,以后发现漏洞,不懂技术的用户就不会补漏洞;程序出故障,也没有人管,会很麻烦。     建议你用速成网站做网站,完全可以自己动手制作网站。有专业人员维护后台系统,让用户无后顾之忧。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 用的是阿里云美国机房,还是很稳定的。。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 找人或公司设计也不太好,如果联系不上对方了,或者是对方公司不做了,那也很麻烦。    ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 咱们论坛效果还不错,支持一下。。。。。。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 你可以选择在节假日或晚上(这种时间最能体现真实的服务水准),找客服沟通一下,看咱们客服是否在,服务如何,沟通3-5次后再确定。    ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 一定要找规模大的服务商,小的服务商不稳定;他们只是简单地在租几台服务器就开始卖虚拟主机了,虽然更便宜,但是不稳定,会使您的网站经常无法访问,影响您公司的形象及业务往来。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 如要在百度、GOOGLE等网站搜索到您的网站,有两种方式,一种是收费的广告服务;一种是免费的,即您在各论坛上宣传您的网站,过一段时间百度、GOOGLE这些网站会免费将您的网站收录到他们的数据库中。一般新网站做好后,过15天-3个月会自动被收录到这些大网站的数据库中,这时候就可以搜索到了。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。  关键是网站是否有原创的内容和经常保持更新,原创内容指你自己写的文章、报告等。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 也可以自己搭建模板,所有文字和图片都是可以改的 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。   速成网站主要是做展示类网站,简单的商城类网站也是可以的,但功能肯定比不上淘宝,目前付款方式只支持支付宝(即时到账),可实现会员注册登录购买等简单功能,不过一般建议客户在网站上放淘宝店铺的链接,指导客户到淘宝店中购买比较好。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。    国际版不能备案,所以用不了支付宝在线支付,支付宝在线支付(即时到账)要求:必须是企业或有执照的个体户;网站必须备案等,具体请见:支付宝官网介绍。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。         从网上找的网站程序不好维护,以后发现漏洞,不懂技术的用户就不会补漏洞;程序出故障,也没有人管,会很麻烦。         找人或公司设计也不太好,如果找不到对方了,或者是对方公司不做了,那也很麻烦。         建议你用速成网站做网站,完全可以自己动手制作网站。有专业人员维护后台系统,让用户无后顾之忧。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。     有一些服务商连在线客服也没有,有的有所谓在线客服,也是机器人,也不能解决客户的问题。     很多用户都是先沟通很长时间,然后再买的。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 注意:国内主机必须备案成功后才能用您自己的域名访问,网站备案一般需要10个工作日左右;个人网站备案后,不能放企业或产品类的内容。速成网站国际版不需要备案,不受备案限制。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 在备案平台备案时,请直接选择购买收费幕布(需自行支付邮费15元左右)。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 可以申请速成网站国际版做跳转,不需要备案。可通过跳转将您的域名指向到其他网址上,通过电脑和手机访问都可以实现跳转。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。   网站内容实时推送至百度搜索,平均仅需2天,即可实现原创内容极速收录!成倍放大SEO效果,更有利于网站推广。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 为什么选择速成网站做网站? 更安全!         从网上找的网站程序不好维护,以后发现漏洞,不懂技术的用户就不会补漏洞;程序出故障,也没有人管,会很麻烦。         找人或公司设计也不太好,如果找不到对方了,或者是对方公司不做了,那也很麻烦。         建议你用速成网站做网站,完全可以自己动手制作网站。有专业人员维护后台系统,让用户无后顾之忧。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 咱 在线上,可以 加 一下。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 首年费用是215元,包括:COM域名+速成网站国际版(5G阿里云空间,不需要备案,不限流量,可先试用一下)。续费:229元/年。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 如要在百度、GOOGLE等网站搜索到您的网站,有两种方式,一种是收费的广告服务;一种是免费的,即您在各论坛上宣传您的网站,过一段时间百度、GOOGLE这些网站会免费将您的网站收录到他们的数据库中。一般新网站做好后,过15天-3个月会自动被收录到这些大网站的数据库中,这时候就可以搜索到了。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 云邮箱是基于庞大的服务器集群构建的企业邮箱平台,在全球多个节点部署了多个中转集群,保证邮件在全球收发无阻。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。     速成网站国际版不用备案,即可直接使用;速成网站创业版等其他的主机网站必须备案。     速成网站-国际版(5G,不限流量,不需备案):160元/年     速成网站-创业版(5G,不限流量,需备案):165元/年 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。 国际版不能备案,所以用不了支付宝在线支付,支付宝在线支付(即时到账)要求:必须是企业或有执照的个体户;网站必须备案等,具体请见:支付宝官网介绍。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。     有一些服务商连在线客服也没有,有的有所谓在线客服,也是机器人,也不能解决客户的问题。     很多用户都是先沟通很长时间,然后再买的。 ------------------------- Re会打字就会建网站:不限流量,免备案,免费试用。   从2016年10月1日起,新购的速成网站(创业版、国际版、百度版)已扩容至20G。2016年10月1日以前购买的不变。价格不变。 -------------------------   从网上找的网站程序不好维护,以后发现漏洞,不懂技术的用户就不会补漏洞;程序出故障,也没有人管,会很麻烦。 -------------------------     可以改变域名注册商的,可转移到我们公司管理,可以教你一下。    COM 英文域名转入费是55元(包括一年续费)。     ------------------------- 有200多套网站模板可以选择,客户自助建站,不需要开发程序,可视化操作,动动鼠标就可以操作!有新手指导、学习视频,一般看半天就会做自己的网站了。 ------------------------- 你可以选择在节假日或晚上(这种时间最能体现真实的服务水准),找客服沟通一下,看咱们客服是否在,服务如何,沟通3-5次后再确定。     ------------------------- 赚钱三法则:不交费、不购买、不销售。不交费:就是不交任何费用;不购买:就是不买任何产品;不销售:就是不让你直接销售任何产品,所以你不需要进货。       ------------------------- 网站备案太麻烦了,用速成网站国际版不用备案就可以直接访问 -------------------------   网站备案太麻烦了,用速成网站国际版不用备案就可以直接访问 -------------------------     有一些服务商连在线客服也没有,有的有所谓在线客服,也是机器人,也不能解决客户的问题。    很多用户都是先沟通很长时间,然后再买的。 ------------------------- 建议你免费试用一下,有数百套模板可以选择,如果对模板不满意,还可以自己改模板。    主要功能包括:网页设计管理、商品展示和发布管理、文章管理、投票和调查问卷、会员管理、网站SEO、手机网站、商城功能等,不限流量。   ------------------------- 现在是200多套模板了。。。 ------------------------- 申请域名或主机请注意:这类产品大部分成本是服务。有一些服务商降低了价格,服务也下降了。不是找不到人,就是电话打不通,也没有工作人员在线支持,会很麻烦。一定要先咨询2-3个小时,问清楚了再说。 ------------------------- 这个用的是阿里云的服务器,还 很稳定的。 ------------------------- 现在.COM/NET/CN/COM.CN/NET.CN等域名也需要实名认证了。 -------------------------     速成网站国际版不用备案,即可直接使用;速成网站创业版等其他的主机网站必须备案。创业版比国际版要快一些。创业版用的是国内的服务器,国际版用的是美国的服务器。    速成网站-国际版(5G,阿里云美国服务器,不限流量,不需备案):160元/年    速成网站-创业版(10G,阿里云国内服务器,不限流量,需备案):165元/年 ------------------------- 申请域名或主机网站请注意:这类产品大部分成本是服务。有一些服务商降低了价格,服务也下降了。不是找不到人,就是电话打不通,也没有工作人员在线支持,会很麻烦。一定要先咨询5-7个小时,问清楚了再说。    可以找咱们。现在在线。 ------------------------- 一般先按一般公司提交,等他们要求时再按要求办就行了。 -------------------------    知道问答推广属精准营销,针对性强,事半功倍。例如需要做网站的客户一般会提交做网站相关的问题,很容易成为您的客户。几百个四级以上的老账号轮流推广,效果更好。可以加一下我。 ------------------------- 其他同类产品是1G空间,月流量15G,超过流量就不能访问了 -------------------------   百度知道问答推广属精准营销,针对性强,事半功倍,一条答复可能有几十甚至几百个用户查看,不像竞价排名,点一次钱就没了。例如需要做网站的客户一般会提交做网站相关的问题,答复后,客户通过搜索你的品牌名称或产品名称到你的网站,很容易成为您的客户。咱们有350多个四级以上超过5年的老账号轮流推广,效果更好。可以加一下我。 ------------------------- 这个用的是阿里云的服务器,稳定性和速度还是不错的。。 ------------------------- 找人设计或从网上下载网站程序都不安全,出现漏洞没有人管,所以还是用自助建站系统比较可靠些,由技术部负责网站后台系统的安全和维护,更省心。 ------------------------- 现在是300多套模板了,做一般民示类的网站足够用了。。

今日创业 2019-12-02 01:27:25 0 浏览量 回答数 0

回答

134题 其实就是水平扩容了,Zookeeper在这方面不太好。两种方式:全部重启:关闭所有Zookeeper服务,修改配置之后启动。不影响之前客户端的会话。逐个重启:这是比较常用的方式。 133题 集群最低3(2N+1)台,保证奇数,主要是为了选举算法。一个由 3 台机器构成的 ZooKeeper 集群,能够在挂掉 1 台机器后依然正常工作,而对于一个由 5 台服务器构成的 ZooKeeper 集群,能够对 2 台机器挂掉的情况进行容灾。注意,如果是一个由6台服务器构成的 ZooKeeper 集群,同样只能够挂掉 2 台机器,因为如果挂掉 3 台,剩下的机器就无法实现过半了。 132题 基于“过半”设计原则,ZooKeeper 在运行期间,集群中至少有过半的机器保存了最新的数据。因此,只要集群中超过半数的机器还能够正常工作,整个集群就能够对外提供服务。 131题 不是。官方声明:一个Watch事件是一个一次性的触发器,当被设置了Watch的数据发生了改变的时候,则服务器将这个改变发送给设置了Watch的客户端,以便通知它们。为什么不是永久的,举个例子,如果服务端变动频繁,而监听的客户端很多情况下,每次变动都要通知到所有的客户端,这太消耗性能了。一般是客户端执行getData(“/节点A”,true),如果节点A发生了变更或删除,客户端会得到它的watch事件,但是在之后节点A又发生了变更,而客户端又没有设置watch事件,就不再给客户端发送。在实际应用中,很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可。 130题 数据发布/订阅,负载均衡,命名服务,分布式协调/通知,集群管理,Master 选举,分布式锁,分布式队列 129题 客户端 SendThread 线程接收事件通知, 交由 EventThread 线程回调 Watcher。客户端的 Watcher 机制同样是一次性的, 一旦被触发后, 该 Watcher 就失效了。 128题 1、服务端接收 Watcher 并存储; 2、Watcher 触发; 2.1 封装 WatchedEvent; 2.2 查询 Watcher; 2.3 没找到;说明没有客户端在该数据节点上注册过 Watcher; 2.4 找到;提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher; 3、调用 process 方法来触发 Watcher。 127题 1.调用 getData()/getChildren()/exist()三个 API,传入 Watcher 对象 2.标记请求 request,封装 Watcher 到 WatchRegistration 3.封装成 Packet 对象,发服务端发送 request 4.收到服务端响应后,将 Watcher 注册到 ZKWatcherManager 中进行管理 5.请求返回,完成注册。 126题 Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听,当服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。工作机制:(1)客户端注册 watcher(2)服务端处理 watcher(3)客户端回调 watcher 125题 服务器具有四种状态,分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 LOOKING:寻 找 Leader 状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader 选举状态。 FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。 LEADING:领导者状态。表明当前服务器角色是 Leader。 OBSERVING:观察者状态。表明当前服务器角色是 Observer。 124题 Zookeeper 有三种部署模式:单机部署:一台集群上运行;集群部署:多台集群运行;伪集群部署:一台集群启动多个 Zookeeper 实例运行。 123题 Paxos算法是分布式选举算法,Zookeeper使用的 ZAB协议(Zookeeper原子广播),二者有相同的地方,比如都有一个Leader,用来协调N个Follower的运行;Leader要等待超半数的Follower做出正确反馈之后才进行提案;二者都有一个值来代表Leader的周期。不同的地方在于:ZAB用来构建高可用的分布式数据主备系统(Zookeeper),Paxos是用来构建分布式一致性状态机系统。Paxos算法、ZAB协议要想讲清楚可不是一时半会的事儿,自1990年莱斯利·兰伯特提出Paxos算法以来,因为晦涩难懂并没有受到重视。后续几年,兰伯特通过好几篇论文对其进行更进一步地解释,也直到06年谷歌发表了三篇论文,选择Paxos作为chubby cell的一致性算法,Paxos才真正流行起来。对于普通开发者来说,尤其是学习使用Zookeeper的开发者明确一点就好:分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。 122题 ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议(paxos算法的一种实现)。ZAB协议包括两种基本的模式:崩溃恢复和消息广播。当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时,所有进程(服务器)进入崩溃恢复模式,首先选举产生新的Leader服务器,然后集群中Follower服务器开始与新的Leader服务器进行数据同步,当集群中超过半数机器与该Leader服务器完成数据同步之后,退出恢复模式进入消息广播模式,Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。 121题 Zookeeper本身也是集群,推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时,其他节点会继续提供服务。如果是一个Follower宕机,还有2台服务器提供访问,因为Zookeeper上的数据是有多个副本的,数据并不会丢失;如果是一个Leader宕机,Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在ZK节点挂得太多,只剩一半或不到一半节点能工作,集群才失效。所以,3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5),2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)。 120题 选完Leader以后,zk就进入状态同步过程。1、Leader等待server连接;2、Follower连接leader,将最大的zxid发送给leader;3、Leader根据follower的zxid确定同步点;4、完成同步后通知follower 已经成为uptodate状态;5、Follower收到uptodate消息后,又可以重新接受client的请求进行服务了。 119题 在zookeeper集群中也是一样,每个节点都会投票,如果某个节点获得超过半数以上的节点的投票,则该节点就是leader节点了。zookeeper中有三种选举算法,分别是LeaderElection,FastLeaderElection,AuthLeaderElection, FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果,而是不断的统计结果,一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。 118题 zk的负载均衡是可以调控,nginx只是能调权重,其他需要可控的都需要自己写插件;但是nginx的吞吐量比zk大很多,应该说按业务选择用哪种方式。 117题 Zookeeper 的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和 leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 116题 有临时节点和永久节点,分再细一点有临时有序/无序节点,有永久有序/无序节点。当创建临时节点的程序结束后,临时节点会自动消失,临时节点上的数据也会一起消失。 115题 在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,这就是主节点存在的意义。 114题 ZooKeeper 实现分布式事务,类似于两阶段提交,总共分为以下 4 步:客户端先给 ZooKeeper 节点发送写请求;ZooKeeper 节点将写请求转发给 Leader 节点,Leader 广播给集群要求投票,等待确认;Leader 收到确认,统计投票,票数过半则提交事务;事务提交成功后,ZooKeeper 节点告知客户端。 113题 ZooKeeper 实现分布式锁的步骤如下:客户端连接 ZooKeeper,并在 /lock 下创建临时的且有序的子节点,第一个客户端对应的子节点为 /lock/lock-10000000001,第二个为 /lock/lock-10000000002,以此类推。客户端获取 /lock 下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听刚好在自己之前一位的子节点删除消息,获得子节点变更通知后重复此步骤直至获得锁;执行业务代码;完成业务流程后,删除对应的子节点释放锁。 112题 ZooKeeper 特性如下:顺序一致性(Sequential Consistency):来自相同客户端提交的事务,ZooKeeper 将严格按照其提交顺序依次执行;原子性(Atomicity):于 ZooKeeper 集群中提交事务,事务将“全部完成”或“全部未完成”,不存在“部分完成”;单一系统镜像(Single System Image):客户端连接到 ZooKeeper 集群的任意节点,其获得的数据视图都是相同的;可靠性(Reliability):事务一旦完成,其产生的状态变化将永久保留,直到其他事务进行覆盖;实时性(Timeliness):事务一旦完成,客户端将于限定的时间段内,获得最新的数据。 111题 ZooKeeper 通常有三种搭建模式:单机模式:zoo.cfg 中只配置一个 server.id 就是单机模式了,此模式一般用在测试环境,如果当前主机宕机,那么所有依赖于当前 ZooKeeper 服务工作的其他服务器都不能进行正常工作;伪分布式模式:在一台机器启动不同端口的 ZooKeeper,配置到 zoo.cfg 中,和单机模式相同,此模式一般用在测试环境;分布式模式:多台机器各自配置 zoo.cfg 文件,将各自互相加入服务器列表,上面搭建的集群就是这种完全分布式。 110题 ZooKeeper 主要提供以下功能:分布式服务注册与订阅:在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑,比较典型的服务注册与订阅,如 Dubbo。分布式配置中心:发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到 ZooKeeper 节点上,供订阅者获取数据,实现配置信息的集中式管理和动态更新。命名服务:在分布式系统中,通过命名服务客户端应用能够根据指定名字来获取资源、服务地址和提供者等信息。分布式锁:这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。 109题 Dubbo是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代,考虑的是微服务治理的方方面面,另外由于依托了 Spirng、Spirng Boot的优势之上,两个框架在开始目标就不一致,Dubbo 定位服务治理、Spirng Cloud 是一个生态。 108题 Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。 107题 Dubbo超时时间设置有两种方式: 服务提供者端设置超时时间,在Dubbo的用户文档中,推荐如果能在服务端多配置就尽量多配置,因为服务提供者比消费者更清楚自己提供的服务特性。 服务消费者端设置超时时间,如果在消费者端设置了超时时间,以消费者端为主,即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时,服务端线程不会定制,会产生警告。 106题 Random LoadBalance: 随机选取提供者策略,有利于动态调整提供者权重。截面碰撞率高,调用次数越多,分布越均匀; RoundRobin LoadBalance: 轮循选取提供者策略,平均分布,但是存在请求累积的问题; LeastActive LoadBalance: 最少活跃调用策略,解决慢提供者接收更少的请求; ConstantHash LoadBalance: 一致性Hash策略,使相同参数请求总是发到同一提供者,一台机器宕机,可以基于虚拟节点,分摊至其他提供者,避免引起提供者的剧烈变动; 缺省时为Random随机调用。 105题 Consumer(消费者),连接注册中心 ,并发送应用信息、所求服务信息至注册中心。 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。 Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。 Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer。 104题 Provider:暴露服务的服务提供方。 Consumer:调用远程服务的服务消费方。 Registry:服务注册与发现的注册中心。 Monitor:统计服务的调用次调和调用时间的监控中心。 Container:服务运行容器。 103题 主要就是如下3个核心功能: Remoting:网络通信框架,提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式。 Cluster:服务框架,提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。 Registry:服务注册,基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。 102题 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。 101题 垂直分表定义:将一个表按照字段分成多表,每个表存储其中一部分字段。水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。 100题 垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。水平分库是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。 99题 QPS:每秒查询数。TPS:每秒处理事务数。Uptime:服务器已经运行的时间,单位秒。Questions:已经发送给数据库查询数。Com_select:查询次数,实际操作数据库的。Com_insert:插入次数。Com_delete:删除次数。Com_update:更新次数。Com_commit:事务次数。Com_rollback:回滚次数。 98题 如果需要跨主机进行JOIN,跨应用进行JOIN,或者数据库不能获得较好的执行计划,都可以自己通过程序来实现JOIN。 例如:SELECT a.,b. FROM a,b WHERE a.col1=b.col1 AND a.col2> 10 ORDER BY a.col2; 可以利用程序实现,先SELECT * FROM a WHERE a.col2>10 ORDER BY a.col2;–(1) 利用(1)的结果集,做循环,SELECT * FROM b WHERE b.col1=a.col1; 这样可以避免排序,可以在程序里控制执行的速度,有效降低数据库压力,也可以实现跨主机的JOIN。 97题 搭建复制的必备条件:复制的机器之间网络通畅,Master打开了binlog。 搭建复制步骤:建立用户并设置权限,修改配置文件,查看master状态,配置slave,启动从服务,查看slave状态,主从测试。 96题 Heartbeat方案:利用Heartbeat管理VIP,利用crm管理MySQL,MySQL进行双M复制。(Linux系统下没有分库的标准方案)。 LVS+Keepalived方案:利用Keepalived管理LVS和VIP,LVS分发请求到MySQL,MySQL进行双M复制。(Linux系统下无分库无事务的方案)。 Cobar方案:利用Cobar进行HA和分库,应用程序请求Cobar,Cobar转发请求道数据库。(有分库的标准方案,Unix下唯一方案)。 95题 聚集(clustered)索引,也叫聚簇索引,数据行的物理顺序与列值(一般是主键的那一列)的逻辑顺序相同,一个表中只能拥有一个聚集索引。但是,覆盖索引可以模拟多个聚集索引。存储引擎负责实现索引,因此不是所有的存储索引都支持聚集索引。当前,SolidDB和InnoDB是唯一支持聚集索引的存储引擎。 优点:可以把相关数据保存在一起。数据访问快。 缺点:聚集能最大限度地提升I/O密集负载的性能。聚集能最大限度地提升I/O密集负载的性能。建立在聚集索引上的表在插入新行,或者在行的主键被更新,该行必须被移动的时候会进行分页。聚集表可会比全表扫描慢,尤其在表存储得比较稀疏或因为分页而没有顺序存储的时候。第二(非聚集)索引可能会比预想的大,因为它们的叶子节点包含了被引用行的主键列。 94题 以下原因是导致mysql 表毁坏的常见原因: 服务器突然断电导致数据文件损坏; 强制关机,没有先关闭mysql 服务; mysqld 进程在写表时被杀掉; 使用myisamchk 的同时,mysqld 也在操作表; 磁盘故障;服务器死机;mysql 本身的bug 。 93题 1.定位慢查询 首先先打开慢查询日志设置慢查询时间; 2.分析慢查询(使用explain工具分析sql语句); 3.优化慢查询 。

游客ih62co2qqq5ww 2020-06-15 13:55:41 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 SSL证书 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 2020中国云原生 阿里云云栖号