MongoDB副本集

副本集架构

对于mongodb来说，数据库高可用是通过副本集架构实现的，一个副本集由一个主节点和若干个从节点所组成。
客户端通过数据库主节点写入数据后，由从节点进行复制同步，这样所有从节点都会拥有这些业务数据的副本，当主节点发生故障而变得不可用时，从节点能主动发起选举并产生新的主节点进行接管，此时，客户端仍然能继续进行访问，这保证了业务的连续性。

MongoDB选举介绍

mongodb的副本集选举、复制机制是基于Raft协议的。Raft协议的选举机制中leader必须通过大多数节点投票才能产生。我们假设副本集的投票成员数量为N，则大多数为N/2+1。当副本集内存活的成员数量不足大多数时，整个副本集将无法选举除主节点，此时无法提供写服务，这些节点都将处于只读状态。此外，如果希望避免平票结果的产生，最好使用奇数个节点成员，比如3个或5个。当然，mongodb副本集的实现中，对于平票问题已经提供了解决方案：

• 为选举定时器增加少量的随机时间偏差，这样避免各个节点 在同一时刻发起选举，提高成功率。
• 使用仲裁者角色，该角色不做数据复制，也不承担读写业务，仅仅用来投票。

此外，在一个mongodb副本集中，最多只能有50个成员，而参与投票的成员最多只能有7个。这是因为一旦过多成员参与数据复制、投票过程，将会带来更多可靠性方面的问题。

mongodb为副本集成员提供了多种角色，具体如下：

• Primary：主节点，其接收所有的写请求，然后把修改同步到所有从节点。一个副本集只能有一个主节点，当主节点”挂掉“之后，其他节点会重新选举出一个主节点。
• Secondary：从节点，与主节点保持同样的数据集。当主节点”挂掉“时，参与竞选主节点。
• Arbiter：仲裁者节点，该节点只参与投票，不能被选为主节点，并且不从主节点中同步数据。当节点宕机导致副本集无法选出主节点时，可以给副本集添加一个仲裁节点，这样仍然可以选出主节点。仲裁者节点本身不存储数据，是非常轻量级的服务。当副本集成员为偶数时，