“不相干片键”比“高基数字段”更关键，因其决定写入是否均匀打散到各分片；高基数如 _id 若具顺序性仍致写热点，而伪随机哈希前缀（如 base36 随机串）配合 hashed 分片才能真正解耦时序与业务逻辑，实现负载均衡。
为什么“不相干片键”比“高基数字段”更关键
很多人误以为只要选个高基数字段（比如 _id）当分片键就能撑住并发写入，结果上线后发现写入吞吐卡在单分片上。根本问题在于：MongoDB 的分片路由不是看字段取值多不多，而是看写入请求是否被 均匀打散到不同分片。如果业务写入集中在某个时间窗口（如每分钟整点批量上报），而片键又和时间强相关（如 timestamp 或 createdAt），就会产生“写热点”——所有新文档都落到同一个分片的最新 chunk 上。
所谓“不相干片键”，是指该字段与写入时序、业务逻辑路径、用户会话周期等完全解耦。例如：sessionId 是用户级唯一，但若 session 生命周期短、大量创建销毁，仍可能局部聚集；而用 Math.random().toString(36).substring(2, 10) 生成的伪随机哈希前缀（拼进 _id 或独立字段），配合 hashed 分片策略，才能真正打散写入压力。
- 推荐方案：
{ "shardKey": "hashPrefix" }，其中hashPrefix是 6–8 字符的 base36 随机串，写入前由应用层生成 - 避免使用：
userId（用户行为有峰谷）、timestamp（天然单调）、auto-increment id（即使转成字符串也逃不开顺序性） - 验证方法：插入 10 万条带
hashPrefix的模拟数据后，执行sh.status()，观察各分片的chunks数量是否接近均值 ±15%
多 mongos 节点不是加机器就有效
部署多个 mongos 实例只是第一步，真正决定并发上限的是客户端连接如何分发、以及每个 mongos 自身的连接池是否被压垮。Spring Boot 默认的 MongoClient 是单例且共享连接池的，即使你起了 3 个 mongos，所有请求仍可能通过同一个 mongos 转发出去——因为 DNS 负载均衡或客户端未启用多地址解析。
- 必须显式配置连接字符串为多个地址：
mongodb://mongos1:27017,mongos2:27017,mongos3:27017/chatdb?loadBalanced=true，并确保loadBalanced=true参数存在（MongoDB Java Driver 4.11+ 才真正支持） - 禁用
maxWaitTime等超时参数的默认值，改用maxConnectionLifeTime=0+minPoolSize=50+maxPoolSize=200，否则高并发下连接池会成为瓶颈 - 每个
mongos进程内存建议 ≥4GB，否则在大量聚合路由时 GC 停顿明显，反而拖慢整体响应
retryWrites=true 在分片集群里要谨慎开
虽然 MongoDB 4.2+ 默认开启可重试写入，但在分片场景下，retryWrites=true 可能引发隐性问题：当某次 insertOne 因网络抖动失败，驱动会自动重试，但重试请求可能被另一个 mongos 接收，而该 mongos 的元数据缓存尚未刷新，导致重复写入或路由错误。这不是 bug，而是最终一致性模型下的合理行为。
- 生产环境建议显式关闭：
mongodb://.../chatdb?retryWrites=false - 把重试逻辑收归应用层：捕获
MongoSocketReadTimeoutException、MongoTimeoutException后，用幂等 key（如eventId+timestamp组合）查表确认是否已写入，再决定重试或跳过 - 注意：事务内的写操作不受
retryWrites控制，提交/中止本身永远可重试，这点无法绕过
真正卡性能的往往是索引写放大
分片解决了数据分布，但没解决单文档写入成本。MongoDB 6.0 默认为每个字段建索引？当然不。但如果你在 chat_sessions 集合上为 userId、sessionId、createdAt、messages.role、messages.timestamp 全部建了独立索引，那每次插入一条含 5 条消息的文档，实际要更新 5 ×（索引数 + 1）个 B-tree 页面——这比网络传输耗时还高。
- 只对查询条件中 必然出现且非前导通配 的字段建索引，例如
{ "userId": 1, "createdAt": -1 }是合理的，但单独为messages.type建索引几乎无意义 - 嵌套数组字段优先用
createIndex({ "messages.timestamp": 1 })，而不是.createIndex({ "messages": 1 })，后者会为整个数组生成索引项，膨胀严重 - 写密集场景下，考虑关闭
journal（仅限日志类数据），或启用wiredTigerEngineConfigString: "cache_size=8G"避免刷盘争抢
分片键设计和 mongos 路由是可控的，但索引膨胀、journal 刷盘、驱动重试策略这些细节，才是压测时突然掉吞吐的真正原因。它们不会报错，只会让 P99 延迟从 12ms 慢慢爬升到 300ms。
