MongoDB 副本集与分片

这篇笔记专门整理 MongoDB 在可用性和扩展性上的两条主线：

1. Replica Set 负责高可用和数据冗余
2. Sharding 负责容量和吞吐扩展

很多人第一次接触 MongoDB 时，会把注意力放在文档模型上，但只要系统进入生产环境，真正绕不过去的往往就是：

副本集怎么稳、读写路径怎么走、分片键怎么选。

---

1. 🌟 为什么副本集是 MongoDB 的基础形态

MongoDB 生产环境里最常见的高可用形态是副本集。它通常由多个节点组成，其中会有：

1. 主节点
2. 从节点
3. 选举机制

主节点负责处理主要写入，请求写成功之后，数据会复制到其他节点。这样做的直接价值是：

1. 提高可用性
2. 提供数据冗余
3. 在故障时支持自动切换

也就是说，副本集不是“有空再加”的高级功能，而是 MongoDB 进入正式运行之后的基础能力。

---

2. 副本集到底解决了什么问题

副本集主要解决的是这几类问题：

1. 单节点故障导致服务完全不可用
2. 数据只有一份，故障后恢复成本过高
3. 运维过程中无法平滑切换节点

它带来的收益可以简单理解为：

维度	副本集带来的价值
可用性	主节点故障后可选举新主
数据安全	数据存在多个副本
运维弹性	节点维护、扩容更从容

但它没有凭空消除所有复杂度，新的问题也会一起进入系统：

1. 复制延迟
2. 读写路径需要明确
3. 故障切换期间会有短暂抖动

---

3. 副本集下的读写路径怎么理解

最基础的理解是：

1. 写通常进入主节点
2. 从节点复制主节点的数据
3. 读可以根据一致性和压力策略决定走主还是走从

但真正落到工程上，通常要把这几个问题想清楚：

1. 哪些读必须读主
2. 哪些读能容忍一定延迟
3. 复制延迟升高时是否要降级

如果业务刚写完就立刻读取，而且读取结果必须是最新的，那么这类请求通常更适合走主节点。
如果是报表、列表、低一致性要求查询，可以结合从节点分担读压力。

副本集的关键从来不是“能不能读从库”，而是：你是否清楚哪些请求能接受旧数据，哪些请求绝对不能。

---

4. 🌟 复制延迟为什么必须纳入治理

只要有主从复制，就会有一个绕不开的问题：从节点追上主节点需要时间。

复制延迟带来的典型表现是：

1. 主节点写入成功
2. 应用立刻去从节点读
3. 从节点还没追上
4. 结果读到旧数据

这和 MySQL 读写分离里遇到的问题本质上很像。

所以 MongoDB 副本集治理里，至少要持续关注：

1. 节点复制延迟
2. 主从角色变化
3. 节点心跳状态
4. 主节点切换频率
5. 写入确认策略和失败率

如果复制延迟已经明显抬升，就不应该继续把强依赖最新数据的读取压到从节点上。

---

5. 写关注和读偏好不是“配置一下就结束”

MongoDB 里经常会遇到两个概念：

1. write concern
2. read preference

它们分别决定：

1. 写到什么程度才算成功
2. 读请求优先从哪些节点读取

更实用的理解是：

5.1 write concern

它决定写入确认的严格程度。要求越高，写成功的可信度越强，但写入延迟和可用性成本也可能更高。

5.2 read preference

它决定查询是优先走主节点，还是允许走从节点。策略选得越激进，读扩展能力越强，但读到旧数据的概率也越高。

所以这两个配置都不是“框架默认给什么就用什么”，而是要结合业务一致性要求来定。

---

6. 🌟 分片在解决什么问题

当单机容量、单副本集吞吐或者热点压力继续增长时，仅靠副本集已经不够了，这时就会进入分片阶段。

分片解决的核心问题通常是：

1. 单节点存储上限
2. 单节点读写吞吐瓶颈
3. 数据规模继续增长后的横向扩展问题

MongoDB 分片的基本思路是：按 shard key 把数据分散到多个分片上，让单点容量和流量压力被拆开。

它带来的收益是：

1. 容量可横向扩展
2. 吞吐可随分片增加而提升
3. 大数据集更容易分散到多台机器

但真正决定系统效果的，往往不是“有没有分片”，而是“分片键到底选得怎么样”。

---

7. 🌟 shard key 为什么是分片设计的核心

shard key 会直接决定：

1. 数据怎么分布
2. 查询是否只打到单分片
3. 是否出现热点分片
4. 写流量是否倾斜

一个不合适的分片键，常见会导致这些问题：

1. 数据大量堆到少数分片
2. 某个热点值把写流量集中在单点
3. 查询经常变成广播到多个分片

选择分片键时，通常至少要看这几件事：

1. 分布是否足够均匀
2. 是否贴合主要查询条件
3. 是否会持续产生热点
4. 后续扩容迁移成本是否可控

例如单调递增字段，如果直接作为分片键，就容易把新写入持续压到一个方向上，带来明显热点。

---

8. 分片之后会新增哪些复杂度

分片不是“拆了就轻松”，而是把单点压力换成分布式复杂度。

常见新增问题包括：

1. 广播查询增加
2. 跨分片聚合更重
3. 热点分片治理复杂
4. 扩容和数据迁移需要更仔细规划
5. 排障维度从单节点变成多节点协同

所以分片更适合作为系统规模增长后的架构动作，而不是一开始就默认开启的配置。

---

9. 副本集和分片之间是什么关系

可以把它们理解成两个不同层面的能力：

1. 副本集解决的是高可用和副本冗余
2. 分片解决的是水平扩展

它们不是互斥关系，真实系统里往往是：每个分片本身仍然由副本集组成。

这意味着一旦进入分片集群，系统同时要处理：

1. 分片间的数据分布问题
2. 分片内部的副本集复制问题

也正因为如此，MongoDB 集群治理的重点从来不只是“把节点拉起来”，而是持续关注：

1. 数据分布均衡度
2. 副本集健康状态
3. 路由层请求分布
4. 查询是否命中目标分片

---

10. 一份更实用的副本集与分片检查清单

可以优先检查这些问题：

1. 是否已经使用副本集，而不是单节点运行
2. 关键读请求是否明确区分读主和读从
3. 复制延迟是否被持续监控
4. 故障切换后应用是否能平滑恢复
5. 分片键是否贴合主查询路径
6. 是否存在热点分片或明显数据倾斜
7. 广播查询和跨分片聚合是否过多

MongoDB 集群能力真正难的部分，不是配置项本身，而是你能不能把一致性要求、读写路径、分片策略和运维治理一起设计清楚。