【zookeeper】——消息广播,崩溃恢复

zookeeper大概流程
【zookeeper】——消息广播,崩溃恢复_第1张图片
zab协议
根据zab协议实现分布式系统数据一致性,zab核心将所有写操作的请求都转换为事物(proposal)。Leader节点再数据写完之后,将向所有follower节点发送数据广播请求,等待所有follower响应。在zab协议中只要有半数以上follower反馈即可。leader节点就会向所有follower服务器发送commit消息。即将leader节点上的数据同步到follower节点上。
ZAB协议要求每个leader都要经历三个阶段,即发现,同步,广播。
发现:即要求zookeeper集群必须选择出一个leader进程,同时leader会维护一个follower可用列表。将来客户端可以这follower中的节点进行通信。
同步:leader要负责将本身的数据与follower完成同步,做到多副本存储。这样也是体现了CAP中高可用和分区容错。follower将队列中未处理完的请求消费完成后,写入本地事物日志中。
广播:leader可以接受客户端新的proposal请求,将新的proposal请求广播给所有的follower。
【zookeeper】——消息广播,崩溃恢复_第2张图片
两种方式1、消息广播,2、崩溃恢复模式
广播模式
zookeeper中消息广播的具体步骤如下:
4.1. 客户端发起一个写操作请求
4.2. Leader服务器将客户端的request请求转化为事物proposql提案,同时为每个proposal分配一个全局唯一的ID,即ZXID。
4.3. leader服务器与每个follower之间都有一个队列,leader将消息发送到该队列
4.4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后,向leader服务器发送ACK确认。
4.5. leader服务器收到半数以上的follower的ACK后,即认为可以发送commit
4.6. leader向所有的follower服务器发送commit消息
zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal,就要确保所有的服务器最终都能正确提交proposal。这也是CAP/BASE最终实现一致性的一个体现。
leader服务器与每个follower之间都有一个单独的队列进行收发消息,使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。
崩溃恢复

zookeeper集群中为保证任何所有进程能够有序的顺序执行,只能是leader服务器接受写请求,即使是follower服务器接受到客户端的请求,也会转发到leader服务器进行处理。
如果leader服务器发生崩溃,则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。
ZAB协议崩溃恢复要求满足如下2个要求:
3.1. 确保已经被leader提交的proposal必须最终被所有的follower服务器提交。
3.2. 确保丢弃已经被leader出的但是没有被提交的proposal。
根据上述要求,新选举出来的leader不能包含未提交的proposal,即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时,新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。
leader服务器发生崩溃时分为如下场景:
5.1. leader在提出proposal时未提交之前崩溃,则经过崩溃恢复之后,新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。

5.2 leader在发送commit消息之后,崩溃。即消息已经发送到队列中。经过崩溃恢复之后,参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行,也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程。
【zookeeper】——消息广播,崩溃恢复_第3张图片

你可能感兴趣的:(#,【Zookeeper】)