zookeeper系列(七)：主从同步

整个集群完成Leader选举后，Leader会向Leader服务器进行注册。当Leader向Leader服务器完成注册后，就进入主从数据同步环节。也就是Leader会将自己的数据同步给从服务器。

根据ZXID来判断同步策略

这里有三个ZXID

四种数据同步策略：

场景：

peerLastZxid 介于 minCommittedLog 和 maxCommittedLog 之间。

leader向从服务器发送一个DIFF指令，告诉从服务器进入DIFF同步阶段，leader将要把一些proposal同步给从。针对每个proposal，leader都会发送两个数敬源据包，分别是proposal内容数据包和commit指令数据包。

假如某个时刻leader服务器的建议缓存队列对应的ZXID依次是：

0x500000001、0x500000002、0x500000003、0x500000004、0x500000005

而从服务器最后处理的ZXID为0x500000003。

那么leader就会依次将0x500000004、0x500000005两个proposal同步给从服务器。

场景：

假设有A、B、C三台机器，加入某一时刻B是leader，此时的epoch为5，ZXID包括0x500000001、0x500000002。此时leader正要处理ZXID：0x500000003，键睁并且已经将该事务写入到了自己机器的事务日志稿稿岁中了，就在将该proposal发给从服务器的时候，B挂了，也就是leader挂了，proposal没有同步出去。

此时zk集群会进行新一轮的leader选举，A成为leader，epoch为6。并又提交了两个事务0x600000001、0x600000002。此时B重启，并开始同步数据。

leaderA发现B中的ZXID:0x500000003自己没有，那么就会让B先回滚到和自己ZXID一样的最近的ZXID。再DIFF同步。

此时B，先回滚到0x500000002，再DIFF同步0x600000001、0x600000002

（这里是6开头了啊，不是5开头）

场景：

peerLastZxid 大于 maxCommittedLog

TRUNC + DIFF同步的第一步。

也就是A成为leader后，还没有新的事务0x600000001、0x600000002进来，B就起来了。这个时候，B直接回滚就好了。

场景1：

peerLastZxid 小于 minCommittedLog

场景2：

leader服务器上没有proposal缓存队列。

在这两种场景下，leader服务器都无法直接使用建议缓存队列进行数据同步，没办法了，只能全量同步了。

所谓全量同步就是leader服务器将本机上的全量内存数据都同步给从服务器。

Zookeeper是一种分布式协调服务。所谓分布式协调服务就是在分布式系统中共享配置、协调锁资源，提供命名服务。

Zookeeper的数据模型和数据结构当中的树类似，很像文件系统的目录。Zookeeper的数据存储也是基于节点，这种节点叫做Znode。Znode的引用方式是路径引用，类似于文件路径：/动物/人

常见的API：

create 创建节点

delete 删除节点

exists 判断节点是否存在

getData 获取一个节点的数据

getChildren 获取节点下的所有节点

Zookeeper客户端在请求读 *** 作的时候，可以选择是否设置Watch。Watch理解成是注册在特定Znode上的触发器。当这个Znode发生改变，即调用了create、delete、setData方法时，会触发Znode上注册的对应事件，请求Watch的客户端会接收到异步通知。

具体交互过程：

1、客户端调用getData方法，watch参数是true。服务端接到请求，返回节点数据。并且在对应的哈希表里插入被Watch的Znode路径，以及Watcher数组。

2、当被Watch的Znode已删除，服务端会查找哈希表，根据key找到该Znode对应的所有Watcher，异步通知客户端，并且删除哈希表中对应的Key-Value。

为了防止单机故障，Zookeeper可以维护一个集群。Zookeeper Service集群时一主多从结构。

更新数据时，先更新到主节点（节点指服务器，而不是Znode），再同步到从节点。

读取数据时，直接读取任意从节点。

为保证主从节点的数据一致性，Zookeeper采用了ZAB协议，这种协议非常类似于一致性算法Paxos和Raft。

ZAB即Zookeeper Atomic Broadcast，有效解决了Zookeeper集群崩溃恢复以及主从同步数据的问题。

Zab协议既不是强一致性，也不是弱一致性，而是处于两者之间的单调一致性。它依靠敏首事务ID和版本号，保证了数据的更新和读取是有序的。

ZAB协议所的三种节点状态：

1）Looking：选举状态

2）Following：Follower节点（从节点）所处的状态

3）Leading：Leader节点（主节点）所处状态

三种算法：leaderElection/AuthFastLeaderElection/FastLeaderElection

1）Leader election

3）Discovery

4）Synchronization

Zookeeper常规情况下更新数据的时候，由Leader广播到所有Follower。其过程如下：

1）客户端发出写入数据请求给任意Follower

2）Follower把写入数据请求转发给Leader

3）Leader采用二阶段族枝提交方式，先发送Propose广播给Follower。

4）Follower接到Propose消息，写入日志成功后，返回ACK消息给Leader

5）Leader接到半数以上ACK消息，返回成功给客户端，兆拿敏并且广播Commit请求给Follower。

原文链接： https://blog.csdn.net/qq_26545305/article/details/87946879

---