复制集架构¶
The architecture of a replica set affects the set’s capacity and capability. This document provides strategies for replica set deployments and describes common architectures.
最基础的复制集架构是由三个成员组成的。这样的架构为复制集提供了冗余与故障切换的余地。根据应用的需求来设计复制集的架构，尽量避免不必要的复杂化。
策略¶
决定复制集的成员个数¶
请根据以下的策略来考量复制集的成员数
复制集应含有奇数个成员¶
奇数个成员的存在确保了复制集可以正常的选举出主节点。如果副本集现有偶数个成员，那么请增加一个投票节点以保证其成员个数为奇数。 投票节点 由于不包含副本集的数据集副本故所需资源也很少。所以我们可以将投票节点设置在其他应用的机器或是某个共享功能的机器上。
故障容错的考量¶
对于复制集来说，其 故障容错 就是要保证在主节点不可用的时候，剩余的节点能够顺利的选举出新的主节点。换句话说，就是为了保证可以正常的选举出新的主节点，需要保证复制集中多数成员的存活。复制集在没有主节点时将无法接受写请求。复制集的故障容错受到其含有的成员个数的影响，但是该影响也不是直接体现的。请参考下表：
复制集成员个数。 |
选举出新的主节点所需存活的多数节点个数。 |
可发生的故障转移次数。 |
|---|---|---|
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
为复制集新增节点 不一定 能够复制集的故障容错能力，但是却可以为一些专用的功能提供服务，比如备份或是报表。
以读为主的架构的负载均衡¶
若业务带来的 大量 的读请求，我们可以通过做读写分离来提升复制集的读能力。随着业务的扩展，我们可以通过在其他数据中心新增从节点的方式来提高冗余能力与可用性。
为了能够选举出主节点，请保证复制集中多数节点的可用性。
不要在负载饱和时才想到来提高性能与承载能力。¶
请保证复制集拥有足够的备用容量来新增节点。不要在复制集负载饱和的时候才想到新增节点来提高承载能力，应有前瞻性。
决定复制集各成员的分布与功能¶
保证在一个数据中心中拥有多数节点¶
当复制集在多个数据中心拥有节点，且各数据中心网络隔离时，为了保证数据的复制与传输，各节点之间需要能够正常沟通。
在选举中，各节点需要能够互相沟通来保证其多数性。为了保证复制集节点能够保持多数且能够正常的选举出主节点，我们需要保证一个数据中心拥有复制集中的多数节点。
通过journaling功能来在意外掉电中保护数据¶
我们可以通过开启journaling功能个来在服务意外关闭或是掉电时保护数据。如果没有开启journaling功能，MongoDB将无法在服务意外关闭或是掉电后恢复数据。
64位的MongoDB在2.0版本后均默认开启了journaling功能。
复制集命名¶
如果应用程序需要连接多个复制集，那么每个复制集需要有独立的名字。驱动通过复制集名来进行数据库连接。
架构模式¶
下文描述了复制集架构的一些通用模式与建议。具体的复制集架构策略还是需要根据具体的应用程序需求来定制。可以将以下的架构建议融合到具体的架构策略中：
- 三个节点的复制集
我们建议复制集最少要由三个节点组成。
- 复制集中拥有四个或更多节点
拥有四个或四个以上节点的复制集可以为读操作提供更广的分布结构，且可以将某些节点用于某些专用功能。
- 异地分布式架构的复制集
通过将复制集成员分布在多个数据中心此类的地理分布的方式可以很好的防止不可抗力破坏造成的数据损毁的出现。