1.zookeeper集群角色
2.leader选举源码分析
3.ZAB协议
4.ZAB崩溃恢复模式
5.watch模式源码分析
6.数据存储
7.参考
1.zookeeper集群角色
1.处理客户端非事务请求,以及转发事务请求给leader服务器
2.参与事务请求提议(proposal)的投票(客户端的一个事务请求,需要半数服务器投票通过以后才能通知leader commit; leader会发起一个提案,要求follower投票)
观察zookeeper集群中最新状态的变化并将这些状态同步到observer服务器上
增加observer不影响集群中事务处理能力,同时还能提升集群的非事务处理能力
源码地址:https://github.com/apache/zookeeper.git
zookeeper启动的时候有个日志输出,可以根据日志输出来跟踪查看leader选举
>QuorumPeer.startLeaderElection
-->createElectionAlgorithm(三种选举算法leaderElection/AuthFastLeaderElection/FastLeaderElection
-->currentVote = new Vote(myid, getLastLoggedZxid(), getCurrentEpoch());//初始化自己的投票信息
--->getCurrentEpoch>readLongFromFile 从/tmp/zookeeper 里面读取数据Epoch
--->QuorumCnxManager 初始化数据,管理选举中和其他server的网络交互,选举时监听在专门的electionAddr上
---->receiveConnection 监听到数据返回,判断sid,sid越大代表权重高,其他服务器需要与该sid服务器建立连接
---->Messenger(就是QuorumCnxManager )
----->WorkerSender>从QuorumCnxManager::recvQueue中获取网络包,并将其发到FastLeaderElection::recvqueue中
----->WorkerReceiver>从FastLeaderElection::sendqueue中获取网络包,并将其放QuorumCnxManager::queueSendMap中,并发送到网络上
----->lookForLeader>QuorumPeer主线程会调用lookForLeader函数,它从recvqueue中获取别人发给server的选举数据,并将发给其他server的投票放到sendqueue中
serverid : 在配置server集群的时候,给定服务器的标识id(myid)
zxid : 服务器在运行时产生的数据ID, zxid的值越大,表示数据越新
server的状态:Looking、 Following、Observering、Leading
参考:https://www.cnblogs.com/siodoon/articles/5438076.html
1.所有在集群中的server都会推荐自己为leader,然后把(myid、zxid、epoch)作为广播信息,广播给集群中的其他server, 然后等待其他服务器返回
2.每个服务器都会接收来自集群中的其他服务器的投票。集群中的每个服务器在接受到投票后,开始判断投票的有效性
a)判断逻辑时钟(Epoch) ,如果Epoch大于自己当前的Epoch,说明自己保存的Epoch是过期。更新Epoch,同时clear其他服务器发送过来的选举数据。判断是否需要更新当前自己的选举情况
b)如果Epoch小于目前的Epoch,说明对方的epoch过期了,也就意味着对方服务器的选举轮数是过期的。这个时候,只需要讲自己的信息发送给对方
c)如果Epoch==当前Epoch,则根据规则判断是否有规则获得leader(zxid最大的优先)
a)ZAB协议要求每个leader都要经历三个阶段,即发现,同步,广播。
(1)发现:即要求zookeeper集群必须选择出一个leader进程,同时leader会维护一个follower可用列表。将来客户端可以这follower中的节点进行通信。
(2)同步:leader要负责将本身的数据与follower完成同步,做到多副本存储。这样也是体现了CAP中高可用和分区容错。follower将队列中未处理完的请求消费完成后,写入本地事物日志中。
(3)广播:leader可以接受客户端新的proposal请求,将新的proposal请求广播给所有的follower。
paxos协议主要就是如何保证在分布式环网络环境下,各个服务器如何达成一致最终保证数据的一致性问题
zookeeper并没有完全采用paxos算法, 而是采用zab Zookeeper atomic broadcast
zab协议为分布式协调服务zookeeper专门设计的一种支持崩溃恢复的原子广播协议
c)在zookeeper 的主备模式下,通过zab协议来保证集群中各个副本数据的一致性
d)zookeeper使用的是单一的主进程来接收并处理所有的事务请求,并采用zab协议,把数据的状态变更以事务请求的形式广播到其他的节点
e)zab协议在主备模型架构中,保证了同一时刻只能有一个主进程来广播服务器的状态变更
f)所有的事务请求必须由全局唯一的服务器来协调处理,这个的服务器叫leader,其他的叫follower,leader节点主要负责把客户端的事务请求转化成一个request事务提议(proposal),并分发给集群中的所有follower节点,再等待所有follower节点的反馈ack。一旦超过半数服务器进行了正确的反馈,那么leader就会commit这条消息
g)ZAB协议中主要有两种模式,第一是消息广播模式(第5点);第二是崩溃恢复模式
h)zookeeper集群中为保证任何所有进程能够有序的顺序执行,只能是leader服务器接受写请求,即使是follower服务器接受到客户端的请求,也会转发到leader服务器进行处理
(1)当leader出现问题,zab协议进入崩溃恢复模式,并且选举出新的leader。当新的leader选举出来以后,如果集群中已经有过半机器完成了leader服务器的状态同步(数据同步),退出崩溃恢复,进入消息广播模式
确保已经被leader提交的proposal必须最终被所有的follower服务器提交。
确保丢弃已经被leader出的但是没有被提交的proposal。
(3)新选举出来的leader不能包含未提交的proposal,即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时,新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。
(4)当新的机器加入到集群中的时候,如果已经存在leader服务器,那么新加入的服务器就会自觉进入数据恢复模式,找到leader进行数据同步
(1)leader在提出proposal时未提交之前崩溃,则经过崩溃恢复之后,新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。
(2)leader在发送commit消息之后,崩溃。即消息已经发送到队列中。经过崩溃恢复之后,参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行,也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程
(1)在zookeeper集群中新的leader选举成功之后,leader会将自身的提交的最大proposal的事物ZXID发送给其他的follower节点。follower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致。
(2)数据同步完之后,zookeeper集群如何保证新选举的leader分配的ZXID是全局唯一呢?这个就要从ZXID的设计谈起。
ZXID是一个长度64位的数字,其中低32位是按照数字递增,即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号,至于这个编号如何产生(我也没有搞明白),每当选举出一个新的leader时,新的leader就从本地事物日志中取出ZXID,然后解析出高32位的epoch编号,进行加1,再将低32位的全部设置为0。这样就保证了每次新选举的leader后,保证了ZXID的唯一性而且是保证递增的。
(1)假设一个事务在leader服务器被提交了,并且已经有过半的follower返回了ack。 在leader节点把commit消息发送给folower机器之前leader服务器挂了怎么办
zab协议,一定需要保证已经被leader提交的事务也能够被所有follower提交
zab协议需要保证,在崩溃恢复过程中跳过哪些已经被丢弃的事务
leader 崩溃之后,集群会选出新的 leader,然后就会进入恢复阶段,新的 leader 具有所有已经提交的提议,因此它会保证让 followers 同步已提交的提议,丢弃未提交的提议(以 leader 的记录为准),这就保证了整个集群的数据一致性。
(3)选举 leader 的时候,整个集群无法处理写请求的,如何快速进行 leader 选举?
这是通过 Fast Leader Election 实现的,leader 的选举只需要超过半数的节点投票即可,这样不需要等待所有节点的选票,能够尽早选出 leader
https://blog.csdn.net/junchenbb0430/article/details/77583955
https://yq.aliyun.com/articles/304722
可以通过zk.exists、zk.getData进行监听,监听一次就没了
>getData(final String path, Watcher watcher, DataCallback cb, Object ctx)
-->sendThread.getClientCnxnSocket().packetAdded()
Watcher,接口类型,其定义了process方法,需子类实现。
KeeperState,枚举类型,Event的内部类,表示Zookeeper所处的状态。
EventType,枚举类型,Event的内部类,表示Zookeeper中发生的事件类型。
WatchedEvent,表示对ZooKeeper上发生变化后的反馈,包含了KeeperState和EventType。
ClientWatchManager,接口类型,表示客户端的Watcher管理者,其定义了materialized方法,需子类实现。
ZKWatchManager,Zookeeper的内部类,继承ClientWatchManager。
MyWatcher,ZooKeeperMain的内部类,继承Watcher。
ServerCnxn,接口类型,继承Watcher,表示客户端与服务端的一个连接。
4.客户端去WatchManger找到对应节点的事件发送通知
参考:https://www.cnblogs.com/leesf456/p/6286827.html
java -cp :/data/program/zookeeper-3.4.10/lib/slf4j-api-1.6.1.jar:/data/program/zookeeper-3.4.10/zookeeper-3.4.10.jar org.apache.zookeeper.server.LogFormatter log.200000001