原文
架构影响着副本集的容量和能力。本文描述了通用的架构部署和提供部署策略。
标准的副本集生产环境由3个成员组成。他们之间相互提供冗余和容错能力。为了尽可能的避免复杂化，你应该根据你的应用程序需求来部署相应架构。
策略
确定副本集成员的数量
根据以下策略添加你的成员。
成员数量的上限
一个副本集最多能拥有50个成员，但是只有最多7个成员拥有投票权，如果副本集中已经有7个投票成员，额外的成员必须为 non-voting members.
成员数量部署为基数
确保副本集的投票成员数量为基数，如果你的副本集投票成员为偶数，部署一个 arbiter来确保投票成员为基数。
arbiter成员不会持有数据副本且仅需消耗很少资源。你可以将 arbiter运行在应用服务器或者共享进程上。arbiter不持有数据副本，可能的话你应该将 arbiter部署在一个你不会放置其他成员的环境中。
pv1对比pv0的arbiters，以下版本增加了 w:1回滚的可能性
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
See Replica Set Protocol Versions.
警告：
一般情况下，每个副本集中仅能存在一个arbiter
容错性
成员数量：当服务器不可用的时候仍然能有足够的成员来进行投票以便选举出新的主服务器。换句话来说，副本集中的成员数量和能够参与投票的成员是不同的。没有了主服务器，整个副本集就无法接受写操作。容错服务器对副本集的大小产生影响，但并无直接关系，参照下表：
往副本集新增一个成员并不总是增加容错性。然而在这样的情况下，额外的成员可以对专用功能提供支持，例如备份或者报告。
对专用功能使用隐蔽式成员和延迟成员
在一个读取流量非常高的情况下，你可以将部分流量分发给备份服务器以提高吞吐量。随着你的部署增长，将成员移动或者增加到备份数据中心以提高冗余性和可用性。
请务必确定你的主数据中心设施可以选举出一个新的主服务器。
增加需求容量
现有的副本集成员中，一定要有支持添加新成员的剩余容量。
请在需求对于当前副本集来说达到饱和前添加新成员。
