ZAB协议简述

ZAB是专门为ZooKeeper设计的崩溃可恢复的原子消息广播算法。基于该协议ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。具体的：

• 客户端的事务请求由主进程处理，并以事务的方式，原子的广播到集群中。
• ZAB协议保证，集群中只有一个主进程能够处理客户端的请求。
• 为保证事务的顺序性，ZAB协议必须能够保证一个全局的变更序列被顺序应用于事务的提交。
• 在当前主进程奔溃退出或重启，Zk集群依旧能够正常工作。

消息广播

ZooKeeper设计成只允许唯一的一个 Leader服务器来进行事务请求的处理。Leader服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议（如果集群中的非Leader服务器接收到客户端的事务请求时，则会将这个事务请求转发给Leader服务器）。

当过半的 Follower服务器已经反馈Leader服务器Ack之后，Leader服务器就开始向集群中广播提交事务的消息，则收到消息的服务器开始在本地执行事务的commit。

在整个消息广播过程中，Leader服务器会为事务 Proposal分配一个全局单调递增的唯一ID，称之为事务ID（即ZXID）。由于ZAB协议需要保证每个消息严格的因果关系，因此必须将每一个事务 Proposal按照其ZXID的先后顺序来进行排序与处理。

具体的，在消息广播过程中，Leader服务器会为每一个 Follower服务器都各自分配一个单独的队列，然后将需要广播的事务 Proposal依次放入这些队列中去，并且根据FIFO策略进行消息发送。每一个 Follower服务器在接收到这个事务 Proposal之后，都会首先将其以事务日志的形式写入到本地磁盘中去，并且在成功写入后反馈给 Leader服务器个Ack响应。当 Leader服务器接收到超过半数 Follower的Ack响应后，就会广播一个Commit消息给所有的 Follower服务器以通知其进行事务提交，同时 Leader自身也会完成对事务的提交，而每一个 Follower服务器在接收到 Commit消息后，也会完成对事务的提交。

崩溃恢复

当 Leader服务器出现崩溃，或者说由于网络原因导致 Leader服务器失去了与过半 Follower的联系，那么就会进入崩溃恢复模式。

在ZAB协议中，为了保证程序的正确运行，整个恢复过程结束后需要选举出一个新的 Leader服务器。因此，ZAB协议需要一个高效且可靠的 Leader选举算法。ZAB协议针对奔溃恢复的核心内容：

• ZAB协议需要确保那些已经在 Leader服务器上提交的事务最终被所有服务器都提交；

• ZAB协议需要确保丢弃那些只在 Leader服务器上被提出的事务；

• Leader选举算法能够保证新选举出来的 Leader服务器拥有集群中所有机器最高编号（即ZXID最大）的事务 Proposal，那么就可以保证这个新选举出来的 Leader一定具有所有已经提交的提案。

总结上述三个核心思想，来应对可能会出现的问题：

1. 当Leader发出提交事务Proposal-1000后挂掉了，那么该事务要么被某个Follower执行了，或者所有的Follower都没有执行。此时开始选举新的Leader，会判断ZXID最大的Follower成为Leader，假如该Follower提交了事务Proposal-1000，那么它会将这条记录广播给其他Follower，否则，所有的Follower都没有提交Proposal-1000。
2. 当Leader向Follower提出事务Proposal-1000后挂掉了，然后大半数的Follower回应Leader信息ACK，但是因为Leader已经挂掉了，因此所有Follower不会收到Leader的Commit信息，此时Followers就可以直接抛弃该提议。

标签：协议,事务,ZAB,Follower,服务器,Proposal,Leader
来源： https://www.cnblogs.com/code-duck/p/15063497.html