杰霸霸博客

主题

ZAB协议 ​

1. ZAB算法 ​

Zab借鉴了Paxos算法，是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。基于该协议，Zookeeper设计为只有一台客户端(Leader)负责处理外部的写事务请求，然后Leader客户端将数据同步到其他Follower节点。即Zookeeper只有一个Leader可以发起提案。

2. Zab 协议内容 ​

Zab协议包括两种基本的模式：消息广播、崩溃恢复。

3. 消息广播 ​

Alt text

  1. 客户端发起一个写操作请求。
  2. Leader服务器将客户端的请求转化为事务Proposal提案，同时为每个Proposal分配一个全局的ID，即zxid。
  3. Leader服务器为每个Follower服务器分配一个单独的队列，然后将需要广播的Proposal依次放到队列中去，并且根据FIFO策略进行消息发送。
  4. Follower接收到Proposal后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向Leader反馈一个Ack响应消息。
  5. Leader接收到超过半数以上Follower的Ack响应消息后，即认为消息发送成功，可以发送commit消息。
  6. Leader向所有Follower广播commit消息，同时自身也会完成事务提交。Follower接收到commit消息后，会将上一条事务提交。
  7. Zookeeper采用Zab协议的核心，就是只要有一台服务器提交了Proposal，就要确保所有的服务器最终都能正确提交Proposal。

✏️笔记

ZAB协议针对事务请求的处理过程,类似于一个两阶段提交过程:
(1)广播事务阶段
(2)广播提交操作

4. 崩溃恢复 ​

Leader宕机很可能带来数据不一致，比如：

  1. Leader发起一个事务Proposal1后就宕机，Follower都没有收到Proposal1。
  2. Leader收到半数ACK时发生宕机，没来得及向Follower发送Commit。

🔍怎么解决上述这些问题呢？ZAB引入了崩溃恢复模式。

4.1 崩溃恢复触发条件 ​

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

  1. 假设两种服务器异常情况：
    • 假设一个事务在Leader提出之后，Leader挂了。
    • 一个事务在Leader上提交了，并且过半的Follower都响应Ack了，但是Leader在Commit消息发出之前挂了。
  2. Zab协议崩溃恢复要求满足以下两个要求：
    • 确保已经被Leader提交的提案Proposal，必须最终被所有的Follower服务器提交。(已经产生的提案，Follower必须执行)
    • 确保丢弃已经被Leader提出的，但是没有被提交的Proposal。(丢弃胎死腹中的提案)

4.2 崩溃恢复之Leader选举 ​

Alt text Leader选举：根据上述要求，Zab协议需要保证选举出来的Leader需要满足以下条件：
(1)新选举出来的Leader不能包含未提交的Proposal。即新Leader必须都是已经提交了Proposal的Follower服务器节点。
(2)新选举的Leader节点中含有最大的zxid。这样做的好处是可以避免Leader服务器检查Proposal的提交和丢弃工作。

4.3 崩溃恢复之数据恢复 ​

Alt text
Zab如何数据同步：
(1)完成Leader选举后，在正式开始工作之前(接收事务请求，然后提出新的Proposal)，Leader服务器会首先确认事务日志中的所有的Proposal是否已经被集群中过半的服务器Commit。
(2)Leader服务器需要确保所有的Follower服务器能够接收到每一条事务的Proposal，并且能将所有已经提交的事务Proposal应用到内存数据中。等到Follower将所有尚未同步的事务Proposal都从Leader服务器上同步过，并且应用到内存数据中以后，Leader才会把该Follower加入到真正可用的Follower列表中。

5. CAP理论 ​

CAP理论告诉我们，一个分布式系统不可能同时满足以下三种：

  • 一致性(C:Consistency)
  • 可用性(A:Available)
  • 分区容错性(P:Partition Tolerance) 这三个基本需求，最多只能同时满足其中的两项，因为P是必须的，因此往往选择就在CP或者AP中。
  1. 一致性(C:Consistency) 在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。在一致性的需求下，当一个系统在数 据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
  2. 可用性(A:Available) 可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
  3. 分区容错性(P:Partition Tolerance) 分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

ZooKeeper保证的是CP
(1)ZooKeeper不能保证每次服务请求的可用性。(注：在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。所以说，ZooKeeper不能保证服务可用性。
(2)进行Leader选举时集群都是不可用。