Zookeeper的学习和使用——zookeeper工作原理和集群原理

Zookeeper的学习和使用——zookeeper工作原理和集群原理

Scroll Down

zookeeper的工作原理和集群原理

1.从实际问题探讨zookeeper的设计和实现

实际问题:
1.跨进程的事务管理如何管理?
2.多系统的如何进行配置的管理?
3.多应用的业务流程的如何控制?
设计思路:
首先我们需要一个中间件来集中管理我们的应用,他可以对我们的应用进行控制(事件通知)和监控(心跳检测),然后随着我们业务量的增长,这个中间件是可以解决单点故障(集群),让我们看看zookeeper是如何帮我们处理这些问题的。

2.zookeeper的集群管理

1.集群的节点状态

zookeeper的节点角色

leadr:领导者,处理事务请求(节点的增删改)
follower:追随者,只处理读请求,参与事务投票
observe:观察者,不参与事务投票,只同步leader状态,扩展系统,提高运行速度

image.png

2.集群出现的问题及解决措施原理

1.zookeeper如何保证集群中各节点的数据一致性

zookeeper中是由leader节点来进行实物请求的操作和其他节点保证数据一致性,然后基于改进版的2PC来进行广播
传统2PC提交:
成功
image.png
失败:
image.png
即:简单的理解就是2pc是各个参入者都要进行参入进行,成功和失败都要返回的通知协调者,然后交给协调者来统一处理。
而zookeeper的改进版的2PC,用来解决事务的一致性问题:
image.png
消息广播:

1.leader会对每个消息生成一个zxid(64位自增)
2.为每个 follower 准备了一个 FIFO 队列(通过 TCP协议来实现,以实现了全局有序这一个特点)将带有zxid的消息会作为一个提案分发给每一个follower节点
3.follower会将提案写入磁盘,返回一个ack给leader
4.leader收到合法数量的请求ack以后,在发送commit或者rollback请求
注意:
observe不参与投票,只会在投票完成后与lead进行同步
zxid:ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.

2.zookeeper如何集群崩溃恢复的

zookeeper是基于zab协议(支持崩溃恢复的原子广播协议),即存在两种模式:恢复模式和广播模式

恢复模式:服务启动或者在领导者崩溃后。
广播模式: leader已经和多数的follower进行了状态同步后。

存在两种方式的原因是为了解决两个问题:

1.已经被处理的消息不能丢失(即leader在接受到ack后发送commit给follower,但是突然宕机了)
2.被丢弃的消息不在此出现(即原来的leader收到事务请求,还未发送投票之前,leader挂了)

原则是:

1.zxid最大。事务id最大,保证事务是最新的
2.每产生一个新的leader,epoch会+1,解决上个leader存在被丢弃消息再次出现问题,类似于古代改朝换代,每个朝代有自己的制度,上个朝代的就不要了。其中zxid是64位,低于32位的表示消息计数器,高于32位的是epoch编号

3.集群的leader选举

节点的状态:

LOOKING:当前Server不知道leader是谁,正在搜寻
LEADING:当前Server即为选举出来的leader
FOLLOWING:leader已经选举出来,当前Server与之同步

启动时候的选举(最少2n+1台服务器):

1.先开始每个节点都是looking状态;
2.每个 Server 发出一个投票,发出投票
3.接受来自各个服务器的投票,检查票据的合法性;
4.处理投票,将接受的票与自己的票对比,根据myid,zxid,epoch的大小
统计投票,即自己小就更新自己的票据,然后在投。
5.统计投票。每次投票后,服务器都会统计投票信息,判断是否已经有过半机器接受到相同的投票信息,如果超过半数就已经选出leader
6.改变服务器状态。一旦确定了 Leader,每个服务器就会更新自己的状态,如果是 Follower,那么就变更为FOLLOWING,如果是 Leader,就变更为 LEADING

运行过程中的 leader 选举:

1.变更状态,非 Observer 服务器都会将自己的服务器状态变更为 LOOKING
2.每个 Server 会发出一个投票。
3. 处理投票。
4. 统计投票。
5. 改变服务器的状态

3.总结

简单的来说,zookeeper的工作原理就是基于zab的,一个就是广播模式,为了解决数据一致性的改进2pc,即由leader来处理事务请求,保证请求的有序性,然后通过投票来保证数据的一致性;一个是崩溃恢复,存在消息丢失,通过zxid最大的选取为leader保证数据的最新,存在丢弃消息被再次消费,用epoch的方式来迭代。最后就是zookeeper的选举启动与崩溃的选举大致内容都一直,都是变更状态,生成票据,检验票据,处理票据,统计票据,改变状态的过程。