ZooKeeper 的选举机制和同步机制了解一下？

zookeeper 相信大家都不陌生，很多分布式中间件都利用 zk 来提供分布式一致性协调的特性。

dubbo 官方推荐使用 zk 作为注册中心，zk 也是 hadoop 和 Hbase 的重要组件。

其他知名的开源中间件中也都出现了 zk 的身影。

有很多童鞋认识 zk 很久了，知道其基本理念，知道如何使用。

但当面试时问到集群 zk 之间的选举和数据同步机制时，就陷入了盲区。

其实很多的分布式中间件的选举和同步，都和 zk 有异曲同工之妙。

这篇文章我就来重点聊下关于 zk 集群之间的选举和同步机制。

ZK 集群的部署

首先我们来看下半数运行机制：

ZK 集群中的角色

除此之外，它和 follower 的功能是一样的。

什么时候需要用到 observer 呢，因为 zk 一般读的请求会大于写。当整个集群压力过大时，我们可以增加几个临时工 observer 来获得性能的提升。

在不需要的时候的时候，可以随时撤掉 observer。

zk 进行连接时，一般我们都会把 zk 所有的节点都配置上去，用逗号分隔。

其实连接集群中的任意一个或者多个都是可以的。

只是如果只连一个节点，当这个节点宕机的时候，我们就断开了连接。

所以还是推荐配置多个节点进行连接。

如何查看 ZK 集群中的角色

ZK 集群的选举机制

所以 zk2 也不会投票给 zk3 了。

当然这是一个比较简单版的选举，其实真正的选举还要比较 zxid，这个后面会讲到。

zk 选举什么时候会被触发呢？

一是启动时会被触发，二是 leader 宕机时会被触发。

上面的例子中，如果节点 2 宕机，根据规则，那获得 leader 的就应该是 zk3 了。

ZK 集群的数据同步机制

如果 Client 选择链接的节点是 Follower 的话，这个 Follower 会把请求转给当前 Leader，然后 Leader 会走蓝色的线把请求广播给所有的 Follower，每个节点同步完数据后会走绿色的线告诉 Leader 数据已经同步完成（但是还未提交）。

当 Leader 收到半数以上的节点 ACK 确认消息后，那么 Leader 就认为这个数据可以提交了，会广播给所有的 Follower 节点，所有的节点就可以提交数据。

整个同步工作就结束了。

可以看到，有 3 个 ZXID，这 3 个 ZXID 各自代表：

cZxid：该节点创建时的事务 ID

mZxid：该节点最近一次更新时的事务 ID

pZxid：该节点的子节点的最新一次创建/更新/删除的事务 ID

查看节点最新 ZXID 的命令为：

再看 ZK 中的选举