ZooKeeper详解

ZooKeeper 是什么ZooKeeper 是一个开源的分布式协调服务。它是一个为分布式应用提供一致性服务的软件分布式应用程序可以基于 Zookeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。ZooKeeper 的目标就是封装好复杂易出错的关键服务将简单易用的接口和性能高效、功能稳定的系统提供给用户。Zookeeper 保证了如下分布式一致性特性顺序一致性原子性单一视图可靠性实时性最终一致性客户端的读请求可以被集群中的任意一台机器处理如果读请求在节点上注册了监听器这个监听器也是由所连接的 zookeeper 机器来处理。对于写请求这些请求会同时发给其他 zookeeper 机器并且达成一致后请求才会返回成功。因此随着 zookeeper 的集群机器增多读请求的吞吐会提高但是写请求的吞吐会下降。有序性是 zookeeper 中非常重要的一个特性所有的更新都是全局有序的每个更新都有一个唯一的时间戳这个时间戳称为 zxidZookeeper Transaction Id。而读请求只会相对于更新有序也就是读请求的返回结果中会带有这个zookeeper 最新的 zxid。ZooKeeper 设计目标简单的数据模型ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调这与标准文件系统类似。 名称空间由 ZooKeeper 中的数据寄存器组成 - 称为znode这些类似于文件和目录。 与为存储设计的典型文件系统不同ZooKeeper数据保存在内存中这意味着ZooKeeper可以实现高吞吐量和低延迟。​编辑可构建集群为了保证高可用最好是以集群形态来部署 ZooKeeper这样只要集群中大部分机器是可用的能够容忍一定的机器故障那么zookeeper本身仍然是可用的。 客户端在使用 ZooKeeper 时需要知道集群机器列表通过与集群中的某一台机器建立 TCP 连接来使用服务客户端使用这个TCP链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了客户端可以连接到另外的机器上。ZooKeeper 官方提供的架构图​编辑上图中每一个Server代表一个安装Zookeeper服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态并且每台服务器之间都互相保持着通信。集群间通过 Zab 协议Zookeeper Atomic Broadcast来保持数据的一致性。顺序访问对于来自客户端的每个更新请求ZooKeeper 都会分配一个全局唯一的递增编号这个编号反应了所有事务操作的先后顺序应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。 这个编号也叫做时间戳——zxidZookeeper Transaction Id高性能ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地高性能因为“写”会导致所有的服务器间同步状态。“读”多于“写”是协调服务的典型场景。ZooKeeper 提供了什么文件系统通知机制Zookeeper 文件系统Zookeeper 提供一个多层级的节点命名空间节点称为 znode。与文件系统不同的是这些节点都可以设置关联的数据而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper 为了保证高吞吐和低延迟在内存中维护了这个树状的目录结构这种特性使得 Zookeeper 不能用于存放大量的数据每个节点的存放数据上限为1M。Zookeeper 怎么保证主从节点的状态同步Zookeeper 的核心是原子广播机制这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式它们分别是恢复模式和广播模式。恢复模式当服务启动或者在领导者崩溃后Zab就进入了恢复模式当领导者被选举出来且大多数 server 完成了和 leader 的状态同步以后恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。广播模式一旦 leader 已经和多数的 follower 进行了状态同步后它就可以开始广播消息了即进入广播状态。这时候当一个 server 加入 ZooKeeper 服务中它会在恢复模式下启动发现 leader并和 leader 进行状态同步。待到同步结束它也参与消息广播。ZooKeeper 服务一直维持在 Broadcast 状态直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。四种类型的数据节点 Znode持久节点除非手动删除否则节点一直存在于 Zookeeper 上临时节点临时节点的生命周期与客户端会话绑定一旦客户端会话失效客户端与zookeeper 连接断开不一定会话失效那么这个客户端创建的所有临时节点都会被移除。持久顺序节点基本特性同持久节点只是增加了顺序属性节点名后边会追加一个由父节点维护的自增整型数字。临时顺序节点基本特性同临时节点增加了顺序属性节点名后边会追加一个由父节点维护的自增整型数字。Zookeeper 的典型应用场景Zookeeper 是一个典型的发布/订阅模式的分布式数据管理与协调框架开发人员可以使用它来进行分布式数据的发布和订阅。通过对 Zookeeper 中丰富的数据节点进行交叉使用配合 Watcher 事件通知机制可以非常方便的构建一系列分布式应用中年都会涉及的核心功能如数据发布/订阅负载均衡命名服务分布式协调/通知集群管理Master 选举分布式锁分布式队列Zookeeper的通知机制客户端端会对某个 znode 建立一个 watcher 事件当该 znode 发生变化时这些客户端会收到 zookeeper 的通知然后客户端可以根据 znode 变化来做出业务上的改变。Zookeeper的分布式锁实现方式在讲zk分布锁之前先看下zookeeper中几个关于节点的有趣的性质有序节点假如当前有一个父节点为/lock我们可以在这个父节点下面创建子节点zookeeper提供了一个可选的有序特性例如我们可以创建子节点“/lock/node-”并且指明有序那么zookeeper在生成子节点时会根据当前的子节点数量自动添加整数序号也就是说如果是第一个创建的子节点那么生成的子节点为/lock/node-0000000000下一个节点则为/lock/node-0000000001依次类推。临时节点客户端可以建立一个临时节点在会话结束或者会话超时后zookeeper会自动删除该节点。事件监听在读取数据时我们可以同时对节点设置事件监听当节点数据或结构变化时zookeeper会通知客户端。当前zookeeper有如下四种事件 1、节点创建2、节点删除3、节点数据修改4、子节点变更。下面描述使用zookeeper实现分布式锁的算法流程假设锁空间的根节点为/lock客户端连接zookeeper并在/lock下创建临时的且有序的子节点第一个客户端对应的子节点为/lock/lock-0000000000第二个为/lock/lock-0000000001以此类推。客户端获取/lock下的子节点列表判断自己创建的子节点是否为当前子节点列表中序号最小的子节点如果是则认为获得锁否则监听/lock的子节点变更消息获得子节点变更通知后重复此步骤直至获得锁执行业务代码完成业务流程后删除对应的子节点释放锁。Zookeeper 采用的哪种分布式一致性协议? 还有哪些分布式一致性协议zab协议是zookeeper专门设计的支持崩溃恢复的原子广播协议。目的是实现分布式zoopkeeper各个节点数据一致性。zab协议约定zk节点有两种角色leader和follower,zk客户端会随机的链接到 zookeeper 集群中的一个节点如果是读请求就直接从当前节点中读取数据如果是写请求那么节点就会向 Leader 提交事务Leader 接收到事务提交会广播该事务只要超过半数节点写入成功该事务就会被提交。ZAB协议包括两种基本的模式消息广播和崩溃恢复。整个 Zookeeper 就是在这两个模式之间切换。 简而言之当 Leader 服务可以正常使用就进入消息广播模式当 Leader 不可用时则进入崩溃恢复模式。以上其实大致经历了三个步骤崩溃恢复主要就是Leader选举过程。数据同步Leader服务器与其他服务器进行数据同步。消息广播Leader服务器将数据发送给其他服务器。支持崩溃恢复后数据准确性的就是数据同步了数据同步基于事务的 ZXID 的唯一性来保证。通过 1 操作可以辨别事务的先后顺序。ZAD和Paxos算法的联系和区别共同点两者都存在一个类似于Leader进程的角色由其负责协调多个Follow进程的运行。Leader进程都会等待超过半数的Follower做出正确的反馈后才会将一个提案进行提交。在ZAB协议中每个Proposal中都包含了一个epoch值用来代表当前Leader周期在Paxos算法中同样存在这样一个标识只是名字变成了Ballot。 不同点Paxos算法中一个新的选举产生的主进程会进行两个阶段的工作读阶段新的主进程会通过和所有其他进程进行通信的方式来搜集上一个主进程提出的提案并将它们提交。写阶段当前主进程开始提出它自己的提案。ZAB在Paxos基础上额外添加一个同步阶段。同步阶段之前ZAB协议存在一个和Paxos读阶段类似的发现Discovery阶段同步阶段中新的Leader会确保存在过半的Follower已经提交了之前Leader周期中的所有事务Proposal发现阶段的存在确保所有进程都已经完成对之前所有事物Proposal的提交ZAB协议主要用于构建一个高可用的分布式数据主备系统例如ZooKeeperPaxos算法则是用于构建一个分布式的一致性状态机系统Zookeeper 是怎样保证主从节点的状态同步Zookeeper的核心是原子广播这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式它们分别是恢复模式选主和广播模式同步。恢复模式当服务启动或者在领导者崩溃后Zab就进入了恢复模式当领导者被选举出来且大多数Server完成了和leader的状态同步以后恢复模式就结束了。因此选主得到的leader保证了同步状态的进行状态同步又保证了leader和Server具有相同的系统状态当leader失去主权后可以在其他follower中选主新的leader。集群中为什么要有主节点在分布式环境中有些业务逻辑只需要集群中的某一台机器进行执行其他的机器可以共享这个结果这样可以大大减少重复计算提高性能所以就需要主节点leader 选举过程有两种情况会发起Leader选举服务器启动的时候服务器运行的时候当Leader宕机在讲解流程之前先说明一下选举流程中涉及到的角色LOOKING寻找Leader状态处于该状态需要进入选举流程只有该节点才可以投票LEADING领导者状态处于该状态的节点说明是角色已经是LeaderFOLLOWING跟随者状态表示Leader已经选举出来当前节点角色是followerOBSERVER观察者状态表明当前节点角色是observer该节点不参与竞选三个核心选举原则Zookeeper集群中只有超过半数以上的服务器启动集群才能正常工作在集群正常工作之前myid小的服务器给myid大的服务器投票直到集群正常工作选出Leader选出Leader之后之前的服务器状态由Looking改变为Following以后的服务器都是Follower。下面以一个简单的例子来说明整个选举的过程假设有五台服务器组成的Zookeeper集群它们的id从1-5同时它们都是最新启动的也就是没有历史数据在存放数据量这一点上都是一样的。假设这些服务器从id1-5依序启动因为一共5台服务器只有超过半数以上即最少启动3台服务器集群才能正常工作。1服务器1启动发起一次选举。服务器1投自己一票。此时服务器1票数一票不够半数以上3票选举无法完成服务器1状态保持为LOOKING2服务器2启动再发起一次选举。服务器1和2分别投自己一票此时服务器1发现服务器2的id比自己大更改选票投给服务器2此时服务器1票数0票服务器2票数2票不够半数以上3票选举无法完成服务器12状态保持LOOKING3服务器3启动发起一次选举。与上面过程一样服务器1和2先投自己一票然后因为服务器3id最大两者更改选票投给为服务器3此次投票结果服务器1为0票服务器2为0票服务器3为3票。此时服务器3的票数已经超过半数3票服务器3当选Leader。服务器12更改状态为FOLLOWING服务器3更改状态为LEADING4服务器4启动发起一次选举。此时服务器123已经不是LOOKING状态不会更改选票信息。交换选票信息结果服务器3为3票服务器4为1票。此时服务器4服从多数更改选票信息为服务器3服务器4并更改状态为FOLLOWING5服务器5启动同4一样投票给3此时服务器3一共5票服务器5为0票服务器5并更改状态为FOLLOWING6选举结果最终Leader是服务器3状态为LEADING其余服务器是Follower状态为FOLLOWING。Zookeeper与Eureka的区别结构上1、Zookeeper是主从架构 2、Eureka是点对点节点都是平级的高可用与强一致性1、Zookeeper当master挂了会在30-120s进行leader选举这点类似于redis的哨兵机制在选举期间Zookeeper是不可用的这么长时间不能进行服务注册是无法忍受的别说30s5s都不能忍受。这时Zookeeper集群会瘫痪这也是Zookeeper的CP保持节点的一致性牺牲了A/高可用。而Eureka不会这就是AP牺牲了C/一致性。2、即使Eureka有部分挂掉还有其他节点可以使用的他们保持平级的关系只不过信息有可能不一致。当坏掉的服务恢复的时候会自动加入到节点上也是高可用的一种。然后退出自我保护机制这也是应对网络异常的一种机制Eureka的自我保护机制在默认配置中Eureka Server在默认90s没有得到客户端的心跳则注销该实例但是往往因为微服务跨进程调用网络通信往往会面临着各种问题比如微服务状态正常但是因为网络分区故障时Eureka Server注销服务实例则会让大部分微服务不可用这很危险因为服务明明没有问题。为了解决这个问题Eureka 有自我保护机制通过在Eureka Server配置如下参数可启动保护机制eureka.server.enable-self-preservationtrue如果在15分钟内超过85%的节点都没有正常的心跳那么Eureka就认为客户端与注册中心出现了网络故障此时会出现以下几种情况Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务Eureka仍然能够接受新服务的注册和查询请求但是不会被同步到其它节点上(即保证当前节点依然可用)当网络稳定时当前实例新的注册信息会被同步到其它节点中它的原理是当Eureka Server节点在短时间内丢失过多的客户端时可能发送了网络故障那么这个节点将进入自我保护模式不再注销任何微服务当网络故障恢复后该节点会自动退出自我保护模式。自我保护模式的架构哲学是宁可放过一个决不可错杀一千