1.9.4.1. 常见分布式集群选举机制总结
1.9.4.1.1. Zookeeper选举
参考 https://www.jianshu.com/p/49ce02abc7ba
1.9.4.1.2. Kafka选举
Kafka Controller控制器的选举：kafka集群的controller选举 分区leader的选举 消费者相关的选举
Kafka Controller控制器的选举 在Kafka集群中会有一个或多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态等工作。比如当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。再比如当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。
Kafka Controller的选举是依赖Zookeeper来实现的，在Kafka集群中哪个broker能够成功创建/controller这个临时（EPHEMERAL）节点他就可以成为Kafka Controller。
Kafka Controller的选举其实就是创建临时节点，这和Zookeeper分布式锁的实现原理基本相同。
分区leader的选举：
分区leader副本的选举由Kafka Controller 负责具体实施。当创建分区（创建主题或增加分区都有创建分区的动作）或分区上线（比如分区中原先的leader副本下线，此时分区需要选举一个新的leader上线来对外提供服务）的时候都需要执行leader的选举动作。
基本思路是按照AR集合中副本的顺序查找第一个存活的副本，并且这个副本在ISR集合中。
消费者相关的选举： 组协调器GroupCoordinator需要为消费组内的消费者选举出一个消费组的leader，这个选举的算法也很简单，分两种情况分析。 1、如果消费组内还没有leader，那么第一个加入消费组的消费者即为消费组的leader。 2、如果某一时刻leader消费者由于某些原因退出了消费组，那么会重新选举一个新的leader， 在GroupCoordinator中消费者的信息是以HashMap的形式存储的，其中key为消费者的member_id，而value是消费者相关的元数据信息。 leaderId表示leader消费者的member_id，它的取值为HashMap中的第一个键值对的key，这种选举的方式基本上和随机无异。 总体上来说，消费组的leader选举过程是很随意的。
Kafka选举参考 https://blog.csdn.net/u013256816/article/details/89369160 https://www.jianshu.com/p/49ce02abc7ba
1.9.4.1.3. Redis选举
redis集群的主从切换
redis没有类似Zookeeper的选举机制。redis的master挂掉以后，redis集群是通过主从切换来保证高可用性的。
redis主从切换有2种方式：手动切换和自动切换。
这里我们讨论自动切换，redis主从自动切换需要哨兵模式的支持，哨兵模式简单来说就是：监控master和slave，在master出现故障的时候，自动将slave切换成master，master恢复以后，作为新master的slave对外提供服务。
参考 https://www.jianshu.com/p/49ce02abc7ba
1.9.4.1.4. Eureka选举
Eureka集群的相互复制
准确的来说，Eureka集群中的各节点之间不存在主从关系。Eureka集群中的节点的关系是对等的，其他3种集群则都存在主从关系，这是Eureka集群的一个特色。
Eureka集群的各个server之间通过相互注册的方式来实现集群的高可用性。数据同步的方式是增量备份，这样可以保证每个server都是最新最全的数据。从而保证集群的高可用性。这样即使某个server挂了，集群还可以对外提供服务。
总结： Eureka server集群不存在选举机制，Eureka server集群各节点的关系是对等的，Eureka server通过相互复制来保证高可用性。
参考 https://www.jianshu.com/p/49ce02abc7ba
1.9.4.1.5. RocketMQ选举
NameServ之间都是全量的数据，没有选举