zookeeper之ZAB协议

标签：连接   服务器   osal   obs   接收   服务   following   生成   准备   

ZAB协议是什么，为了解决什么事情。

ZAB协议是Zookeeper Atomic Broacdcast的缩写，译为原子广播协议。解决了zookeeper中事务的最终一致性。

ZAB协议的模式

当集群启动时，或者leader节点挂掉，ZAB协议就会进入到恢复模式，然后会选举出新的leader，当leader服务器选举出来后，并且一半以上的节点与leader数据同步后，ZAB退出恢复模式。
当集群中有过半的Follower节点与Leader完成了状态同步，这时候就进入到了消息广播模式。
如果有新的节点加入集群，则会进入到数据恢复模式，与leader同步。

消息广播

这里要说明一下，首先客户端连接随便一个服务器，如果不是leader会转发消息，最后都是leader与客户端连接。
消息广播是一个二次提交的过程。

• 1. leader接收到消息后，将消息赋予一个全局唯一64位自增的zxid，新事务的zxid一定会比旧事务的zxid大
• 2.leader会为每个follower准备一个FIFO队列，将带有zxid的消息作为一个提案proposal发送给所有的follower（leader和follower之间只需要往队列中发消息即可。如果使用同步的方式会引起阻塞，性能要下降很多。）
• 3.follower收到提案后，会以事务日志的方式存储到磁盘，写入成功后向leader会返回ACK
• 4.leader接收到半数以上的ACK后，认为消息发送成功，继而发送commit消息
• 5.leader和收到commit消息的follower都会完成事务提交。

崩溃恢复

崩溃回复包括两部分，第一个是leader选举，另一个是数据恢复。
假如在消息广播中，leader给所有follower复制提案后，挂掉了，怎么处理；或者
leader收到ack，发送commit后崩溃了，怎么处理。
针对这两个问题，zab规定了两个原则

• 1.ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
• 2.ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
  那么，zab要满足上述两点规则，必须设计一个高效的leader选举算法。

leader选举算法

• 1.首先每一个server都会发出一个投票，（myid，zxid）
• 2.接收其他server的投票，节点状态应该为looking。
• 3.别人的票和自己的票进行比较，首先比较zxid。zxid比较大的server作为新的leader，如果zxid相同，比较myid。myid大的作为leader
• 4.统计票数，服务器会统计投票信息，判断是否有半数以上的节点接受相同的投票。
• 5.改变服务器状态，leader改为LEADING，follower改为FOLLOWING
  注意：observer不参与选举。选举出来的新leader不能包含未提交的proposal。

数据恢复（数据同步）

选举出新leader后，新leader具有最高的zxid，leader服务器会首先确认事务日志中的所有proposal是否已经被集群过半的服务器commit。过半提交后，leader就认为数据同步了。leader会将这些follwer服务器加入到可用服务列表中。
ZAB中的事务编号zxid是一个64为的数字。高32位是epoch，用来标识leader是否改变，每一次新的leader选出来，就会从这个 Leader 服务器上取出本地事务日志充最大编号 Proposal 的 zxid，并从 zxid 中解析得到对应的 epoch 编号，然后再对其加1，之后该编号就作为新的 epoch 值，并将低32位数字归零，由0开始重新生成zxid。；低32位是一个递增的计数器，客户端每有一个事务请求，leader会有一个propoal并对计数器+1。高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。
基于以上，当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。

zookeeper之ZAB协议

标签：连接   服务器   osal   obs   接收   服务   following   生成   准备   

原文地址：https://www.cnblogs.com/hhachi/p/12786552.html