副本集架构 —— 一主一从一选举
Load Balancer
在 MongoDB 的分片集群中，每个 shard 实际上就是一个副本集。尽管你可以配置一个单一的 mongod 作为一个 shard，但在生产环境中，通常每个 shard 都会设置为副本集以提供数据冗余、故障恢复能力和高可用性。每个副本集（shard）通常会包含一主一从一选举节点，即一个主节点（Primary）和一个从节点（Secondary）以及一个仲裁节点（Arbiter）。这种结构保证了当主节点出现故障时，可以快速地在剩余的从节点之间进行选举，选出新的主节点，继续提供服务。因此，MongoDB 的分片集群是由多个副本集构成的，每个副本集保管着部分数据，这种方式既实现了数据的分布式存储，又保证了数据的冗余和可用性。
Arbiter
Mongos
... ...
Primary
Client
mongos 作为 MongoDB 分片架构的核心组件，扮演着应用服务器与数据库之间的路由器（Router）角色。它会负责根据存储在配置服务器（Config Server）中的集群元数据，将客户端的读写请求正确地定向到相应的分片节点或副本集。这样设计的关键在于 mongos 自身并不进行数据存储，也不参与副本集的选举或同步流程。mongos 实例的 \"无状态\" 设计使其可以作为灵活的路由器在复杂的分片环境中运作，在客户端请求需要在多节点间进行路由时提供准确的指向。为了提升系统的可用性并实现负载均衡，生产环境通常会部署多个 mongos 实例。这意味着，当然有的 mongos 实例发生故障时，其他尚在正常运作的实例可以顺利接手处理请求，保障系统运行的稳定性。
一主两从的架构包含了一个主节点和两个从节点，这已经形成了一个奇数节点的集群，所以我们不需要专门的仲裁节点。当主节点发生故障，存在的两个从节点可以进行投票来选择新的主节点，由于存在两个节点，所以仍然满足了 MongoDB 中的“大多数（50%以上）”的投票原则。这个过程能够保证副本集的数据一致性和高可用性。
Heartbeats
Replication
Secondary
在一主一从的架构中，我们有两个数据节点，一个主节点和一个从节点。如果主节点宕机，根据 MongoDB 的设计，从节点需要获取大多数投票（超过所有节点一半）才能提升为新的主节点。然而，在只有两个节点的环境中，这个限制无法满足，因为只剩下一个从节点，它得不到足够的投票。为了解决这个问题，我们添加了一个仲裁节点。仲裁节点不持有数据，他们只投票。例如，如果主节点宕机，仲裁节点可以投票给从节点，使其成为新的主节点。
负载均衡器有很多种实现方案，以下是一些常见的负载均衡解决方案：1. 硬件负载均衡器：如 F5 BIG-IP、Cisco ACE、Citrix NetScaler。硬件负载均衡器通常在高流量的网络中使用，可提供高性能和高可靠性，但价格相对较高。2. 软件负载均衡器：如 Nginx、HAProxy、LVS (Linux Virtual Server)。软件负载均衡器更加灵活，安装和维护成本相对较低。它们通常运行在普通的服务器上，使用一种或多种算法（如轮询、最小连接等）来分发请求。3. 云服务提供商的负载均衡服务：如 Amazon 的 Elastic Load Balancer (ELB)、Google Cloud Load Balancing、Azure 的 Load Balancer。这些服务可以与云服务提供商的其他服务（如自动扩展等）很好地集成在一起，易于设置和使用。
副本集架构 —— 一主两从
Shard
Config Servers
分片集群 HA 架构
在 MongoDB 分片集群的生产环境中，配置服务器（Config Server）通常是由至少三个节点构成的副本集。每个配置服务器节点都保存着整个集群的元数据，包括集群中每个分片（shard）的数据范围等信息。当路由器（mongos）需要知道如何路由请求时，它会查询配置服务器以确定应该将请求发送到哪个分片。在生产环境中，为了高可用性和数据的一致性，一般会配置三个配置服务器节点作为一个副本集。这种配置下，即使某一个配置服务器节点发生故障，剩下的两个节点依然可以组成大多数（majority），继续提供服务，同时也可以选出新的主节点。这就保证了配置服务器的正常运行，使得分片集群能够正常地路由和处理请求。
