提示:文章写完后,目录可以自动生成,如何生成可参考右边的帮助文档
前言
一致性协议有很多种,比如 Paxos,Raft,2PC,3PC等等,今天我们讲一种协议,ZAB 协议,该协议应该是所有一致性协议中生产环境中应用最多的了。为什么呢?因为他是为 Zookeeper 设计的分布式一致性协议!
一、什么是 ZAB 协议?
-
ZAB 协议全称:Zookeeper Atomic Broadcast(Zookeeper 原子广播协议)。
-
Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面,Zookeeper 并没有使用 Paxos,而是采用了 ZAB 协议。
-
ZAB 协议定义:ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持 崩溃恢复 和 原子广播协议。
-
基于该协议,Zookeeper 实现了一种 主备模式 的系统架构来保持集群中各个副本之间 数据一致性。
二、消息广播
ZAB 协议的消息广播过程使用的是一个原子广播协议。对于客户端发送的写请求,全部由 Leader 接收,Leader 将请求封装成一个事务 Proposal,将其发送给所有 Follwer ,然后,根据所有 Follwer 的反馈,如果超过半数成功响应,则执行 commit 操作(先提交自己,再发送 commit 给所有 Follwer)。
如果集群中的Learner 节点收到客户端的事务请求,那么这些Learner会将请求转发给Leader服务器。然后再执行如下过程:
- Leader接收到事务请求后,为事务赋予一个全局唯一的64位自增id,即zxid,通过zxid的大小比较即可实现事务的有序性管理,然后将事务封装成一个Proposal。
- Leader 根据Follower 列表获取到所有的Follower,然后将Proposal通过这些Follower的队列将提案发送给各个Follower。
- 当Follower 接收到提案后,会先将提案的zxid与本地记录的事务日志中的最大zxid进行比较。若当前提案的zxid大于最大zxid,则将当前提案记录到本地事务日志中,并向Leader 返回一个ACK。
当Leader接收到过半的ACKs后,Leader 就会向所有Follower 的队列发送Commit 消息,向所有Observer的队列发送Proposal。 - 当Follower接收到Commit消息后,就会将事务正式更新到本地。当Observer 收到Proposal 后,会直接将事务更新到本地。
- 无论是Follower 还是 Observer ,在同步完成后都需要向Leader 发送成功ACK。
通过以上步骤,就能够保持集群之间数据的一致性。实际上,在 Leader 和 Follwer 之间还有一个消息队列,用来解耦他们之间的耦合,避免同步,实现异步解耦。
细节:
-
Leader 在收到客户端请求之后,会将这个请求封装成一个事务,并给这个事务分配一个全局递增的唯一 ID,称为事务ID(ZXID),ZAB 兮协议需要保证事务的顺序,因此必须将每一个事务按照 ZXID 进行先后排序然后处理。
-
在 Leader 和 Follwer 之间还有一个消息队列,用来解耦他们之间的耦合,解除同步阻塞。
-
zookeeper集群中为保证任何所有进程能够有序的顺序执行,只能是 Leader 服务器接受写请求,即使是 Follower 服务器接受到客户端的请求,也会转发到 Leader 服务器进行处理。
-
实际上,这是一种简化版本的 2PC,不能解决单点问题。等会我们会讲述 ZAB 如何解决单点问题(即 Leader 崩溃问题)。
三、崩溃恢复
消息广播过程中,Leader 崩溃怎么办?还能保证数据一致吗?如果 Leader 先本地提交了,然后 commit 请求没有发送出去,怎么办?
实际上,当 Leader 崩溃,即进入我们开头所说的崩溃恢复模式(崩溃即:Leader 失去与过半 Follwer 的联系)。下面来详细讲述。
假设1:Leader 在复制数据(未提交)给所有 Follwer 之后崩溃,怎么办?
假设2:Leader 在收到 Ack 并提交了自己,同时发送了部分 commit 出去之后崩溃怎么办?
针对这些问题,ZAB 定义了 2 个原则:
1、ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
2、ZAB 协议确保丢弃那些只在 Leader 提出事务/复制,但没有提交的事务。
让 Leader 选举算法能够保证新选举出来的 Leader 服务器拥有集群总所有机器编号(即 ZXID 最大)的事务,那么就能够保证这个新选举出来的 Leader 一定具有所有已经提交的提案。
而且这么做有一个好处是:可以省去 Leader 服务器检查事务的提交和丢弃工作的这一步操作。
四、数据同步
具体过程如下:
- 为了保证Leader向Learner发送提案的有序,Leader会为每一个Learner 服务器准备一个队列
- Leader 将那些没有被各个Leader同步的事务封装为Proposal
- Leader 将那些Proposal逐条发给各个Learner,并在每个Proposal后紧跟一个Commit消息,表示该事务已经被提交,Learner可以直接接收并执行
- Learner接收来自于Leader 的 Proposal,并将其更新到本地
- 当Learner 更新成功后,会向准Leader 发送ACK信息
- Leader 服务器在收到来自Learner的ACK后就会将该Learner加入到真正可用的Follower列表或Observer列表。没有反馈ACK,或反馈了但Leader没有收到的Learner,Leader不会将其加入到相应列表。
当崩溃恢复之后,需要在正式工作之前(接收客户端请求),Leader 服务器首先确认事务是否都已经被过半的 Follwer 提交了,即是否完成了数据同步。目的是为了保持数据一致。
当所有的 Follwer 服务器都成功同步之后,Leader 会将这些服务器加入到可用服务器列表中。
实际上,Leader 服务器处理或丢弃事务都是依赖着 ZXID 的,那么这个 ZXID 如何生成呢?
答:在 ZAB 协议的事务编号 ZXID 设计中,ZXID 是一个 64 位的数字,其中低 32 位可以看作是一个简单的递增的计数器,针对客户端的每一个事务请求,Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。
而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID,并从该 ZXID 中解析出对应的 epoch 值,然后再对这个值加一。
高 32 位代表了每代 Leader 的唯一性,低 32 代表了每代 Leader 中事务的唯一性。同时,也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。
基于这样的策略:当 Follower 链接上 Leader 之后,Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对,比对结果要么回滚,要么和 Leader 同步。
总结
ZAB 协议和我们之前看的 Raft 协议实际上是有相似之处的,比如都有一个 Leader,用来保证一致性(Paxos 并没有使用 Leader 机制保证一致性)。再有采取过半即成功的机制保证服务可用(实际上 Paxos 和 Raft 都是这么做的)。
ZAB 让整个 Zookeeper 集群在两个模式之间转换,消息广播和崩溃恢复,消息广播可以说是一个简化版本的 2PC,通过崩溃恢复解决了 2PC 的单点问题,通过队列解决了 2PC 的同步阻塞问题。
而支持崩溃恢复后数据准确性的就是数据同步了,数据同步基于事务的 ZXID 的唯一性来保证。通过 + 1 操作可以辨别事务的先后顺序。