Zookeeper 基础学习

ZK 是干什么的

分布式解决了用户量不断增加的问题，但是分布式所带来的问题也不少，比如在一个分布式系统中如何确保被 RPC 调用的机器存活呢？使用 TCP 三次握手来解决？不行，速度太慢。为此我们去使用一些机器来通知调用方被调用方是否存活

那这些机器需要什么功能呢，首先它们应该保证高可用，如果自身的高可用都不能保证又如何去维持分布式程序的高可用呢，因此它们应该进行集群配置，并且集群应该保证强一致性

为了管理分布式程序的各个机器，它们需要存放一些代表各个机器的数据，并且读数据的速度要快，因此他们的数据应该存放在内存中

最后它应该有一些通知回调功能，当被调用方挂了应该及时告知调用方发生了什么事情

最后，我们得出结论，ZK 提供分布式协同服务，解决出现在分布式系统中出现的一系列问题，它的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用

ZooKeeper 将数据保存在内存中，性能是非常棒的。 在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态

拥有这些特性，它不止能做注册中心，还可以做分布式锁、命名服务等

数据结构

结构

使用多叉树结构，每个节点都可以存放数据，不过存放的数据比较少，最多只有1mb。它的数据存放在内存中，因此性能很好

zookeeper 中的节点叫 znode，根节点叫/，下面的节点一般以 /XXX，/XXX/XX 来命名

类型

znode 分为两大类型（持久节点、短暂节点），四种类型，分别是：

持久：这个节点一直存放在 zookeeper 中，直到被 delete
短暂：这个节点被某个会话写入，当连接断开，这个节点消失，这个节点不可以创建子节点（session被看作一个tcp长连接）
持久编号：这个节点有自己的id和持久节点的性质
短暂编号：这个节点有自己的id和短暂节点的性质

stat 与 data

在 Linux 中这个命令用来获取文件属性，在 ZK 中做为一个名词也是相似的功能

每个 znode 除了存放数据，还会自动维持一个叫 stat 的数据结构，stat 中存放了这个节点的所有信息，比如事务 ID、节点创建时间、当前节点的子节点个数等

data 指的是节点存放的数据的具体内容

监听器 watcher

监听器是观察者模式的一种实现，观察者模式指在出现一对多关系依赖的时候，会有一个观察者或者一群观察者在旁边观察，如果某个被依赖对象出现修改时，观察者会自动通知依赖它的对象

zkClent 代表客户端，它会创建一个 connect 连接 zookeeper，还有一个端口用来接受 zookeeper 传来的消息

客户端可以指定它要监听哪一个节点，当这个节点或者子节点发生变化时（可能是节点中数据变化或者节点直接变化），zookeeper 返回消息给客户端

zookeeper 使用一个链表来存放客户端以及它对应监听的节点

集群

为了保证高可用，可以以集群形态来部署 zookeeper，集群中使用 ZAB 协议保证数据一致性

架构

与传统的主从模式不同，ZK 使用 Leader、Follower、Observer 来实现集群

• Leader用来实现数据的写入和读取，主要负责写入
• Follower只能进行数据的读取，如果客户端需要实现写入请求时，它会转交给Leader实现
• Observer用来实现数据的读取，它不参加选举以及半数相关的操作，它用来提高集群数据读取效率

选举机制

当Leader挂掉或者集群建立的时候需要选择Leader，只有当前集群存活大于一半的主机才会执行此步骤，此时所有的服务器会按一定顺序进行选举，此时所有的机器处于LOOKING状态

一个新加入选举的服务器会先投自己一票，其他已经投过票的会把票投给最大 id 的服务器，直到某个机器获得超过一半的票数成为Leader

选举完毕Leader全量复制自己的数据给所有Follower，复制完成后对外提供服务，如果有数据写入会进行增量复制

配置奇数台机器

zookeeper集群中有这样一个特性，如果这个集群中超过一半的机器可用，这个集群可用。此外，选举中半数投票、半数写成功策略也是一半可以进行

因为这些特性，配置5台机器和配置6台机器允许的出错数量是一样的，所以配置奇数台机器可以省下一台机器的钱

同时，ZooKeeper 选举的过半机制还防止了脑裂。比如现在有一个由 6 台服务器所组成的一个集群，部署在了 2 个机房，每个机房 3 台。正常情况下只有 1 个 leader，但是当两个机房中间网络断开的时候，每个机房的 3 台服务器都会认为另一个机房的 3 台服务器下线，而选出自己的 leader 并对外提供服务。若没有过半机制，当网络恢复的时候会发现有 2 个 leader。仿佛是 1 个大脑（leader）分散成了 2 个大脑，这就发生了脑裂现象。脑裂期间 2 个大脑都可能对外提供了服务，这将会带来数据一致性等问题

ZooKeeper 的过半机制导致不可能产生 2 个 leader，因为少于等于一半是不可能产生 leader 的

一致性协议

在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。 如果对第一个节点的数据进行了更新操作并且更新成功后,却没有使得第二个节点上的数据得到相应的更新，于是在对第二个节点的数据进行读取操作时，获取的依然是老数据 (或称为脏数据)，这就是典型的分布式数据不一致情况

一致性协议有一个重要前提，在不可靠信道上试图通过消息传递的方式达到一致性是不可能的

如何知道对方机器是否出现故障

zookeeper有一个心跳帧（可以在配置文件中修改），默认为2秒，当机器之间发送消息的时候重新计时

在初始化连接时，超过10个心跳没有回应则认为对方挂了，在配置文件的对应参数为 initlimit

在正常连接时，超过5个心跳没有回应则认为对方挂了，在配置文件的对应参数为 synlimit

Paxos 算法

Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一

这个算法主要由提案者、表决者、学习者组成

首先每个提案者在提出提案时都会首先获取到一个具有全局唯一性的、递增的提案编号N，然后将这个编号发送给所有的表决者

每个表决者中保存的已经被接受的提案中会存在一个编号最大的提案，将这个编号返回给提案者

如果提案者接受到了半数以上的回应，将这个提案的内容发送给所有表决者，表决者只会同意大于等于自身编号最大的提案，如果提案者接受到了半数以上的同意，向未批准的表决者发送提案内容和提案编号并让它无条件执行和提交

如果这个过程失败会递增该提案的编号

ZAB 协议

ZAB 协议由 paxos 算法改编而来

简单来说就是进行修改时 Leader 问 Followers 是否同意更新，如果超过半数以上的同意那么就进行 Follower 和 Observer 的更新

Leader 内部维持着一个队列，在数据更新时会按照先进先出的形式发送数据给 Follower，这是因为请求处理的顺序不同就会导致数据的不同，从而产生数据不一致问题

ZAB协议有两种模式：

崩溃恢复：当 Leader 崩溃后的选主过程，当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式

消息广播：集群中对数据同步的过程

应用场景

分布式锁

zookeeper在多线程情况下只会创建全局的唯一节点

利用这个特性，将某个临时节点当作锁，一个连接创建这个节点代表这个连接抢到了锁，其他链接需要等待，当这个连接下线或者删除节点时（redis中需要考虑连接下线情况），锁被释放

注册中心

作为dubbo的注册中心使用，每个服务器创建临时节点，里面存放可提供的服务，web网页作为客户端连接zookeeper，在需要时查找自己想要的服务，将服务器的IP、方法等信息存放到自己的缓存中

客户端使用watcher监视zookeeper中的节点，如果服务器挂掉，zookeeper会发送消息给客户端（不使用watcher的话zookeeper也可以自动发送替代的服务器信息给客户端）

命名服务

对于每个节点的全路径，它必定是唯一的，我们可以使用节点的全路径作为命名方式了。而且更重要的是，路径是我们可以自己定义的，这对于我们对有些有语意的对象的ID设置可以更加便于理解