参考
Zookeeper原理篇-Zookeeper启动流程分析
zookeeper原理篇-Zookeeper选举过程分析
预处理
创建服务实例之前需要的数据读取加载准备就绪
入口启动类 QuorumPeerMain
解析Zoo.cfg配置文件
创建 DatadirCleanupManager类实例
对历史记录文件进行清理
以及定时清理日志和快照的管理器
通过clientPort参数断是是单机还是集群
创建ZookeeperServer类实例
初始化
将Zookeeper中的相关服务管理类进行创建
创建一个ServerStats实例
收集统计信息
创建 数据存储管理器–FileTxnSnaplog类
据zookeeper.serverCnxnFactory参数来确定网络连接工厂类型
基于Netty基于jdk自身的Nio工厂
初始化一个Thread 主线程
初始化ServerCnxnFactory实例
端口其实已经对外开放
还无法对外处理请求
开始恢复Zookeeper的数据
构建会话管理器–SessionTracker
负责管理Session
初始化请求过滤链
责任链模式
三个请求处理器PrepRequestProessorSyncRequestProessorFinalRequestProessor
启动注册
服务器已经开始到就绪状态了
将对应的信息注册以后即可对外提供服务了
将JMX服务注册
完成单机启动流程
可以正常提供服务了
集群模式
预处理
同单机模式
初始化
创建并初始化ServerCnxnFactory
创建数据文件管理器FileTxnSnaplog
集群模式下
创建QuorumPeer实例
属于Zookeeper的托管者会不停的检测当前服务器实例的状态并且在需要选举的时候发起选举
创建内存数据库ZKDatabase实例
录会话记录以及DataTree和事物日志
QuorumPeer实例作为托管者
将核心组件信息注册上去
包括
ZKDatabaseFileTxnSnaplog服务器列表信息选举算法
恢复数据
启动ServerCnxnFactory中的主线程
运行run方法，开始执行服务器选举相关的操作
Leader选举
electionAlg属性，确定选举算法
LeaderElection 0
UDP协议实现
UDP版本的FastLeaderElection
1 UDP版本的 非授权模式2 UDP版本的 授权模式
TCP版本的FastLeaderElection
3 TCP协议实现的3.4只支持
选举初始化阶段
初始化一个选举的票据
根据自身服务器IDlastLoggedZxid当前服务器的epoch
开始注册JMX服务
QuorumPeer的状态应该是LOOKING
才会开始进行选举操作
一般是ZXID最大的机器成为Leader如果ZXID一样，SID越大的则成为Leader
Leader与Follower交互
当选举出Leader机器以后，其他的机器则会开始与Leader进行交互
Leader服务器需要确定集群的机器存活情况
zk创建LearnerCnxAcceptor实例负责处理所有的非Leader机器的连接请求
非Leader服务器在启动完毕后
会从选举的结果中找到集群的Leader,并且尝试进行连接
建立连接后 会将自己的信息发送给Leader
此过程的数据称之为LearnerInfo
当前服务器的SID最大的ZXID
Leader收到LearnerInfo消息后，epochofleader进行比较
直到半数以上
确定整个集群中的epoch值
Leader将该信息发送给所有的非Leader
此消息称之为LEADERINFO
Follower机器收到后
响应给Leader一个ack
Leader收到ack以后
开始与该Follower机器进行数据同步过程了
超过半数的Follower机器完成了和Leader之间的数据同步过程
已经可以提前启动对外提供服务
Leader与Follower启动
创建并且启动会话管理器初始化Zookeeper中的请求处理链开始注册JMX服务注册完毕后，整个集群的启动完成可以对外开始提供服务了 详细选举流程 zookeeper中存在三种服务器角色
Leader
Follower
Observer
作为一个监控协调者的作用不参与zookeeper对外提供服务以及选举 选举分两种
当整个zookeeper的集群启动后，进行的选举过程
在zookeeper运行期间
当出现Leader崩溃的过程时，zookeeper进行的选举操作 启动选举
基础
机器编号
配置文件李myid
当至少两台含有myid的机器启动后,开始进入进群选举
每个server发起一个投票
选票
server1 (1,0) （myid,ZXID）server2 (2,0)
接受到其他服务端实例发来的选票
服务处于Looking状态
校验处理选票的流程
选票信息进行pk比较
优先比较ZXID,ZXID不一样的时候
大的的为leader
两个选票的ZXID相同的话，那么就会比较myid
大的的为leader
依据上面规则
server1 (2,0)
server1会更新自己的选票为
server2 (2,0)
统计每一次选票
判断是否有过半的实例接受到了相同的选票信息
如果是单数的实例
达到(实例数 + 1) / 2 数量一样的选票的即可
同步服务端实例状态
每个服务实例都会更新自身的状态
Follower 变为 FOLLOWER状态Leader 变成LEADING状态 运行期间选举
如果是 Follower挂了或者是新机器实例加入集群中
也不会影响Leader
一旦Leader无法响应或者是宕机了，Zookeeper集群将无法对外进行服务
而是进行新一轮的Leader选举
更新自身状态
Follower实例状态 变成 LOOKING
一样的选举流程
XMind - Trial Version
