zookeeper详解

目录

一、什么是zookeeper？

二、znode节点类型

三、ZAB协议（ZooKeeper Atomic Broadcast 原子广播）

四、zookeeper怎么保证事务请求一致性（二阶段提交）

五、集群选主

六、分布式锁

---

一、什么是zookeeper？

zookeeper是一个开源的分布式协调服务，是一个典型的分布式数据一致性解决方案。

zk属于cap中的cp，保证一致性，崩溃回复时分钟级不可用，但其实为弱一致性
可以实现：命名服务（节点类似于文件系统）、配置管理（watcher机制）、分布式锁、集群管理（dubbo的注册中心）。
可以保证：

• 顺序一致性（同一个客户端发起的事务请求，会严格按照顺序执行）
• 原子性（执行一个事务，整个集群要么全部成功，要么全部失败）
• 单一视图（无论客户端连接那台服务器，看到的数据相同）
• 可靠性（服务端成功执行事务后变更状态会保留下来）
• 实时性（Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper 不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用 sync()接口）

二、znode节点类型

• 持久化节点：客户端与zookeeper断开连接后，节点依然存在
• 持久化顺序节点：客户端与zookeeper断开连接后，节点依然存在，zookeeper会给该节点名称进行顺序编号
• 临时节点：客户端与zookeeper断开连接后，节点删除
• 临时顺序节点：客户端与zookeeper断开连接后，节点删除，zookeeper会给该节点名称进行顺序编号

zookeeper限制只有持久节点才能有子节点，dubbo中的zookeeper存储服务节点时要用持久化节点，存储服务的地址节点要用临时顺序节点，因为同一个服务可能会有多个地址，且地址失效要及时移除。

三、ZAB协议（ZooKeeper Atomic Broadcast 原子广播）

在zookeeper中，主要依赖ZAB协议来实现分布式数据一致性。ZAB协议包括两种基本的模式，分别是崩溃恢复（集群选主）和消息广播（事务二阶段提交）。当整个服务框架在启动过程中，或是当 Leader服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的 Leader 服务器。leader选举成功后，采用原子广播协议，将服务器数据的状态变更为以事务的形式广播到所有的follower上去，该协议保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更。

四、zookeeper怎么保证事务请求一致性（二阶段提交）

客户端的所有非事务请求（比如get或exist）任何节点都能自行处理。但客户端的所有写请求（事务请求）都由leader接收，将事务请求转化为一个提议（proposal）分发给集群中的所有follower，分发后需要等待所有的follower的反馈（ACK请求），只要超过半数的follower进行了正确的反馈后，leader再次向所有的follower发送commit消息，要求将事务提交。

五、集群选主

zookeeper集群中有三种角色：leader（接收所有写请求并协调消息广播）、follower（为客户端提供读服务，参与投票，同步leader的提议）、observer（为了提高读的性能，又不影响投票效率）。
每个服务器在工作过程中有四种状态：LOOKING竞选状态、LEADING领导者状态、FOLLOWING随从状态、OBSERVING观察状态。
投票信息：sid机器序号、zxid事务id号。zookeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid。由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生。
规则：（1）初始阶段都会给自己投票 （2）当接收到别的服务器的投票时，先检查zxid，zxid大的优先作为leader，若zxid一样则再比较sid。

举例
假设当前集群中有5台机器组成。sid分别为1，2，3，4，5。zxid分别为9，9，9，8，8，并且此时sid为2的机器是leader。某一时刻，1和2的服务器挂掉了，集群开始进行选主。
在第一次投票中，由于无法检测到集群中其他机器的状态信息，因此每台机器都将自己作为被推举的对象来进行投票。于是sid为3，4，5的机器，投票情况分别为（3，9），（4，8），（5，8）
每台机器把投票发出后，同时也会接收到来自另外两台机器的投票。
对于server3来说，接收到（4，8），（5，8）的投票，对比后由于自己的zxid要大于收到的另外两个投票，因此不需要做任何变更。
对于server4来说，接收到（3，9），（5，8）的投票，对比后由于（3，9）这个投票的zxid大于自己，因此需要变更投票为（3，9），然后继续将这个投票发送给另外两台机器。
对于server5来说，接收到（3，9），（4，8）的投票，对比后由于（3，9）这个投票的zxid大于自己，因此需要变更投票为（3，9），然后继续将这个投票发送给另外两台机器。
经过第二轮投票后，集群中的每台机器都会再次受到其他机器的投票，然后开始统计投票。判断是否有过半的机器收到相同的投票信息，如果有，那么该投票的sid会成为新的leader。
机器总数为5台，server3，4，5都收到投票（3，9）。因此server3成为leader。

六、分布式锁

锁服务可以分为两类

• 独占锁，就是所有试图来获取这个锁的客户端，最终只有一个可以成功获得这把锁。通常的做法是把 zk 上的一个 znode 看作是一把锁，通过 create znode 的方式来实现。所有客户端都去创建节点，最终成功创建的那个客户端也即拥有了这把锁。
• 时序锁，就是所有试图来获取这个锁的客户端，最终都是会被安排执行，只是有个全局时序了。如果有客户端争抢一个zk分布式锁，大家都是上来直接创建一个锁节点下的一个接一个的临时顺序节点，如果自己不是第一个节点，就对自己上一个节点加监听器，只要上一个节点释放锁，自己就排到前面去了，相当于是一个排队机制。而且用临时顺序节点的另外一个用意就是，如果某个客户端创建临时顺序节点之后，不小心自己宕机了也没关系，zk感知到那个客户端宕机，会自动删除对应的临时顺序节点，相当于自动释放锁，或者是自动取消自己的排队。

参考：
https://www.jianshu.com/p/75e48405d678
https://blog.csdn.net/weixin_43113679/article/details/99679454