阅读MongoDB分片架构的官方文档后，我还没有发现为什么你需要一个或三个配置服务器，而不是另一个数字。
配置服务器上的MongoDB文档说:
"如果一个或两个配置服务器不可用，集群的元数据变为只读。您仍然可以从分片中读写数据，但是在所有三个服务器都可用之前不会进行块迁移或分割。"
因此反射:一台服务器相当于单点故障，但两台服务器的行为与三台服务器相同，对吗?
那么，为什么绝对是三个服务器，而不是两个或更多呢?
因为文档还说:
配置服务器不能作为副本集运行。
配置服务器协议
MongoDB 3.0及更早版本只支持单一类型的配置服务器部署协议，该协议被称为MongoDB 3.2的旧SCCC(同步集群连接配置)。SCCC部署有1个配置服务器(仅用于开发)或3个配置服务器(用于生产)。
MongoDB 3.2弃用SCCC协议，支持新的部署类型:配置服务器作为复制集(CSRS)。CSRS部署与标准副本集具有相同的限制，标准副本集可以有1个配置服务器(仅限开发)或多达50个服务器(生产)，如MongoDB 3.2。对于生产部署中的高可用性，建议至少使用3台CSRS服务器，但是对于地理上分布的部署，额外的服务器可能很有用。
SCCC(同步集群连接配置)
使用SCCC，配置服务器使用两阶段提交协议更新，该协议需要多个服务器对事务达成共识。您可以在测试/开发中使用单个配置服务器，但在生产环境中，您应该始终使用3个配置服务器。为什么你不能在MongoDB中只使用2个(或超过3个)服务器的实际答案是MongoDB代码库只有支持1或3个配置服务器用于SCCC配置。
三个服务器提供了比两个服务器更强的一致性保证，并且允许在一个配置服务器上进行维护活动(例如，备份)，同时仍然有两个服务器可供mongos查询。超过三个服务器将增加跨所有服务器提交数据所需的时间。
您的分片集群的元数据需要在所有配置服务器上是相同的，并由MongoDB分片实现维护。元数据包括当前哪些分片保存文档范围(也称为chunks)的基本细节。在SCCC配置中，配置服务器不是副本集，所以如果一个或多个配置服务器脱机，那么配置数据将是只读的——否则，当它们重新联机时，数据将无法传播到脱机的配置服务器。
显然1配置服务器不提供冗余或备份。对于2配置服务器，一个潜在的故障场景是服务器可用，但服务器上的数据不一致(例如，其中一个服务器有一些数据损坏)。使用3个配置服务器，您可以改进前面的场景:2/3的服务器可能是一致的，您可以识别出奇怪的服务器。
CSRS (Config Servers as Replica Sets)
MongoDB 3.2不支持在配置服务器上使用三个镜像的mongod实例，并且从3.2开始配置服务器(默认情况下)作为副本集部署。副本集配置服务器必须使用WiredTiger 3.2+存储引擎(或其他支持新的readConcern读隔离语义的存储引擎)。CSRS还禁止一些不适合分片集群元数据用例的非默认副本集配置选项(例如arbiterOnly, buildIndexes和slaveDelay)。
CSRS部署提高了配置服务器的一致性和可用性，因为MongoDB可以利用标准副本集读写协议对配置数据进行分片。此外，这允许一个分片集群有超过3个配置服务器，因为一个副本集可以有多达50个成员(在MongoDB 3.2)。
对于CSRS部署，写可用性取决于维护一个仲裁成员，该成员可以看到副本集的当前主节点。例如，一个3节点的副本集需要2个可用成员来维护主节点。为了提高容错性，可以添加额外的成员，遵守与普通副本集相同的选举规则。mongos使用majority的readConcern来确保分片集群元数据只有在提交给大多数复制集成员时才能被读取，nearest的readPreference用于将请求路由到最近的配置服务器。