ZooKeeper
ZooKeeper作为一个命名服务、配置管理、集群管理、分布式锁、队列管理的工具，广泛用于各种分布式系统中
ZooKeeper集群角色
Zookeeper集群中，有Leader、Follower和Observer三种角色
Leader
- 事务请求的唯一调度和处理者，保证集群事务处理的顺序性
- 集群内部各服务的调度者
Follower
- 处理客户端非事务请求，转发事务（写入请求）请求给Leader服务器
- 参与事务请求Proposal的投票，所有事务请求需要半数以上Proposal的投票才能最终Commit
- 参与Leader选举投票
Observer
- 处理客户端的非事务请求（读取请求），转发事务请求（写入请求）给 Leader 服务器
- 不参与任何形式的投票，只接收选举结果信息
Zookeeper选举机制
Leader服务器挂了，即所有服务器找不到Leader的情况下，所有集群中的服务器进入LOOKING状态。
它们会通过计算ZXID和MYID选举产生新的Leader服务器，优先比较ZXID其次比较MYID，ZXID为处理事务过程中动态产生的事务ID号，用于标识存储的消息是否最新，MYID为每个节点自身的优先级编号。
接着，新的Leader服务器与集群中Follower服务进行数据同步，当集群中超过半数机器与该 Leader服务器完成数据同步之后，退出恢复模式进入消息广播模式。
Leader 服务器开始接收客户端的事务请求生成事务Proposal进行事务请求处理。
ZooKeeper选举示例
Zookeeper集群初始化阶段，服务器（myid=1-5）「依次」启动，开始zookeeper选举
- 服务器1（myid=1）启动，当前只有一台服务器，无法完成Leader选举
- 服务器2（myid=2）启动，此时两台服务器能够相互通讯，开始进入Leader选举阶段，此时选票为2，不能产生Leader
- 服务器3（myid=3）启动，继续进入Leader选举阶段，此时选票为3，都指向MYID为3的服务器，则服务器3当选为Leader
- 服务器4启动，发起一次选举，但是服务器1、2、3都不再是Looking状态，其选票会指向服务器3，服务器4参选失败
- 服务器5启动，发起一次选举，但是会重蹈服务器4的覆辙
ZooKeeper 2 Clusters (For AAP)
ZooKeeper没有2Cluster方案，针对ZooKeeper的AAP设计依赖以下
1.确定ZooKeeper的使用场景，针对不同使用场景下的ZooKeeper做不同的设计，如：若ZooKeeper仅仅用于应用的分布式锁，则在On-Premises和Azure间为AAP模型的时候，Azure端不会有业务请求，则无需共享一个分布式锁
2.Azure的ZooKeeper节点配置为Observer模式，不参与选举（Observer数据同步机制、是否可手动升级为Leader、从Azure端恢复数据回On-Premises的可行性需要进一步验证）
3.考虑通过配置ZooKeeper的选举优先级来调整On-Premises与Azure节点主从关系，将Azure端的节点优先级配置到最低，出现不可用的情况是Azure的Follower节点最后参与到Leader主节点的选举
参考链接：
