zookeeper 原理(二)

zookeeper节点类型

持久节点， 节点会被持久
临时节点，客户端断开连接后，ZooKeeper 会自动删除临时节点
顺序节点，每次创建顺序节点时，ZooKeeper 都会在路径后面自动添加上10位的数字，从1开始，最大是2147483647 （2^32-1）

ZAB协议

Zab（Zookeeper Atomic Broadcast）是为ZooKeeper设计的崩溃恢复原⼦⼴播协议，它保证zookeeper集群数据的⼀致性和命令的全局有序性
ZAB 协议包括有两种模式，分别是 崩溃恢复和消息广播。

• 崩溃恢复:当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进人恢复模式并选举产生新的 Leader 服务器。当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。剩下未同步完成的机器会继续同步，直到同步完成并加入集群后该节点的服务才可用。

• 消息广播:当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。当一台同样遵守 ZAB 协议的服务器启动后加人到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播，那么新加人的服务器就会自觉地进人数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。Leader 服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议；而如果集群中的其他机器接收到客户端的事务请求，那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。

Zab协议原理

Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。

同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。

广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。

zookeeper初始化leader选举

首先明白几个概念

• 服务器id(myid)
  比如三台服务器，编号为1，2,3
  编号越大的选举权重越大
• zxid
  值越大说明数据越新，选举权重越大
  Leader 收到请求之后，会将每个请求分配一个全局唯一递增的事务ID：zxid
• 逻辑时钟（epoch）
  用来判断是不是同一轮的投票，同一轮的的投票过程中，逻辑时钟的值是相同的
• 选举状态
  looking 竞选状态，当节点认为集群中没有leader，会进入looking状态，目的为了查找或者选举leader
  following 随从状态，同步leader信息，参与投票
  observing 观察状态，同步leader状态，不参与投票
  leading状态，领导者状态

每个节点启动的时候状态都是LOOKING，处于观望状态，接下来就开始进行选主流程

1. 每个server都会发出一个投票。server1 和server2 都会将自己作为leader发起投票，投票信息包含服务器的（myId，zxid），此时servcer1投票为（1,0），server2的投票为（2,0）
2. 各个服务器收到投票后，首先判断该投票的有消息，是否是本轮投票，是否来自looking状态的服务器。
3. 处理投票，每个服务器将别人的投票和自己的投票作对比，优先检查zxid，数值较大的优先作为leader，zxid相同的就比较myid，myid较大的服务器优先作为leader。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2,0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

5. 统计投票，每轮投票之后就会判断是否有过半的机器接受到了相同的投票信息。对于server1 server2，都统计出了集群中有两台机器接受了（2,0）的投票，此时便认为已经选出了zk2作为leader.
6. 一旦确认了leader了之后，每个服务器会更新自己的状态，如果是follower，就更新成following，如果是leader，就变更为leader.

运行中leader选举。

1. 当leader宕机之后，剩下的非observer服务器会将自己的状态变更为looking，然后进入 leader选举
2. 每个server发起一个投票，首先判断是否是来自本轮的投票，是否是来自looking状态服务器，在运行期间，每个服务器上的zxid可能不同，优先会比较zxid，zxid较大的优先选举为leader。zxid相同的，就比较myid，值越大的优先作为leader.
3. 每轮投票之后，就会统计是否有过半的机器都收到了相同的投票信息，如果有就设置为leader.
4. 一旦确认了leader之后，服务器就更新自己的状态。如果是follower，就更新成following,如果是leader，就变更为leader.

zookeeper的特性

• 顺序一致性：leader会根据请求顺序生成ZXID来严格保证请求顺序下的执行。
• 原子性，所有请求的处理结果在整个集群中所有机器上的应用情况是一致的，要么成功，要么失败。
• 单一视图，无论客户端连接到哪个zk服务器，看到的数据都是一致的
• 可靠性：一旦服务端成功执行了某个事务，那么该事务引起的服务端变更就会被一直保留下来。
• 实时性，zookeeper能保证在一段时间内客户端最终一定能从服务端上读取到最新的数据状态

Zookeeper 如何识别请求的先后顺序

Leader 收到请求之后，会将每个请求分配一个全局唯一递增的事务ID：zxid，然后把请求放入到一个 FIFO 的队列中，之后就会按照 FIFO 的策略发送给所有的 Follower。

Zookeeper 选举后如何进行数据同步的

同步有几种场景

1. 差异化同步，leader、 follower、observer中都有一个最大的zxid。根据这个可以拿到差异化的数据，leader向follower和observer发起同步，leader把差异数据发送给follower和observer
2. 回滚同步。在leader A收到请求了，接着数据处理，但是还没有来得及发送同步数据，就挂掉了。 b变成了leader，此时a需要回滚数据
3. 回滚+差异化同步。leader A收到请求之后，接着数据处理，但是没有发送同步数据，就挂掉了，b变成了leader，b里面有执行了其他的数据请求，此时a需要先将之前的没有处理完的数据回滚，再进行差异化同步
4. 全量同步。当follower 和observer里面的最新的zxid，比leader中最小的zxid还要小的话， leader发起全量同步命令。

数据通过过程（2PC）

zookeeper的数据一致性是依靠的ZAB协议完成的。

数据同步（也是一个2pc协议）

client的请求不关心是请求到是follow和leader，都有可能，但是如果follow收到的是一个事务请求，follower节点会将请求转发给leader节点。 leader节点接着会将这个事务请求，传递给集群中的其他follower节点（当前包含前面那个）。
follower收到leader的事务操作请求后，会在本地记录一个事物日志，写入内存，但是还没有真的提交，接着返回leader节点一个ack，表明成功或者失败。leader收到各个follower的ack后，如果超过半数follower返回ack成功，那么会告诉客户端数据写入成功，同时leader会通知follower节点进行数据提交操作。 整个过程是2pc协议
数据同步以后，因为数据是过半提交，所以follower并不是全部是一致，可能有些follower中间断开连接了，follower和leader之间有一个心跳请求，会向leader发起数据同步。整个过程中，leader是决策者

Wather监听机制和它的原理

客户端会对zookeeper上的节点注册一个watcher事件，当改节点发生变化，这些client会收到zookeeper的通知。

当服务提供者发生变化，上线或者下线，消费者通过订阅注册中心服务指定的节点，可以感知节点变化。

• 服务注册，provider启动时候，会向zookeeper上创建一个节点
• 服务消费. cosumer启动时候，会向zookeeper读取节点目录下的服务器信息，并且设置watcher监听，获取到服务信息之后，将服务提供者的信息缓存到本地
• 服务通知，一旦服务提供者因为某种原因发生了修改或者删除，zookeeper会发送一个修改通知给消费者，消费者更新本地服务列表。

分享一个dubbo和 zookeeper一些面试题 戳链接