概述
最近在看一些 es 方面的东西，了解到在es 的7.x版本之前 Master Election 算法采用的是Bully，但是在7.x改用了 Raft。
Bully 算法原理
消息类型：
-
Election 消息，向节点发起选举的消息
-
Alive 消息，节点对 Election 消息的应答
-
Victory 消息，竞选成功的主节点向普通节点发送竞选成功的消息
选举过程：
-
集群中每个活着的节点查找比自己ID大的节点，如果不存在则向其他节点发送Victory消息，表明自己为主节点。
-
如果存在比自己ID大的节点，则向这些节点发送Election消息，并等待响应。
-
如果在给定的时间内，没有收到这些节点回复的消息，则自己成为主节点，并向比自己ID小的节点发送Victory消息。
-
节点收到比自己ID小的节点发送的Election消息，则回复Alive消息。
假设有如下6节点组成的集群，每个节点都会维护和其它节点的联系，p6节点是当前集群的master节点：
p6宕机了
P3节点是整个集群中最先发现master节点宕机的节点，p3节点通知了比自己编号大的p4，p5节点，p6节点
因为p6节点已经宕机，只有p4，p5节点向p3节点发出响应，并通知p3节点他们会取代p6节点成为master节点
P4节点向P5，P6节点发送通知
因为p6节点已经宕机，所以只有p5节点作出了响应
P5节点向P6节点发起选举通知，P6节点没有响应，于是P5节点成为了整个集群的master节点
P5节点成为了整个集群的master节点
Bully算法缺陷
- Master假死
Master节点承担的职责负载过重的情况下，可能无法即时对组内成员作出响应，这种便是假死。如果上图中的P6节点假死，于是P5节点成为了Master节点，但是在P6节点负载减轻之后，P6节点又对组内成员作出了响应，P6节点又会成为Master节点，如此反复，整个集群状态就会非常不可靠。
Elasticsearch是如何解决这个问题的呢？在Bully算法中，Master节点P6因为负载重，来不及对P3节点作出响应，所以P3节点通知P4,P5节点进行选举。在Elasticsearch中，P3节点发现Master P6对自己长时间不作出响应，P3节点会请求其它节点判断P6节点是否存活，如果有1/2以上节点都认定P6存活，那么P3就会放弃发起选举
- 脑裂问题
脑裂问题指的是一个集群中出现了两个及以上的Master节点。
比如上图中集群因为网络原因分成了两个部分，一个部分称为partition1包含P3,P5,P6节点，另一部分称为partition2包含P2,P1,P4节点，这两个partition因为网络原因比如路由器短时故障造成不能相互通信的问题。
图片来自于：CS 551: Distributed Operating SystemsBully Election Algorithm Example