深入剖析MongoDB集群架构设计

一、MongoDB集群架构介绍

1.1 主从复制

1.2 副本集

1.3 分片集群

二、副本集

3.1 主节点选举

3.2 oplog

3.2 主从同步

三、分片集群

3.1 分片策略

3.2 分片键的选择

3.3 何时选择分片集群

四、总结

一、MongoDB集群架构介绍

MongoDB 有三种集群架构模式，分别为主从复制（Master-Slaver）、副本集（Replica Set）和分片（Sharding）模式。

1.1 主从复制

这种表述方式描述的是早期 MongoDB 中的一种复制模式，即一个主节点（Master）负责处理写入操作，多个从节点（Slave）被动复制主节点的数据。主从复制模式在现代 MongoDB 中已经不再推荐使用，因为它缺乏自动故障转移、数据一致性保障和灵活的读负载均衡能力。

自 MongoDB 3.6 版本起，官方已弃用主从复制模式，并推荐使用副本集（Replica Set）替代。因此，严格来说，现代 MongoDB 不再将主从复制作为一种推荐或官方支持的集群架构模式。

1.2 副本集

副本集是现代 MongoDB 中用于实现数据冗余、高可用性和读负载均衡的主要方式。它包含一个主节点（Primary）和一个或多个从节点（Secondary）。与主从复制相比，副本集提供了自动故障转移、数据一致性保证以及对从节点读取能力的精细控制。

副本集是目前 MongoDB 中主流且推荐的集群架构模式之一，用于实现数据的高可用性和读写分离。

1.3 分片集群

分片是 MongoDB 用于水平扩展、处理大规模数据集和高并发读写的架构模式。通过将数据划分为多个分片（shards），每个分片可以是一个副本集，数据根据分片键（shard key）分布在不同的分片上。此外，还包括配置服务器集群（Config Server）和路由进程（Mongos）。

分片是现代 MongoDB 中另一种重要的集群架构模式，用于处理超出单个服务器或副本集处理能力的大规模数据集。

二、副本集

MongoDB 副本集架构如下图，副本集简单来说就是有故障恢复功能的主从集群。成员身份包括主节点、从节点、仲裁者。任何时间，集群中只有一个活跃节点，其他的都为备份节点，活跃节点实际上是活跃服务器。有几种不同的类型节点可以存在于副本集中

主节点：主节点是副本集中唯一接受写操作的节点，负责处理客户端的所有写请求，如插入、更新、删除等。主节点通过心跳机制与从节点保持通信，报告自身的状态并接收从节点的状态信息。
从节点：从节点通过复制主节点的 oplog 来保持与主节点数据的同步。它们可以处理只读查询，分担主节点的读负载。从节点在保持数据同步的同时，参与副本集的选举过程，当主节点不可用时，有能力成为新的主节点。
仲裁节点：从节点在保持数据同步的同时，参与副本集的选举过程，当主节点不可用时，有能力成为新的主节点。仲裁节点的存在可以减少需要维护数据副本的服务器数量，尤其适用于资源有限的环境，或者需要额外投票节点以满足法定人数（quorum）要求的场景。

MongoDB 提供了读扩展机制，默认情况下，客户端从 Primary 读取数据，但是可以通过配置将读取操作发送到 Secondary。当负载是读取密集型时这是不错的选择。如果是写入密集型，就需要用分片来实现扩展。

3.1 主节点选举

MongoDB 在副本集中会自动进行主节点的选举，主节点选举被触发的条件：

主节点故障
主节点网络不可达(默认心跳时间为10s)
人工干预

一旦触发选举，就要根据一定规则来选举主节点，选举根据票数来决定谁获胜。

只有具有投票权的节点（包括主节点、从节点和仲裁节点）才能参与选举投票。
发起选举，符合资格的节点会向其他副本集成员发送选举请求（即投票消息），包含自己的投票意图（希望成为主节点）和当前的选举轮次信息。节点收到选举请求后，会根据自身状态和请求信息决定是否投票支持该候选节点。
每个节点在一个选举轮次中只能投一票。投票规则：
1. 优先选择具有最新数据的节点，即 oplog 时间戳最新的节点。
2. 考虑节点的优先级（priority），优先级高的节点更可能获得选票。
3. 如果优先级和数据新鲜度相同，选择具有更高节点 ID 的节点。
票数最高，获得了"大多数"成员的投票支持的节点获胜。大多数的定义为：假设集群内投票成员数量为N，最大数为N/2 + 1。例如3个成员投票，则大多数的值为2。当集群存活的成员数不足大多数时，整个复制集群无法选举Primary，集群将停止提供写服务，处于只读状态。

3.2 oplog

MongoDB 的复制集至少需要两个服务器或者节点，其中一个是主节点，负责处理客户端请求，其他的都是从节点，负责映射主节点数据。主节点记录在其上执行的所有操作。从节点定期轮询主节点获得这些操作，然后对自己的副本数据进行操作。由于和主节点执行相同的操作，从节点就能保持与主节点的数据同步。

主节点的操作记录称为 oplog，oplog 存储在一个特殊的数据库中，叫做 local。对于老版本主从复制的名称为 oplog oplog.$main，对于副本集名称为 oplog.rs。oplog 中每个文档都代表了主节点上的一个操作，文档内容如下：

ts:操作的时间戳，用于跟踪操作的执行时间
t：事务编号，用于标识属于同一事务的一组操作
v：记录oplog的版本
op:操作类型
- i:insert
- u:update
- d:delete
- c:db cmd
- db:申明当前数据库
- n:no op，即空操作，会定期执行，确保时效性
ns:操作的命名空间
o:操作所对应的具体文档，即当前操作的内容

实际的内容如下图：

需要强调的是oplog只记录改变数据库状态的操作。比如，查询就不在存储oplog中。

3.2 主从同步

从节点第一次启动时，会对主节点的数据进行完整同步。从节点复制主节点上的每个文档，耗费的资源可想而知。同步完成后，从节点通过心跳开始查询最新的 oplog 并执行这些操作，以保证数据是最新的。

从节点（Secondary）定期或持续的连接到主节点，读取并监视器 oplog。从节点将 oplog中的新记录下载到本地的 oplog 集合中，形成一个与主节点 oplog 相似的副本。从节点按照 oplog 记录的顺序，将每个操作在其本地数据副本上重新执行一遍，从而将主节点的写操作同步到自己的数据集中。这个过程通常称为“回放”（replay）。

oplog 是一个 capped collection(固定集合)，这意味着它有一个预先设定的最大容量并且会自动覆盖。当达到这个容量后，oplog 会自动删除最早的记录以腾出空间给新的写操作记录。这个容量可以通过设置 oplogSize 参数来指定，单位通常是 MB 或 GB。

当 oplog 达到其上限时，新的写操作会推动旧的记录出 oplog。这个过程是自动的，由 MongoDB 内部管理。被清理的记录是那些已经过期（即从节点已经同步）或在主节点上被覆盖（如在回滚事务时）的记录。

如果从节点在 oplog 记录被清理后还没有同步到这些记录，理论上存在数据丢失的风险。然而，MongoDB 的复制机制设计旨在尽量避免这种情况的发生：

心跳与检查点：从节点定期向主节点发送心跳消息，报告其复制进度（已复制到 oplog 中的某个时间点）。主节点在清理 oplog 时会考虑到这些信息，确保已报告同步进度的从节点不会因为 oplog 清理而丢失数据。
延迟阈值：从节点如果在一段时间内没有报告复制进度，主节点会认为该从节点可能已落后太多或出现故障，此时主节点会更加保守地管理 oplog，避免过早清理可能仍有从节点需要的记录。
数据安全窗口：管理员在配置 oplog 大小时，应考虑网络延迟、从节点处理速度等因素，确保 oplog 足够大，能容纳在最坏情况下从节点需要同步的所有操作。一般建议 oplog 大小应能容纳至少几个小时甚至一天的写操作，以应对网络中断或其他可能导致同步延迟的情况。
监控与报警：通过监控复制集的状态（如使用 rs.status() 或相关工具），及时发现复制延迟问题，并在必要时介入调整复制配置或解决网络问题，避免从节点长期落后导致数据丢失的风险。

数据一致性如何保障的？主节点在将写操作记录到 oplog 后，才会向客户端返回确认。这意味着只要主节点确认写入成功，即使此时从节点还未复制该数据，但该数据已经在主节点上持久化，能够在从节点故障时通过主节点的备份恢复。

三、分片集群

分片是 MongoDB 的扩展方式，分片是指将数据拆分，将其分散在不同机器上的过程，有时也用分区来表示这一概念。将数据分散在不同机器上，不需要功能强大的计算机就可以存储大量数据，处理更大的负载。

分片集群的组成如下

shard：每个分片包含分片数据的一个子集。每个分片都可以部署为副本集
mongos：mongos充当查询路由器，在客户端应用程序和分片集群之间提供接口
config servers：配置服务器存储集群的元数据和配置设置，存储了分片列表、每个分片包含的 chunk、路由规则等等

分片集群架构图如下：

MongoDB支持自动分片，可以摆脱手动分片的困扰。集群自动切分数据，做负载均衡。分片集群的概念：

Shard Rules：分片规则，也叫分片算法，指分发读写请求的逻辑
Shard Key：分片键，也叫路由键，指基于文档中的哪个字段进行分片计算
Document：文档，一条数据
Chunk：块，指包含一定范围内多个文档的数据段，数据集群中分割、存储数据的基本单元
Shard：分片，每个分片都由一个副本集组成，一个分片中可以存储多个Chunk
Cluster：集群，由多个Shard分片组成，统一对外提供读写服务

MongoDB 分片的基本思想就是将集合切分成小块(chunk)。这些块分散到若干片里面，每个片只负责一部分数据。应用程序不必知道哪片对应哪些数据，甚至不知道数据已经拆分，所以在分片之前需要运行一个路由进程，该进程的名字为mongos。这个路由知道所有数据存放位置，所以应用可以链接他来正常发送请求。