上一篇讲了分片存在的理由。这一篇讲分片集群的架构——它不是「几台机器各存一部分数据」那么简单，而是三层组件协作的系统：mongos（路由）、config server（元数据）、shard（数据分片）。理解这三层的分工，才能理解分片集群怎么工作、故障怎么定位、扩容怎么操作。
先把机制边界说清楚
分片集群由三类组件构成：
- mongos：路由进程。应用连的是 mongos，不是 shard。mongos 接收请求，查 config server 知道数据在哪个 shard，转发请求到对应 shard，汇总结果返回应用。
- config server：存集群元数据的特殊复制集（必须是复制集，3 节点）。它记录「哪个片键范围的数据在哪个 shard」的映射关系。mongos 靠它路由。
- shard：实际存数据的分片。每个 shard 本身是一个完整的复制集（有自己的 Primary/Secondary），所以分片集群的每个 shard 都自带高可用。
这三层的关系是：应用 → mongos → (查 config) → shard。应用完全不需要知道数据怎么分、存在哪，它只连 mongos，对应用来说分片集群和单机几乎无差别。
三层架构
把三层画出来，各自职责清晰。这套架构的精巧之处在于分层解耦：路由无状态可扩展，元数据集中管理，数据分散存储且各自高可用。
mongos：无状态路由
mongos 是应用和分片集群之间的「前台」。它的职责：
- 接收应用的读写请求。
- 根据请求里的片键，查 config server 确定数据在哪个 shard。
- 把请求转发到目标 shard（单 shard）或多个 shard（广播查询）。
- 汇总结果返回应用。
mongos 是无状态的——它不存数据，所有路由信息都从 config server 获取（并缓存）。这意味着 mongos 可以任意水平扩展：部署多个 mongos 实例，用负载均衡分摊请求。通常每个应用机房都部署 mongos，让应用就近连接，降低网络延迟。
mongos 重启后会重新从 config server 加载路由表（有缓存机制，不是每次请求都查）。如果 config server 元数据变化（比如块迁移），mongos 会感知并更新缓存。
config server：集群的大脑
config server 是分片集群最关键的组件，它存的元数据包括：
- ** chunk 映射**：每个 chunk（数据块）的片键范围，以及它属于哪个 shard。这是 mongos 路由的依据。
- shard 列表：集群里有哪些 shard。
- 数据库和集合的分片配置：哪些集合启用了分片、用什么片键。
config server 必须是复制集（3 节点，生产标配），因为它一旦故障，整个集群的路由就瘫痪了（mongos 查不到元数据）。所以 config server 本身要有高可用。
config server 的数据量很小（只是元数据，不是业务数据），但对一致性要求极高。所有 chunk 迁移、shard 增减，都要先更新 config server。它是整个集群的「真相来源」。
shard：自带高可用 的数据分片
每个 shard 是一个完整的复制集，存一部分数据。关键认知：
- shard 之间数据不重叠（正常情况下），每个文档只属于一个 shard。
- 每个 shard 自带高可用：Primary/Secondary 的复制集结构，shard 内部故障自动 failover。
- shard 独立运维：每个 shard 可以单独扩容、备份、优化，互不影响。
shard 的数量决定了集群的容量上限。加 shard 就能扩容——新数据会被分配到各个 shard（或新 shard），实现近线性扩展。但 shard 数量不是越多越好，因为跨 shard 的协调（config server 管理、balancer 均衡）也有开销。
应用为什么对分片无感知
分片架构最大的设计目标是「对应用透明」。应用连接 mongos，发出的查询和连接单机几乎一样：
- 查询带片键 → mongos 直接路由到目标 shard（定向查询，最高效）。
- 查询不带片键 → mongos 把查询发到所有 shard，汇总结果（广播查询 / scatter-gather，开销大）。
- 写入带片键 → 路由到对应 shard。
应用唯一要感知的是：查询尽量带片键，否则会触发广播查询。这是分片使用最重要的优化原则，第 30 篇会展开。
这种透明性的价值是：从单机/复制集迁移到分片集群，应用代码几乎不用改（除了注意片键查询）。代价是 mongos 多了一层路由开销，且广播查询会放大负载。
取舍与边界
分片架构的优势是近线性扩展和应用透明。代价：
- 组件多，运维复杂。mongos、config server、shard 都要监控和管理，比复制集复杂数倍。
- config server 是单点瓶颈（逻辑上）。虽然它是复制集，但所有路由都依赖它，它故障影响全局。
- 跨 shard 操作受限。跨 shard 事务、跨 shard 聚合有性能代价，广播查询放大负载。
- 网络开销。每次请求要经 mongos 转发，比直连单机多一跳。
判断框架
- 应用连 mongos，不直连 shard，对分片无感知。
- mongos 无状态可扩展，多实例 + 负载均衡，与应用同机房部署。
- config server 存路由元数据，必须是 3 节点复制集，是集群的大脑。
- 每个 shard 是独立复制集，自带高可用，可独立运维。
- 查询带片键 = 定向查询（高效）；不带片键 = 广播查询（昂贵）。
- 分片集群运维复杂度是复制集数倍，能不用就不用。
下一篇讲整个分片阶段最关键的决策——片键设计。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会按分片集群和架构选型这条线更新。
