集群选举逻辑

1.elasticsearch集群选举逻辑（RBULLY算法）

1.连接协调器，获取当前集群的所有状态，包括master选举相关状态
2.判断当前集群的activeMaster是否为空
   如果不为空，选举结束，跳到第五步（老大已经选完）
   如果为空，进入第三步
3.将所有master作为候选人添加到cadidateMaster中
4.判断cadidate是否满足最小master数量
   如果不满足，跳到第一步重新选举
   如果满足，直接从候选人中找id最小的放入activeMaster中
5.选举完成

2.Zookeeper集群选举逻辑

2.1Zookeeper事务概念

1.每一个写操作都是一个事务，每一个事务都用一个事务id来代表，叫：zxid
2.zxid 是全局唯一，并且全局递增的。作用就是可以根据最大事务id，找到最新的事务

2.2Zookeeper选举机制

2.2.1选举分两个阶段

1.数据恢复阶段：
当zk服务器启动时，会先从本地磁盘找到本机的最大事务id。

2.选举阶段：
zk服务器会提交选举协议
1.Zxid（最大事务id）
2.本机的选举id（myid文件里的数字）
3.逻辑时钟值 记录当前的选举轮数，确保每个zk在同一轮选举中
4.当前zk服务器状态，分4种： Looking=>选举阶段 Following=>当小弟阶段 Leading=>当领导阶段 Observering=>观察者阶段

2.2.2选举的pk原则

1.首先比较最大事务id，Zxid，谁大谁当领导
2.如果Zxid比较不出来，比较myid（选举id），谁大谁当领导
3.选举的前提满足过半同意

2.2.3Leader选举出来之后

首先要做的是数据同步，目的是确保zk集群的数据一致性。一是可以保证当Leader挂掉之后，其他follower可以顶替工作。此外要确保客户端无论从哪个zk服务器获取数据都是一致的。
这种实现数据一致的过程称为原子广播（Atomic Brodcast）
对于客户端的读请求，任何一个zk服务器都可以处理，
但是对于写请求，会交给Leader来处理，Leader会通过原子广播端口，将写请求（事务）广播给其他的节点，还会收集每个台服务器的ack信息，然后统计是否满足过半性，如果满足，则此事务成功提交。最后反馈客户端一个确认信息。
请记住：过半性（过半选举，过半事务提交，过半存活）
每一次选举，都会生成一个epoch id（这个id是递增的），所以follower只是会接受最大的epoch id传来的数据

注意：当老的leader宕机之后，就会通过选举产生新的leader，就会要求进行数据同步，但是在老的leader重启之后，就会认为自己还是leader，就会要求重新进行数据同步，这个时候就需要引入epoch id，来表明，谁的id最大，就接受谁的数据。详情见下图：

事务id（zsid）是一个64位的2进制数，高32位是epoch id，低32位是事务id

扩展 Zookeeper的选举机制根据Paxos 算法来实现。 Paxos算法解决的问题：在分布式环境下就某一个决议达成一致性问题。 Paxos算法存在活锁问题，Zk用的是Fast Paxos算法，解决了活锁问题。