目录
一、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)
- 人工干预
一旦触发选举，就要根据一定规则来选举主节点，选举根据票数来决定谁获胜。
- 只有具有投票权的节点（包括主节点、从节点和仲裁节点）才能参与选举投票。
- 发起选举，符合资格的节点会向其他副本集成员发送选举请求（即投票消息），包含自己的投票意图（希望成为主节点）和当前的选举轮次信息。节点收到选举请求后，会根据自身状态和请求信息决定是否投票支持该候选节点。
- 每个节点在一个选举轮次中只能投一票。投票规则：
- 优先选择具有最新数据的节点，即 oplog 时间戳最新的节点。
- 考虑节点的优先级（priority），优先级高的节点更可能获得选票。
- 如果优先级和数据新鲜度相同，选择具有更高节点 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。这个路由知道所有数据存放位置，所以应用可以链接他来正常发送请求。
3.1 分片策略
将数据分散到不同的机器上通常有两种方案，Hash和范围划分。
Hash分片：把 Key 作为输入，输入到一个 Hash 函数中，计算出一个整数值，值的集合形成了一个值域，我们按照固定步长去切分这个值域，每一个片叫做 Chunk ，这里的 Chunk 则就是整数的一段范围而已。
优点事速度快，均衡性好，但排序性差
范围分片：按一定的范围进行切分，与 TiDB 类似。优点是排序性好，缺点是容易引起热点数据。
3.2 分片键的选择
设置分片时，需要从集合里选一个键，用该键的值作为数据拆分的依据。这个键称为片键(shard key)。
片键分为递增片键和随机片键，该如何选择呢？
如果写入负载很高的话，不适合使用递增片键，比如时间戳，因为写入会集中在一个片内，但递增片键查询效率非常高。如果写入负载很高的话，选择随机片键，均匀分散负载到各个片上。
不论片键随机跳跃还是稳定增加，片键的变化至关重要，例如，如果有个“logLevel”键只有3个值，DEBUG、WARN 或 ERROR，MongoDB 就无论如何也不会把他作为片键将数据分为3块。如果键的变化太少，但又想将其作为片键，可以将这个键与一个变化较大的键组合起来。
3.3 何时选择分片集群
出现下面信号时就可以考虑分片了
- 机器的磁盘不够用了
- 单个mongod已经不能满足写数据性能要求
- 想将大量数据放在内存中提高性能
一般来说，先要从不分片开始，然后再需要时将其转换成分片。虽然提供了更强的扩展性和容错能力，但分片集群架构更为复杂，需要管理配置服务器、路由节点（Mongos）、分片节点以及相关网络配置，运维成本较高。同时，硬件和云资源需求可能增加，导致成本上升。
四、总结
当讨论 MongoDB 的集群架构时，应强调副本集和分片这两种官方推荐和支持的模式。如果在历史背景下讨论，可以提及主从复制作为早期的一种复制方式，但需明确指出它在现代 MongoDB 中已不再适用。
往期经典推荐：
探索非关系型世界：MongoDB核心概念全解析-CSDN博客
TiDB存储引擎TiKV揭秘-CSDN博客
深入浅出 TiDB MVCC：揭秘分布式数据库中的多版本并发控制-CSDN博客
揭开Spring Bean生命周期的神秘面纱-CSDN博客
深入JVM内核揭示Java多态背后的神秘机制-CSDN博客
