分布式系统（六）

什么是Zab和谈？

Zab和谈 的全称是 Zookeeper Atomic Broadcast （Zookeeper本子广播）。 Zookeeper 是通过 Zab 和谈来担保分布式事务的最末一致性。

Zab和谈是为分布式协调效劳Zookeeper专门设想的一种 撑持解体规复 的 本子广播和谈 ，是Zookeeper担保数据一致性的焦点算法。Zab借鉴了Paxos算法，但又不像Paxos这样，是一种通用的分布式一致性算法。它是出格为Zookeeper设想的撑持解体规复的本子广播和谈。

正在Zookeeper中次要依赖Zab和谈来真现数据一致性，基于该和谈，zk真现了一种主备模型（即Leader和Follower模型）的系统架构来担保集群中各个正原之间数据的一致性。 那里的主备系统架构模型，便是指只要一台客户端（Leader）卖力办理外部的写事务乞求，而后Leader客户端将数据同步到其余Follower节点。

Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，假如是读乞求，就间接从当前节点中读与数据；假如是写乞求，这么节点就会向 Leader 提交事务，Leader 接管到事务提交，会广播该事务，只有赶过对合节点写入乐成，该事务就会被提交。

Zab 和谈的特性：

1）Zab 和谈须要确保这些曾经正在 Leader 效劳器上提交（Commit）的事务最末被所有的效劳器提交。

2）Zab 和谈须要确保抛弃这些只正在 Leader 上被提出而没有被提交的事务。

模型图

Zab 和谈真现的做用

1）运用一个单一的主进程（Leader）来接管并办理客户实个事务乞求（也便是写乞求），并给取了Zab的本子广播和谈，将效劳器数据的形态变更以 事务proposal （事务提议）的模式广播到所有的正原（Follower）进程上去。

2）担保一个全局的变更序列被顺序引用。 Zookeeper是一个树形构造，不少收配都要先检查威力确定能否可以执止，比如P1的事务t1可能是创立节点"/a"，t2可能是创立节点"/a/bb"，只要先创立了父节点"/a"，威力创立子节点"/a/b"。

为了担保那一点，Zab要担保同一个Leader建议的事务要按顺序被apply，同时还要担保只要先前Leader的事务被apply之后，新选举出来的Leader威力再次建议事务。

3）当主进程显现异样的时候，整个zk集群照常能一般工做。

Zab和谈本理

Zab和谈要求每个 Leader 都要教训三个阶段：发现，同步，广播。

发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。未来客户端可以和那些 Follower节点停行通信。

同步：Leader 要卖力将自身的数据取 Follower 完成同步，作到多正原存储。那样也是提现了CAP中的高可用和分区容错。Follower将队列中未办理完的乞求出产完成后，写入原地事务日志中。

广播：Leader 可以承受客户端新的事务Proposal乞求，将新的Proposal乞求广播给所有的 Follower。

Zab和谈焦点

Zab和谈的焦点：界说了事务乞求的办理方式

1）所有的事务乞求必须由一个全局惟一的效劳器来协调办理，那样的效劳器被叫作 Leader效劳器。其余剩余的效劳器则是 Follower效劳器。

2）Leader效劳器 卖力将一个客户端事务乞求，转换成一个 事务Proposal，并将该 Proposal 分发给集群中所有的 Follower 效劳器，也便是向所有 Follower 节点发送数据广播乞求（或数据复制）

3）分发之后Leader效劳器须要等候所有Follower效劳器的应声（Ack乞求），正在Zab和谈中，只有赶过对合的Follower效劳器停行了准确的应声后（也便是支到对合以上的Follower的Ack乞求），这么 Leader 就会再次向所有的 Follower效劳器发送 Commit 音讯，要求其将上一个 事务proposal 停行提交。

事务乞求办理

Zab和谈内容

Zab 和谈蕴含两种根柢的形式：解体规复 和 音讯广播

和谈历程

当整个集群启动历程中，大概当 Leader 效劳器显现网络中弄断、解体退出或重启等异样时，Zab和谈就会 进入解体规复形式，选举孕育发作新的Leader。

中选举孕育发作了新的 Leader，同时集群中有过半的呆板取该 Leader 效劳器完成为了形态同步（即数据同步）之后，Zab和谈就会退出解体规复形式，进入音讯广播形式。

那时，假如有一台固守Zab和谈的效劳器参预集群，因为此时集群中曾经存正在一个Leader效劳器正在广播音讯，这么该新参预的效劳器主动进入规复形式：找到Leader效劳器，并且完成数据同步。同步完成后，做为新的Follower一起参取到音讯广播流程中。

和谈形态切换

当Leader显现解体退出大概机注重启，亦或是集群中不存正在赶过对合的效劳器取Leader保存一般通信，Zab就会再一次进入解体规复，建议新一轮Leader选举并真现数据同步。同步完成后又会进入音讯广播形式，接就事务乞求。

担保音讯有序

正在整个音讯广播中，Leader会将每一个事务乞求转换成对应的 proposal 来停行广播，并且正在广播 事务Proposal 之前，Leader效劳器会首先为那个事务Proposal分配一个全局单递删的惟一ID，称之为事务ID（即zxid），由于Zab和谈须要担保每一个音讯的严格的顺序干系，因而必须将每一个proposal依照其zxid的先后顺序停行牌序和办理。

音讯广播 1）正在zookeeper集群中，数据正原的通报战略便是给取音讯广播形式。zookeeper中农数据正原的同步方式取二段提交相似，但是却又差异。二段提交要求协调者必须等到所有的参取者全副应声ACK确认音讯后，再发送commit音讯。要求所有的参取者要么全副乐成，要么全副失败。二段提交会孕育发作重大的阻塞问题。

2）Zab和谈中 Leader 等候 Follower 的ACK应声音讯是指“只有对合以上的Follower乐成应声便可，不须要支到全副Follower应声”

音讯广播流程图

音讯广播详细轨范

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 音讯后，会将上一条事务提交。

zookeeper 给取 Zab 和谈的焦点，便是只有有一台效劳器提交了 Proposal，就要确保所有的效劳器最末都能准确提交 Proposal。那也是 CAP/BASE 真现最末一致性的一个表示。

Leader 效劳器取每一个 Follower 效劳器之间都维护了一个径自的 FIFO 音讯队列停行支发音讯，运用队列音讯可以作到异步解耦。 Leader 和 Follower 之间只须要往队列中发音讯便可。假如运用同步的方式会惹起阻塞，机能要下降不少。

解体规复

一旦 Leader 效劳器显现解体大概由于网络起因招致 Leader 效劳器失去了取过半 Follower 的联络，这么就会进入解体规复形式。

正在 Zab 和谈中，为了担保步调的准确运止，整个规复历程完毕后须要选举出一个新的 Leader 效劳器。因而 Zab 和谈须要一个高效且牢靠的 Leader 选举算法，从而确保能够快捷选举出新的 Leader 。

Leader 选举算法不只仅须要让 Leader 原人晓得原人曾经当选举为 Leader ，同时还须要让集群中的所有其余呆板也能够快捷感知到选举孕育发作的新 Leader 效劳器。

解体规复次要蕴含两局部：Leader选举 和 数据规复

Zab 和谈如何担保数据一致性

如果两种异样状况： 1、一个事务正在 Leader 上提交了，并且过半的 Folower 都响应 Ack 了，但是 Leader 正在 Commit 音讯发出之前挂了。 2、如果一个事务正在 Leader 提出之后，Leader 挂了。

要确保假如发作上述两种状况，数据还能保持一致性，这么 Zab 和谈选举算法必须满足以下要求：

Zab 和谈解体规复要求满足以下两个要求： 1）确保曾经被 Leader 提交的 Proposal 必须最末被所有的 Follower 效劳器提交。 2）确保抛弃曾经被 Leader 提出的但是没有被提交的 Proposal。

依据上述要求 Zab和谈须要担保选举出来的Leader须要满足以下条件： 1）新选举出来的 Leader 不能包孕未提交的 Proposal 。 即新选举的 Leader 必须都是曾经提交了 Proposal 的 Follower 效劳器节点。 2）新选举的 Leader 节点中含有最大的 zxid 。 那样作的好处是可以防行 Leader 效劳器检查 Proposal 的提交和抛弃工做。

Zab 如何数据同步

1）完成 Leader 选举后（新的 Leader 具有最高的zxid），正在正式初步工做之前（接就事务乞求，而后提出新的 Proposal），Leader 效劳器会首先确认事务日志中的所有的 Proposal 能否曾经被集群中过半的效劳器 Commit。

2）Leader 效劳器须要确保所有的 Follower 效劳器能够接管到每一条事务的 Proposal ，并且能将所有曾经提交的事务 Proposal 使用到内存数据中。等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 效劳器上同步过啦并且使用到内存数据中以后，Leader 才会把该 Follower 参预到实正可用的 Follower 列表中。

Zab 数据同步历程中，如何办理须要抛弃的 Proposal

正在 Zab 的事务编号 zxid 设想中，zxid是一个64位的数字。

此中低32位可以看成一个简略的单删计数器，针对客户端每一个事务乞求，Leader 正在孕育发作新的 Proposal 事务时，都会对该计数器加1。而高32位则代表了 Leader 周期的 epoch 编号。

epoch 编号可以了解为当前集群所处的年代，大概周期。每次Leader变更之后都会正在 epoch 的根原上加1，那样旧的 Leader 解体规复之后，其余Follower 也不会听它的了，因为 Follower 只从命epoch最高的 Leader 号令。

每中选举孕育发作一个新的 Leader ，就会从那个 Leader 效劳器上与出原地事务日志充最大编号 Proposal 的 zxid，并从 zxid 中解析获得对应的 epoch 编号，而后再对其加1，之后该编号就做为新的 epoch 值，并将低32位数字归零，由0初步重重生成zxid。

Zab 和谈通过 epoch 编号来区分 Leader 厘革周期，能够有效防行差异的 Leader 舛错的运用了雷同的 zxid 编号提出了纷比方样的 Proposal 的异样状况。

基于以上战略 当一个包孕了上一个 Leader 周期中尚未提交过的事务 Proposal 的效劳器启动时，当那台呆板参预集群中，以 Follower 角涩连上 Leader 效劳器后，Leader 效劳器会依据原人效劳器上最后提交的 Proposal 来和 Follower 效劳器的 Proposal 停行比对，比对的结果肯定是 Leader 要求 Follower 停行一个回退收配，回退到一个简曲曾经被集群中过半呆板 Commit 的最新 Proposal。

真现本理

Zab 节点有三种形态：

Following：当前节点是逃随者，从命 Leader 节点的号令。 Leading：当前节点是 Leader，卖力协调事务。 Election/Looking：节点处于选举形态，正正在寻找 Leader。 代码真现中，多了一种形态：ObserZZZing 形态 那是 Zookeeper 引入 ObserZZZer 之后参预的，ObserZZZer 不参取选举，是只读节点，跟 Zab 和谈没有干系。

节点的恒暂形态：

history：当前节点接管到事务 Proposal 的Log acceptedEpoch：Follower 曾经承受的 Leader 变动 epoch 的 newEpoch 提议。 currentEpoch：当前所处的 Leader 年代 lastZxid：history 中最近接管到的Proposal 的 zxid（最大zxid）

Zab 的四个阶段

1、选举阶段（Leader Election） 节点正在一初步都处于选举节点，只有有一个节点获得赶过对合节点的票数，它就可以中选准 Leader，只要达到第三个阶段（也便是同步阶段），那个准 Leader 才会成为实正的 Leader。

Zookeeper 规定所有有效的投票都必须正在同一个 轮次 中，每个效劳器正在初步新一轮投票时，都会对原人维护的 logicalClock 停行自删收配。

每个效劳器正在广播原人的选票前，会将原人的投票箱（recZZZset）清空。该投票箱记录了所遭到的选票。 譬喻：SerZZZer_2 投票给 SerZZZer_3，SerZZZer_3 投票给 SerZZZer_1，则SerZZZer_1的投票箱为(2,3)、(3,1)、(1,1)。（每个效劳器都会默许给原人投票）

前一个数字默示投票者，后一个数字默示当选举者。票箱中只会记录每一个投票者的最后一次投票记录，假如投票者更新原人的选票，则其余效劳器支到该新选票后会正在原人的票箱中更新该效劳器的选票。

那一阶段的宗旨便是为了选出一个准 Leader ，而后进入下一个阶段。 和谈并无规定具体的选举算法，背面会提到真现中运用的 Fast Leader Election。

选举流程

2、发现阶段（DescoZZZery） 正在那个阶段，Followers 和上一轮选举出的准 Leader 停行通信，同步 Followers 最近接管的事务 Proposal 。 一个 Follower 只会连贯一个 Leader，假如一个 Follower 节点认为另一个 Follower 节点，则会正在检验测验连贯时被谢绝。被谢绝之后，该节点就会进入 Leader Election阶段。

那个阶段的次要宗旨是发现当前大大都节点接管的最新 Proposal，并且准 Leader 生成新的 epoch ，让 Followers 接管，更新它们的 acceptedEpoch。

发现流程

3、同步阶段（Synchronization） 同步阶段次要是操做 Leader 前一阶段与得的最新 Proposal 汗青，同步集群中所有的正原。 只要当 quorum（赶过对合的节点） 都同步完成，准 Leader 才会成为实正的 Leader。Follower 只会接管 zxid 比原人 lastZxid 大的 Proposal。

同步流程

4、广播阶段（Broadcast） 到了那个阶段，Zookeeper 集群威力正式对外供给事务效劳，并且 Leader 可以停行音讯广播。同时，假如有新的节点参预，还须要对新节点停行同步。 须要留心的是，Zab 提交事务其真不像 2PC 一样须要全副 Follower 都 Ack，只须要获得 quorum（赶过对合的节点）的Ack 就可以。

广播流程

和谈真现

和谈的 JaZZZa 版原真现跟上面的界说略有差异，选举阶段运用的是 Fast Leader Election（FLE），它包孕了轨范1的发现责备。因为FLE会选举领有最新提议的汗青节点做为 Leader，那样就省去了发现最新提议的轨范。

真际的真现将发现和同步阶段兼并为 RecoZZZery Phase（规复阶段），所以，Zab 的真现真际上有三个阶段。

Zab和谈三个阶段：

1）选举（Fast Leader Election） 2）规复（RecoZZZery Phase） 3）广播（Broadcast Phase）

Fast Leader Election（快捷选举） 前面提到的 FLE 会选举领有最新Proposal history （lastZxid最大）的节点做为 Leader，那样就省去了发现最新提议的轨范。那是基于领有最新提议的节点也领有最新的提交记录

成为 Leader 的条件： 1）选 epoch 最大的 2）若 epoch 相等，选 zxid 最大的 3）若 epoch 和 zxid 相等，选择 serZZZer_id 最大的（zoo.cfg中的myid） 节点正在选举初步时，都默许投票给原人，当接管其余节点的选票时，会依据上面的 Leader条件 判断并且变动原人的选票，而后从头发送选票给其余节点。当有一个节点的得票赶过对合，该节点会设置原人的形态为 Leading ，其余节点会设置原人的形态为 Following。

选举历程

RecoZZZery Phase（规复阶段） 那一阶段 Follower 发送他们的 lastZxid 给 Leader，Leader 依据 lastZxid 决议如何同步数据。那里的真现跟前面的 Phase 2 有所差异：Follower 支到 TRUNC 指令会末行 L.lastCommitedZxid 之后的 Proposal ，支到 DIFF 指令会接管新的 Proposal。

history.lastCommitedZxid：最近被提交的 Proposal zxid history.oldThreshold：被认为曾经太旧的曾经提交的 Proposal zxid

规复阶段

什么状况下zab和谈会进入解体规复形式？

1、当效劳器启动时

2、当leader 效劳器显现网络中断，解体大概重启的状况

3、当集群中曾经不存正在过半的效劳器取Leader效劳器保持一般通信。

zab和谈进入解体规复形式会作什么？

1、当leader显现问题，zab和谈进入解体规复形式，并且选举出新的leader。当新的leader选举出来以后，假如集群中曾经有过半呆板完成为了leader效劳器的形态同（数据同步），退出解体规复，进入音讯广播形式。

2、当新的呆板参预到集群中的时候，假如曾经存正在leader效劳器，这么新参预的效劳器就会盲目进入解体规复形式，找到leader停行数据同步。

非凡状况下须要处置惩罚惩罚的两个问题：

问题一：曾经被办理的事务乞求（proposal）不能丢（commit的） 当 leader 支到正当数质 follower 的 ACKs 后，就向各个 follower 广播 COMMIT 号令，同时也会正在原地执止 COMMIT 并向连贯的客户端返回「乐成」。但是假如正在各个 follower 正在支到 COMMIT 号令前 leader 就挂了，招致剩下的效劳器并无执止都那条音讯。

如那边置惩罚惩罚 曾经被办理的事务乞求（proposal）不能丢（commit的） 呢？

1、选举领有 proposal 最大值（即 zxid 最大） 的节点做为新的 leader。

由于所有提案被 COMMIT 之前必须有正当数质的 follower ACK，即必须有正当数质的效劳器的事务日志上有该提案的 proposal，因而，zxid最大也便是数据最新的节点保存了所有被 COMMIT 音讯的 proposal 形态。

2、新的 leader 将原人事务日志中 proposal 但未 COMMIT 的音讯办理。

3、新的 leader 取 follower 建设先进先出的队列， 先将原身有而 follower 没有的 proposal 发送给 follower，再将那些 proposal 的 COMMIT 号令发送给 follower，以担保所有的 follower 都保存了所有的 proposal、所有的 follower 都办理了所有的音讯。通过以上战略，能担保曾经被办理的音讯不会丢。

问题二：没被办理的事务乞求（proposal）不能再次显现什么时候会显现事务乞求被损失呢？

当 leader 接管到音讯乞求生成 proposal 后就挂了，其余 follower 并无支到此 proposal，因而颠终规复形式从头选了 leader 后，那条音讯是被跳过的。 此时，之前挂了的 leader 从头启动并注册成为了 follower，他糊口生涯了被跳过音讯的 proposal 形态，取整个系统的形态是纷比方致的，须要将其增除。

假如处置惩罚惩罚呢？

Zab 通过奇妙的设想 zxid 来真现那一宗旨。

一个 zxid 是64位，高 32 是纪元（epoch）编号，每颠终一次 leader 选举孕育发作一个新的 leader，新 leader 会将 epoch 号 +1。低 32 位是音讯计数器，每接管到一条音讯那个值 +1，新 leader 选举后那个值重置为 0。

那样设想的好处是旧的 leader 挂了后重启，它不会当选举为 leader，因为此时它的 zxid 肯定小于当前的新 leader。当旧的 leader 做为 follower 接入新的 leader 后，新的 leader 会让它将所有的领有旧的 epoch 号的未被 COMMIT 的 proposal 根除。

每天提高一点点！