Zookeeper的核心原理

分布式锁原理

​ 利用临时有序节点实现

​ 节点下最小的节点获取锁

​ 其余节点监听比他小的节点

​ 避免了惊群效应

Zookeeper的数据同步原理

​ 读请求：可直接从当前节点读取数据

​ 写请求：转发到leader，leader广播事务请求，半数通过写入成功

问题？

​ leader如何选择？

​ 启动选举

​ leader节点崩溃后选举

​ 数据一致性保证？如何同步的？

ZAB（Zookeeper Atomic Broadcast）协议：

定义：zookeeper设计的支持崩溃恢复的原子广播协议。

zab两种模式：崩溃恢复和原子广播

原子广播原理

​ 说明：类2pc（二阶段提交）协议

leader接收事务消息 带有zxid

广播事务消息给follower 带有该zxid

follower接收消息好写入磁盘、回复ack

leader接收到ack回复超过半数，发送commit

follower接收到commit后，提交操作

崩溃恢复原理

​ 说明：Leader崩溃或者Leader和半数follower失去联系，这时需要选举leader、数据同步

​ Leader选举算法

​ zxid：事务请求编号，64位， 高32为是epoch变化（全局时钟），每进行一次选举+1；

​ 低32位是消息计数器，每接收到一条事务消息 +1，维护在leader上，新的leader 初始值位0

Leader选举：服务启动选举和崩溃选举

​ 选择中概念：myid、zxid 、epoch

​ 选举状态：looking 观望状态、following 随从状态、observing观察状态、leading领导状态

服务启动选举过程 （三台服务为例）

1. 触发：服务1启动，观望状态，服务2启动，相互通信，触发选举投票

2. 发起投票：两台服务都投票（zxid 、 myid、和epoch）自己，发送给集群中各个节点

   各个节点判断票是否有效（epoch），是否来自looking 观望状态服务器

3. 处理投票： PK ，比较epoch > zxid > myid 得到结果 , 其他节点更新投票，重新投票

4. 统计投票： 是否过半支持

5. 改变服务节点状态：节点各自 更新状态 leading状态、following状态

   崩溃选举过程

   1.当leader出现宕机／不可用，其余follower节点 将状态改为lonking观望状态、进行选举投票

   2.发起投票

   3.处理投票

   4.统计投票

   5.改变各自服务器状态

​