从一台机器扛不住说起——MongoDB Sharded
验证与回滚
说到MongoDB Sharded，很多问题都出在细节上。当你的MongoDB单机写入超过2000 QPS、数据量超过几百GB时，索引膨胀和磁盘IO会逐渐让查询变慢。这时候很多人第一反应是加机器——分片集群确实能水平扩展，但“分片”不是简单把数据拆成几份丢到不同服务器上。拆得不好，集群里的某些机器可能忙死，另一些却闲着，甚至跨片查询比全表扫描还慢。
要让分片集群真正发挥作用，就必须理解两个底层机制：Chunk分裂（数据怎么自动切分）和片键选型（按什么规则切分）。这两件事直接决定了数据分布是否均匀、请求是否会倾斜。
先搞懂Chunk：数据切分的最小单元
配置前的检查
MongoDB分片并不在文档级别直接分配，而是把数据按片键范围分成一个个逻辑块（Chunk）。每个Chunk覆盖一段连续的片键值区间，默认大小上限是64MB（可配置）。当某个Chunk的数据量增长到超过阈值，mongos或balancer会触发一次分裂操作：把这个Chunk从中间切一刀，变成两个大小相近的子Chunk。
分裂只更新配置服务器（Config Server）上的元数据，并不实际移动数据。数据仍然留在原分片上，直到后续的负载均衡器根据元数据决定是否需要迁移Chunk到其他分片。所以Chunk分裂是一个轻量操作，但频繁分裂会带来元数据压力。
理解Chunk的意义在于：片键决定了Chunk的分布边界。如果片键选得不好，Chunk根本无法分裂均匀，或者分裂后仍然集中在同一个分片上，导致“数据倾斜”。
片键选型：决定集群命运的把手
片键是你告诉MongoDB“用什么字段来切分数据”的那个字段组合。选片键时，大多数教材会列出三个指标：基数（Cardinality）、写入分布（Write Distribution）、查询隔离（Query Isolation）。但新手容易把这些概念当考试题背，忘了背后的因果。
基数：片键值不重复，Chunk才能分得开
片键的每个不同值被称为一个“分片键值”。如果片键只有男/女两个值，那整个集合最多只能分成2个Chunk（甚至因为64MB限制，也许只能分几十个），而你有10个分片，那8个分片完全是空的。因为Chunk分裂必须基于片键值区间，基数太低导致区间太少，数据就只能挤在少数几个Chunk里。
建议：片键的基数至少要比集群分片数量高一个数量级。如果对分片数没有把握，优先选择高基数字段，比如用户ID、订单号、设备序列号。
写入分布：别让所有新数据都写到最后一个Chunk
这是最容易被忽略的陷阱。假设你用时间戳作为片键，那么每分钟生成的新数据的时间戳都比旧数据大。在基于范围的片键策略下，所有新写入都落在最后一个Chunk内（因为时间戳单调递增）。这个Chunk所在的单个分片会承受全部写入压力，其他分片根本没事干。
更糟糕的是，当最后一个Chunk达到64MB后触发分裂，分裂出来的新Chunk仍然在同一个分片上，因为balancer还没来得及迁移。写入热点持续在同一个物理节点上，分片集群实际上退化为单机写入。
解决办法：要么使用哈希片键（Hashed Shard Key），让MongoDB对片键值做哈希，使相邻的时间戳散列到不同分片上；要么使用联合片键，例如{userId:1, timestamp:1}，让同一个用户的数据按时间聚集，但不同用户分散在不同的分片上。
查询隔离：让读取命中尽可能少的分片
分片集群中最昂贵的操作是“广播查询”——一个读请求被分发到所有分片，然后聚合结果。如果你经常按某个字段查询，最好把这个字段作为片键的前缀。这样查询时mongos可以精确路由到包含目标数据的Chunk所在分片，只需要访问一台机器。
例如，你的业务经常查某个用户的所有订单，那么片键设计为{userId:1, date:1}，查询时带上userId就能直接定位到只包含该用户数据的Chunk。如果片键只有date，查询某个用户时，mongos不知道这个用户的数据分布在哪些Chunk里（因为Chunk按date分区），只能向所有分片发查询，浪费资源和时间。
关联教程：此处可内链到“MongoDB Sharded部署与验证”内容。
常见片键策略对比
故障定位思路
理解了三个维度，再来看看MongoDB官方支持的两大类片键策略：
- 基于哈希的片键（Hashed Shard Key）：对片键字段计算64位哈希值，然后按哈希值范围分区。优点：写入绝对均匀，没有热点。缺点：无法进行范围查询（必须转成哈希值才能定位），且多个查询条件如果哈希字段不同仍需广播。
- 基于范围的片键（Ranged Shard Key）：按字段本身的值范围分区。优点：支持范围查询，能实现查询隔离。缺点：如果片键值单调递增或递减，写入会集中，需要额外设计联合片键来打散。
- 联合片键（Compound Shard Key）：组合两个或多个字段，比如{userId:1, timestamp:-1}。优点：可以兼顾业务查询模式和写入分布。缺点：复杂度高，一旦选定后期无法修改，必须提前设计好。
相关阅读：此处可内链到“MongoDB Sharded常见问题”专题。
实际选型：从业务需求反推
故障定位思路
假设你有一个物联网平台，设备每10秒上报一条数据，写入量极大，且经常需要查某台设备最近的100条记录。这时片键可以这样选：
- 如果用deviceId做哈希片键：写入均匀，但查某个设备的最近数据时，即便带着deviceId，由于哈希片键不支持范围查询，还得用其他方式（比如在应用层加时间过滤）。
- 如果联合片键{deviceId:1, timestamp:-1}：同一个设备的数据会落在同一个Chunk（范围分区），查询某设备的时间段只需扫描一个Chunk，但不同设备分散到不同Chunk。问题在于如果只有一个设备写入量大，那个Chunk会成为热点——但实际场景中设备数量足够多，单一设备压力有限，这种策略是可以接受的。
总结一下：有大量写入且无法预测查询模式时，无脑选哈希片键；读多写少且查询固定字段时，用联合片键把高频查询字段放前面；永远不要直接用单调递增字段（如时间戳、自增ID）做单字段范围片键。
延伸阅读：此处可内链到“MongoDB Sharded配置案例”相关文章。
进阶阅读：此处可内链到“MongoDB Sharded性能优化”指南。
补充参考：此处可内链到“MongoDB Sharded故障排查实例”。
验证你的片键选择
实际操作要点
动手之前可以做两件事：第一，用MongoDB自带的sh.status()查看现有分片集群的Chunk分布；第二，在测试环境用模拟数据跑一下，监控Chunk数量、大小和迁移次数。如果某个分片上的Chunk数量长期是其他分片的十倍，说明片键失效，需要重建集合。
注意：MongoDB的片键一旦设置后无法修改（除非重新导入数据或使用分片升级特性）。所以选型时务必谨慎，宁可通过预分片多建几百个空Chunk，也比后期发现数据倾斜重新迁移要好。
MongoDB Sharded：写在最后
我的处理经验
Chunk分裂是MongoDB分片集群的自动调节机制，但设计再好的算法也填不了片键选型的坑。记住三个关键决策点：基数足够大、写入不扎堆、读查询能按片键定位。下次面试或面试官问你“MongoDB分片集群怎么设计片键”，别只背概念，把今天聊的三个维度和常见反例说清楚，就够了。把这些步骤跑通后，MongoDB Sharded基本就能稳定落地。
延伸阅读