Zookeeper的工作原理

转自：https://blog.csdn.net/u013679744/article/details/79240249

Zookeeper使用了ZAB(Zookeeper Atomic Broadcast)协议，进行了消息广播，崩溃恢复，数据同步

基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性，同时其崩溃恢复过程也确保zk集群的高可用性,所以Leader是主，follower是备是副本？

Zookeeper使用一个单一主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上，并且ZAB协议能够保证一个全局的变更序列。

ZAB协议的核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式。当有写请求时，就把事务提交给loader,loader会广播这个事务让所有的副本都写入这个数据

Zookeeper 客户端会随机连接到 Zookeeper 集群的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求且当前节点不是leader，那么节点就会向 leader 提交事务，leader 会广播事务，只要有超过半数节点写入成功，该写请求就会被提交（类 2PC 协议）。

那么问题来了：

主从架构下，leader 崩溃，数据一致性怎么保证？
选举 leader 的时候，整个集群无法处理写请求,所以自然不会有数据一致性的问题

如何快速进行 leader 选举？
所以zab协议重要的就是：1. 消息广播协议（leader向其他节点广播事务）  2. leader选举（快速选举过程fast leader election，集群刚启动时(还没有loader)，leader崩溃或leader与集群中超过一半的节点断连后(整个集群没法用)） 3. leader重新选举后，如何进行数据同步到一致状态

事务ID的概念

在 ZAB 协议的事务编号 Zxid 设计中，Zxid 是一个 64 位的数字，其中低 32 位是一个简单的单调递增的计数器，针对客户端每一个事务请求，计数器加 1；而高 32 位则代表 Leader 周期 epoch 的编号，每选产生一个新的 Leader 服务器时，就会从这个 Leader 服务器上取出其本地日志中最大事务的ZXID(因为所有follower的事务是一样的)，并从中读取 epoch 值，然后加 1，以此作为新的 epoch，并将低 32 位从 0 开始计数。

epoch：可以理解为当前集群所处的年代或者周期，每个 leader 就像皇帝，都有自己的年号，所以每次改朝换代，leader 变更之后，都会在前一个年代的基础上加 1。这样就算旧的 leader 崩溃恢复之后，也没有人听他的了，因为 follower 只听从当前年代的 leader 的命令。

ZAB协议的两种基本模式：崩溃恢复模式和消息广播模式。其过程为：

当系统启动或leader服务器出现故障时，进入故障恢复模式，将会开启新的一轮选举，选举产生的leader会与过半的follower进行同步，使数据一致，当与过半的机器同步完成后，就退出恢复模式，进入消息广播模式。当一台遵从zab协议的服务器启动时，如果检测到leader在广播消息，会自动进入恢复模式，当其完成与leader的同步之后，则进入广播模式。所以，zk还可以保证易扩展性。（没进行数据同步，就不能加入真正可用的follower列表）