文章目录
- ZAB协议介绍
- ZooKeeper的Leader选举流程分析
- QuorumPeer是如何开启一次Leader选举的?
- QuorumPeer的线程主逻辑中是如何根据节点状态启动Leader选举的
- 初步开始查看Leader选举的源码细节
- QuorumPeer是如何尝试去跟其他机器建立连接的?
- QuorumCnxManager是如何基于TCP监听其他机器的连接的?
- ZooKeeper是如何避免两台机器重复建立TCP连接的
- 当两台机器建立连接之后是如何开始发起投票的
- SenderWorker是如何将投票发送给其他机器的?
- 如何接收其他机器发送过来的投票
- 如何进行选票PK以及选票归档?
- 如何通过归档的选票统计出谁当选Leader?
- 如何根据选举结果更新自己的角色状态?
- Leader选举完毕之后各自确定角色以及创建核心实体
- Leader是如何启动Follower连接监听器的
- Follower是如何向Leader发起连接请求的?
- Leader跟Follower建立连接之后会干什么?
- Jute是什么序列化协议?ZooKeeper内部通信是如何实现的
- Follower在完成连接建立之后是如何向Leader进行注册的
- Leader是如何处理Follower的注册请求的?
- Follower注册完毕之后的数据同步通信架构
ZAB协议介绍
ZAB (ZooKeeper Atomic Broadcast) 协议
ZAB (ZooKeeper Atomic Broadcast) 协议是 ZooKeeper 中用来保证集群中所有节点数据一致性的核心协议。它确保了所有更新能够在集群中以原子的方式传播,即要么所有节点都应用了更新,要么都不应用。ZAB 协议有两种模式:崩溃恢复模式 (Recovery Mode) 和普通模式 (Broadcast Mode)。
1. 概述
ZAB 协议解决了以下问题:
- 一致性:所有服务器对同一操作具有相同的结果。
- 原子性:要么所有服务器都应用了某个操作,要么都不应用。
- 顺序性:操作按照提案的顺序被应用。
- 持久性:已经提交的操作不会因为故障而丢失。
2. 模式
2.1 崩溃恢复模式 (Recovery Mode)
当集群中的服务器重启或加入新服务器时,需要进入崩溃恢复模式。此模式的目的是让所有的服务器达成一致的状态。
- 选举 Leader:服务器之间进行选举,选出一个 Leader。
- 状态同步:Follower 通过 Sync 请求与 Leader 同步状态。
- 完成同步