Zookeeper 集群选主和数据同步算法

2019-09-19 0 By admin

一、选主流程

1、恢复模式

当『Leader』崩溃或者『Leader』失去大多数的『Follower』,这时候 Zookeeper 进入恢复模式。
恢复模式需要重新选举出一个新的『Leader』,让所有的 Server都恢复到一个正确的状态。
Zookeeper 的选举算法有两种:一种是基于basic paxos实现的,另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

2、basic paxos流程

1、选举线程由当前Server发起选举的线程担任,其主要功能是对投票结果进行统计,并选出推荐的 Server。
2、选举线程首先向所有Server发起一次询问(包括自己);
3、选举线程收到回复后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的id(myid),并存储到当前询问对象列表中,最后获取对方提议的『Leader』相关信息(id,zxid),并将这些信息存储到当次选举的投票记录表中。
4、收到所有Server回复以后,就计算出zxid最大的那个Server,并将这个Server相关信息设置成下一次要投票的Server。
5、线程将当前zxid最大的Server设置为当前Server要推荐的『Leader』,如果此时获胜的Server获得n/2 + 1的Server票数, 设置当前推荐的『Leader』为获胜的Server,将根据获胜的Server相关信息设置自己的状态,否则,继续这个过程,直到『Leader』被选举出来。

每个Server启动后都会重复以上流程。在恢复模式下,如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息,Zookeeper会记录事务日志并定期进行快照,方便在恢复时进行状态恢复。

二、同步流程

选完『Leader』以后,Zookeeper 就进入状态同步过程。
1、『Leader』 等待server连接。
2、『Follower』连接『Leader』,将最大的zxid发送给『Leader』。
3、『Leader』根据『Follower』的zxid确定同步点。
4、完成同步后通知『Follower』 已经成为uptodate状态。
5、『Follower』收到uptodate消息后,又可以重新接受client的请求进行服务了。

三、数据一致性与paxos算法

据说Paxos算法的难理解与算法的知名度一样令人敬仰,所以我们先看如何保持数据的一致性。
这里有个原则就是:
在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。
Paxos算法解决的什么问题呢,解决的就是保证每个节点执行相同的操作序列。
好吧,这还不简单,master维护一个全局写队列,所有写操作都必须放入这个队列编号,那么无论我们写多少个节点,只要写操作是按编号来的,就能保证一致性。没错,就是这样,可是如果master挂了呢。

3.1、写操作过程

Paxos 算法通过投票来对写操作进行全局编号;同一时刻,只有一个写操作被批准,同时并发的写操作要去争取选票,只有获得过半数选票的写操作才会被 【批准】(所以永远只会有一个写操作得到批准),其他的写操作竞争失败只好再发起一轮投票。所有写操作都被严格编号排序。

3.2、编号规则

编号严格递增,当一个节点接受了一个编号为100的写操作,之后又接受到编号为99的写操作(因为网络延迟等很多不可预见原因),它马上能意识到自己数据不一致了,自动停止对外服务并重启同步过程。
任何一个节点挂掉都不会影响整个集群的数据一致性(总2n+1台,除非挂掉大于n台)。

3.3、集群同步状态

zookeeper 作为 Hadoop 项目中的一个子项目,是 Hadoop 集群管理的一个必不可少的模块,它主要用来控制集群中的数据,如它管理 Hadoop 集群中的 NameNode,还有 Hbase 中 Master Election、Server 之间状态同步等。