用通俗易懂的方法解释MongoDB的选举机制

如果主节点宕机或故障了，其他的节点就会选出一个新的主节点。选举的过程可以由任意的非主节点发起，然后根据优先级和Bully算法选举出新的主节点。在选举出主节点之前，整个集群服务是只读的，不能执行写入操作。
非仲裁节点都有一个优先级的设置，范围为0--100，越大的值越能优先成为主节点。默认情况下为1，如果值为0则不能成为主节点。
Bully算法是一种协调者(主节点）竞选算法，主要思想是集群的每个成员都可以声明它是主节点并通知其他节点。其算法介绍如下：

当任何一个进程发现协调者不响应请求时，他发起一次选举，选举过程如下：
(1).P进程向所有编号比他大的进程发送一个election消息；
(2).如果无人响应，则P获胜，成为协调者
(3).如果编号比他大的进程响应，则由响应者接管选举工作，P的工作完成。
   任何一个时刻，一个进程只能从编号比他小的进程接受election消息，当消息到达时，接受者发送一个OK消息给发送者，表明它在运行，
接管工作。
最终除了一个进程外，其他进程都放弃，那个进程就是新的协调者。
    他将获胜消息发送给其他所有进程，通知他们新的协调者。
    当一个以前崩溃的进程恢复过来了后，它将主持一场选举。如果该进程恰好是当前运行进程中编号最大的进程，它将获胜，故此成为
欺负算法。


举例来说，当主节点故障或宕机之后，有资格成为主节点的从节点就会向其他节点发起一个选举提议，基本的意思就是“我觉得我能成为主节点，你们觉得呢？”，
而其他节点在收到这个选举提议后会做如下判断(三个条件)：
(1).副本集中是否有其他节点已经是主节点了？
(2).自己的数据是否比请求成为主节点的从节点上的数据更新呢？
(3).副本集中的其他节点的数据是否比请求成为主节点的从节点的数据更新呢？
如果这三个条件中只有有一个条件成立，那么都会认为对方的提议不可行，于是将返回一个消息给请求节点说“我觉得你成为主节点不合适，你退出选举吧！”，
请求节点只要收到其他任何一个节点返回不合适，都会立刻退出选举，并将自己保持在从节点的角色；但是如果上面三个条件都是否定的，那么就会在返回包中回复说“我觉得你可以成为主节点”，也就是把票投给这个请求节点，投票环节结束后就会进入选举的第二阶段。获得认可的请求节点会向其他节点发送一个确认的请求包，基本意思就是“我要宣布自己是主节点了，有人反对吗？”，如果在这次确认过程中其他节点都没反对，那么请求节点就将自己升级为主节点，所有节点在30秒内不再进行其他选举投票决定，如果有节点在确认环节反对请求节点做主节点，那么请求节点在收到反对回复后，会保持自己的节点角色依然是从节点，然后等待下一次选举。
那优先级是如何影响到选举的呢？选举机制会尽自己最大努力让优先级最高的节点成为主节点，即使副本集中已经选举出了比较稳定的，但优先级比较低的主节点。
优先级比较低的节点会短暂地作为主节点运行一段时间，但不能一直作为主节点。也就是说如果优先级比较高的节点在 Bully算法投票中没有胜出，副本集运行一段时间后会继续发起选举，直到优先级最高的节点成为主节点为止。

由此可见，优先级的设置参数在选举过程中是很重要的，要么不设置，保持都是优先级为1的公平状态，要么可以把性能比较好的几台Server设置的优先级更高一些。