Zab协议（把zk leader处理的写请求同步到follower及observer上）
|
|-定义: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 协议的特性|--Zab 协议需要确保那些已经在 Leader 服务器上提交(Commit)的事务最终被所有的服务器提交.
| |
| |--Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务.
| _________________________________________________________________________________________
| | Client Client Client |
| | \ | / |
| | \ | / |
| | \ | / 事务复制过程： |
| | ZK_Leader(写数据) 1.proposal dispatch |
| | | 2.Ack 应答 |
| | ___________________|___________________ 3.Commit 过半响应后发生Commit指令 |
| | / / \ \ |
| | / / \ \ |
| | Zk_follower Zk_follower Zk_follower Zk_follower |
| |_________________________________________________________________________________________|
|
|-Zab 协议实现的作用
| |
| |--使用一个单一的主进程(Leader)来接收并处理客户端的事务请求(也就是写请求),并采用了Zab的原子广播协议,
| | 将服务器数据的状态变更以事务proposal (事务提议)的形式广播到所有的副本(Follower)进程上去.
| |
| |--保证一个全局的变更序列被顺序引用.
| | Zookeeper是一个树形结构,很多操作都要先检查才能确定是否可以执行,
| | 比如P1的事务t1可能是创建节点"/a",t2可能是创建节点"/a/bb",只有先创建了父节点"/a",才能创建子节点"/a/b".
| | 为了保证这一点,Zab要保证同一个Leader发起的事务要按顺序被apply,
| | 同时还要保证只有先前Leader的事务被apply之后,新选举出来的Leader才能再次发起事务.
| |
| |--当主进程(Leader)出现异常的时候,整个zk集群依旧能正常工作.
|
|-Zab协议原理
| |
| |--Zab协议要求每个 Leader 都要经历三个阶段：发现,同步,广播.
| |
| |--发现：要求zookeeper集群必须选举出一个 Leader 进程,同时 Leader 会维护一个 Follower 可用客户端列表.
| | 将来客户端可以和这些 Follower节点进行通信.
| |
| |--同步：Leader 要负责将本身的数据与 Follower 完成同步,做到多副本存储.这样也是体现了CAP中的高可用和分区容错.
| | Follower将队列中未处理完的请求消费完成后,写入本地事务日志中.
| |
| |--广播：Leader 可以接受客户端新的事务Proposal请求,将新的Proposal请求广播给所有的 Follower.
|
|-Zab协议核心
| |
| |--Zab协议的核心：定义了事务请求的处理方式
| |
| |--所有的事务请求必须由一个全局唯一的服务器来协调处理,这样的服务器被叫做 Leader服务器.其他剩余的服务器则是 Follower服务器.
| |
| |--Leader服务器 负责将一个客户端事务请求,转换成一个 事务Proposal,并将该 Proposal 分发给集群中所有的 Follower 服务器,
| | 也就是向所有 Follower 节点发送数据广播请求(或数据复制)
| |
| |--分发之后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选举并实现数据同步.
| | | 同步完成后又会进入消息广播模式,接收事务请求.
|
|-保证消息有序(全局事务ID)
| |
| |--在整个消息广播中,Leader会将每一个事务请求转换成对应的 proposal 来进行广播,
| | 并且在广播 事务Proposal 之前,Leader服务器会首先为这个事务Proposal分配一个全局单递增的唯一ID,称之为事务ID(即zxid),
| | 由于Zab协议需要保证每一个消息的严格的顺序关系,因此必须将每一个proposal按照其zxid的先后顺序进行排序和处理.
|
|-消息广播
| |
| |--特点:(类二阶段提交)
| | |
| | |---在zookeeper集群中,数据副本的传递策略就是采用消息广播模式.zookeeper中数据副本的同步方式与二段提交相似,但是却又不同.
| | |
| | | 二段提交要求协调者必须等到所有的参与者全部反馈ACK确认消息后,再发送commit消息.
| | | 要求所有的参与者要么全部成功,要么全部失败.二段提交会产生严重的阻塞问题.
| | |
| | |---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 协议选举算法必须满足以下要求：
| | |
| | |---确保已经被 Leader 提交的 Proposal 必须最终被所有的 Follower 服务器提交.
| | |---确保丢弃已经被 Leader 提出的但是没有被提交的 Proposal.
| | |
| | | 根据上述要求
| | |----Zab协议需要保证选举出来的Leader需要满足以下条件：
| | | 1)新选举出来的 Leader 不能包含未提交的 Proposal .
| | | 即新选举的 Leader 必须都是已经提交了 Proposal 的 Follower 服务器节点.
| | | 2)新选举的 Leader 节点中含有最大的 zxid .
| | | 这样做的好处是可以避免 Leader 服务器检查 Proposal 的提交和丢弃工作.