ZooKeeper集群架构剖析

ZooKeeper集群架构剖析 1 ZooKeeper之攘其外

ZooKeeper服务端有两种不同的运行模式。单机的称为"独立模式"(standalone mode),但是独立模式存在单点故障的问题，所以在实际开发使用较少；集群的称为“仲裁模式(quorum mode)”，不存在单点故障的问题，实际开发中使用较多。

• 主从架构：Master + Slave

• 客户端读: 类比查询余额

• 客户端写：类比存钱
  
  leader在通知follower执行某条命令时，如何保障每个follower都收到，并执行呢？

队列结构

CAP：Consistency一致性；Availability可用性；Partition Tolerance分区容错；三选二

2 ZooKeeper之安其内

leader很重要？如果挂了怎么办？开始选举新的leader
ZooKeeper服务器四种状态：

• looking：服务器处于寻找Leader群首的状态

• leading：服务器作为群首时的状态

• following：服务器作为follower跟随者时的状态

• observing：服务器作为观察者时的状态

leader选举分两种情况

• 集群初始启动时：安装后首次启动时

• 集群运行中leader挂了时

集群启动时的Leader选举

• 以3台机器组成的ZooKeeper集群为例

• 原则：集群中过半数Server启动后，才能选举出Leader；

• 此处quorum数是多少？

• 每个server投票信息vote信息结构为(sid, zxid)；

  ​ server1~3初始投票信息分别为：
  server1 -> (1, 0)
  ​ server2 -> (2, 0)
  ​ server3 -> (3, 0)

• leader选举公式：
  server1 (sid1, zxid1)
  server2 (sid2, zxid2)
  zxid大的server胜出；若zxid相等，再根据判断sid判断，sid大的胜出

• 依次启动ZK1、ZK2、ZK3 选举的流程：
  （1）ZK1和ZK2票投给自己；ZK1的投票为(1, 0)，ZK2的投票为(2, 0)，并各自将投票信息分发给其他机器。
  （2）处理投票。每个server将收到的投票和自己的投票对比；ZK1更新自己的投票为(2, 0)，并将投票重新发送给ZK2。
  （3）统计投票。server统计投票信息，是否有半数server投同一个服务器为leader；
  （4）改变服务器状态。确定Leader后，各服务器更新自己的状态，Follower变为FOLLOWING；Leader变为LEADING。
  （5）当ZK3启动时，发现已有Leader，不再选举，直接从LOOKING改为FOLLOWING。

• 同时ZK1、ZK2、ZK3 选举的流程：
  ZK1-> (1, 0) ZK2-> (2, 0) ZK3 -> (3, 0) -> ZK3被选中为Leader,其他两台节点被选为Follower

• 集群运行时新leader选举：

3 脑裂和服务器数量选取

ZK集群的服务器的数量通常为奇数台（3,5,7,9）

脑裂：