面试官上来就问 ZAB 协议
提出的事务提议,要么就抛弃 Leader 服务器。同时,我们可以在过半的 Follower 服务器已经反馈 ACK 后,就开始提交事务提议了。 Leader 服务器会为事务提议分配一个全局单调递增的 ID,称为事务 ID(ZXID)。由于 ZAB 协议需要保证每一个消息严格的因果关系,因此需要将每一个事务提议按照其 ZXID 的先后顺序进行处理。 在消息广播过程中,Leader 服务器会为每一个 Follower 服务器分配一个队列,然后将事务提议依次放入到这些队列中去,并且根据 FIFO 的策略进行消息发送。 每一个 Follower 服务器接收到这个事务提议后,会把该事务提议以事务日志的形式写入到本地磁盘中,并且写入成功后,反馈给 Leader 服务器 ACK。 当 Leader 服务器收到过半 Follower 服务器的 ACK,就发送一个 COMMIT 消息,同时 Leader 自身完成事务提交,Follower 服务器接收到 COMMIT 消息后,也进行事务提交。 之所以采用原子广播协议协议,是为了保证分布式数据一致性。过半的节点数据保存一致性。 消息广播你可以认为消息广播机制是简化版的 2PC协议,就是通过如下的机制保证事务的顺序一致性的。请求时 Leader 节点为每一个请求生成一个事务 Proposal,将其发送给集群中所有的 Follower 节点,收到过半 Follower的反馈后开始对事务进行提交,ZAB 协议使用了原子广播协议;在 ZAB 协议中只需要得到过半的 Follower 节点反馈 Ack 就可以对事务进行提交,这也导致了 Leader 节点崩溃后可能会出现数据不一致的情况,ZAB 使用了崩溃恢复来处理数字不一致问题;消息广播使用了TCP 协议进行通讯所有保证了接受和发送事务的顺序性。广播消息时 Leader 节点为每个事务 Proposal分配一个全局递增的 ZXID(事务ID),每个事务 Proposal 都按照 ZXID 顺序来处理; Leader 节点为每一个 Follower 节点分配一个队列按事务 ZXID 顺序放入到队列中,且根据队列的规则 FIFO 来进行事务的发送。Follower节点收到事务 Proposal 后会将该事务以事务日志方式写入到本地磁盘中,成功后反馈 Ack 消息给 Leader 节点,Leader 在接收到过半Follower 节点的 Ack 反馈后就会进行事务的提交,以此同时向所有的 Follower 节点广播 Commit 消息,Follower 节点收到 Commit 后开始对事务进行提交; 崩溃恢复消息广播过程中,Leader 崩溃了还能保证数据一致吗?当 Leader 崩溃会进入崩溃恢复模式。其实主要是对如下两种情况的处理。
针对此问题,ZAB 定义了 2 个原则:
(编辑:牡丹江站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |