先说说我为什么会写这篇东西。前几天团队里有个兄弟凌晨三点给我打电话说线上MongoDB单机节点磁盘写满了写入直接拒绝服务日志在刷no space left。这哥们儿平时挺稳的那晚也慌了。后来我远程看了一眼三百多个G的数据索引已经膨胀到比数据本身还大工作集远超内存慢查询一堆整个库基本等于瘫痪。最后我们花了两个通宵做分片迁移中间踩了不下十个坑每一步都像在雷区里走路。这文章就是把这十来年的MongoDB分片经验加上那两晚的血泪一起拆开揉碎讲清楚。从单机为什么会崩、分片的架构设计怎么做、分片键怎么选到完整的搭建实操、生产环境真实的坑一篇拉通。适合正在评估分片方案、准备从单机升集群或者已经在分片集群上但被各种诡异问题折磨的团队参考。1. 分片不是什么玄学先看懂单机MongoDB为什么会“崩盘”1.1 单机节点真正的瓶颈到底在哪里先说结论单机MongoDB崩掉通常不是某一个原因而是容量、写入吞吐、内存工作集三者同时逼近极限之后的连锁反应。磁盘容量是最先暴露的。日志类、订单类、埋点类数据一旦日增量在GB级别几百GB的单块磁盘很快就会被塞满。MongoDB的存储引擎WiredTiger在做删除和覆盖写时会产生大量的磁盘碎片和旧版本数据磁盘空间的实际消耗效率远比你想象的低。写入吞吐是第二个坎。单节点的写入能力受限于单个mongod进程所拥有的CPU核数、内存带宽和磁盘IOPS。你在单机上跑了高并发写入开始可能还能撑住每秒几千次写入但一旦数据量膨胀、索引变多写放大和锁竞争会把吞吐一路往下拽。等到大量更新操作开始做文档迁移和索引更新写性能会呈断崖式下跌。最容易被忽略的是内存工作集。MongoDB的索引和频繁访问的热数据需要尽量驻留在内存里。当热数据集超过可用内存的合理比例我一般按不超过50%来压测评估查询开始频繁触发磁盘页面换入换出延迟从几毫秒直接飙到几百毫秒。这时候你再怎么加索引、优化查询效果都很有限因为瓶颈已经到了物理资源的层面。1.2 分片到底做了什么以及它没做什么分片的本质是水平扩展。它把一个集合的数据按照你指定的分片键拆成若干个chunk分散存储到多个shard节点上。每一个shard本质上还是一个独立的MongoDB实例生产环境至少是副本集对外则统一由mongos路由节点提供接入。这里面有个生活化的类比单机MongoDB就像一个大仓库所有货物堆在一起找货要全仓库翻。分片之后仓库被拆成好几栋楼货物按规则分片键分到不同楼管理员mongos根据取货单直接告诉你该去哪栋楼拿速度快得多容量也大得多。标题里写的“千倍扩容”虽然有点夸张但从单机几百GB到分布式集群几百TB数量级上确实是千倍的跨越。但有一点必须泼冷水分片不能解决所有问题。分片键选错了查询不但没变快反而因为要广播到所有shard再合并结果比单机更慢。单条文档超过16MB的上限不会因为分片而改变。跨分片的join、事务、聚合在性能和复杂度上都有额外代价。分片不是为了炫技存在的它是在单机确实到极限之后才该引入的架构级方案。1.3 什么时候真的应该上分片判断要不要上分片我的经验就三个硬指标满足两个以上就该认真规划了数据总量超过单机磁盘合理承载能力的70%且还在增长。估算行情一台物理机挂1TB ssd最终可用也就800G出头MongoDB数据文件加上索引业务数据300G就开始疼。写入TPS持续增长单节点CPU长期在70%以上且加副本集只解决读扩展解决不了写扩展。热工作集明显超过内存缓存命中率持续走低慢查询占比超过5%。如果只是读多写少优先加副本集做读写分离。如果只是单机磁盘快满但数据可以归档清理先做数据生命周期管理。分片是重武器上线后运维心智负担上升一个量级不是随便玩的。2. 容量规划与分片键选型这一步错后面步步错2.1 从“千倍扩容”倒推回容量规划聊到扩容很多团队第一反应是“把机器买够就行了”。实际上分片集群的容量规划是个整体工程不是堆机器。我在动手之前一般按这套逻辑来做估算当前数据量直接看集合的db.collection.stats()拿size和totalIndexSize相加这是数据层真实占用。增长速率统计最近30天/90天的数据增量算月均增长率。很多业务是季节性爆发的比如年底促销、活动月只按均值来规划后面一定会被打脸。保留周期日志类和账单类数据往往是按天清理或归档的。有些业务SLA要求保留多年这类数据即使切成归档表也需要计入总量。冗余与写放大分片集群里每个shard是副本集数据本身就有副本冗余。三副本下一份真实数据在物理磁盘上至少占三份空间。再加上内部移动和rebalance过程中的临时复制保守按3.5到4倍来预算物理存储。举例来说假设业务当前真实数据500G月增50G需要保留24个月三副本。那么最终规划容量是(500G 50G×24) × 4 ≈ 6800G约6.8T。按每台shard挂2T磁盘算至少需要4个shard考虑到平衡时段和后续增长余量我会建议起步直接上6个shard。2.2 分片键为什么是分片集群的生死线如果说分片集群是一条船分片键就是这条船的龙骨。龙骨弯了船再好也白搭。分片键决定了数据怎么被切分也决定了查询能不能被路由到正确的shard更决定了写入压力是均匀分摊还是集中打到一个节点上。分片键的选择我总结了四个核心原则高基数分片键可能的取值必须足够多。比如用星期几做分片键最多只有7个值chunk数量上不去分布永远不可能均匀。低频率变化分片键字段一经写入最好永远不变。分片键自带immutable约束改了会导致整个文档必须迁到另一个shard代价极大。分布均匀写入请求要能均匀分散到各个shard。用时间戳做分片键如果业务是持续产生的某个时刻的写入永远会落在某个时间区间所在的那个chunk上。高频查询带得动业务里最重要的查询条件如果包含分片键mongos就能精确路由到特定shard不用广播所有分片再合并。我见过最典型的一个反例是把订单表按createTime做范围分片。表面上看订单创建时间天然不重复、基数无穷大团队当时觉得没毛病。结果上线后发现每次写入都落在最后一个chunk所在的shard上前面的shard几乎不参与写入只有后台归档查询才会扫到前面的数据。热点全集中在一台机器上写入瓶颈比单机时还难受因为查询还要跨shard汇总。这就是典型的低质量分片键引发的灾难。2.3 三种分片策略怎么选hash、range、zoneMongoDB支持三种分片方式选型逻辑其实不难难的是很多人没想清楚业务到底属于哪种访问模式。Hash分片把分片键做哈希运算再按哈希值均匀切分。它的核心优点就是写入天然均匀适合日志、埋点、订单这类持续高并发写入、没有明显范围扫描需求的场景。缺点是范围查询会被打散到所有shard效率低。Range分片按分片键的数值区间切分。它的优势是范围查询效率高可以把相邻数据尽量落在同一个shard。缺点是写入容易产生热点因为增量数据往往落在区间的一端。Zone/Tag分片可以理解为在hash或range之上再叠加一层“数据位置”约束。你可以通过配置让某些分片键值范围的chunk固定落到指定的shard或机房。常用于多租户隔离、数据合规性存放、本地化读写优先等场景。我自己的默认推荐是物流、订单、日志类直接上hash分片优先保写入和扩容的均匀性。只有明确碰到那种强依赖时间范围扫描、并且可以接受写入热点的场景才用range。至于zone分片等业务体量大到需要做数据本地化和租户隔离了再来研究初期不用给自己加戏。3. 分片集群搭建实操从零到一的全过程记录3.1 版本选择和环境准备关于版本MongoDB从4.2开始config server必须是副本集架构旧版的三个config节点还是主从模式踩过的人应该知道有多痛。我个人建议直接用5.0以上的稳定版本目前7.0.x系列也已经很成熟事务、聚合、change streams都比较稳。至少在4.4以上否则后面排查问题和官方文档对不上会很痛苦。环境规划方面我按一个比较标准的6节点测试环境举例生产环境同理把机器规格提升就好3个config server节点跑在低配机器上2C4G都够内存别给太小因为整个集群的元数据都在这里。2个shard每个shard是1主2从的副本集共6个mongod进程。2个mongos路由节点建议和业务侧LB或应用多地址配置对接不要只暴露一个mongos。网络和磁盘所有节点之间内网互通建议万兆局域网不然chunk迁移和均衡期会拖太久磁盘统一用SSD尤其是chunk迁移期间HDD很容易成为瓶颈。3.2 搭建config server副本集config server本质上也是一个MongoDB副本集启动时设置clusterRole: configsvr。配置如下# /etc/mongod-config.conf sharding: clusterRole: configsvr replication: replSetName: cfgrs net: bindIp: 0.0.0.0 port: 27019 storage: dbPath: /data/configdb三个config节点都启动之后连到任意一个节点执行初始化rs.initiate({ _id: cfgrs, configsvr: true, members: [ { _id: 0, host: 10.0.0.1:27019 }, { _id: 1, host: 10.0.0.2:27019 }, { _id: 2, host: 10.0.0.3:27019 } ] })注意configsvr: true这个字段不能省它标识这个副本集是作为集群配置服务器运行的。初始化完成后通过rs.status()确认三个节点状态是正常的主从关系。3.3 搭建shard副本集每个shard就是一个独立副本集只是启动参数上加了一个clusterRole: shardsvr。下面的配置以shard01为例# /etc/mongod-shard01.conf sharding: clusterRole: shardsvr replication: replSetName: shard01 net: bindIp: 0.0.0.0 port: 27017 storage: dbPath: /data/shard01三个节点都启动后同样做副本集初始化。shard02、shard03以此类推。这个时候还不需要考虑分片先把副本集本身跑通因为后面任何shard出问题最终兜底的都是副本集里的数据冗余和自动切换。3.4 启动mongos并加入shardmongos的路由功能靠的是读取config server的元数据配置很简单# /etc/mongos.conf sharding: configDB: cfgrs/10.0.0.1:27019,10.0.0.2:27019,10.0.0.3:27019 net: bindIp: 0.0.0.0 port: 27017mongos本身不存数据可以横向多开。启动后用mongosh连接任意mongos把shard加进来sh.addShard(shard01/10.0.1.1:27017,10.0.1.2:27017,10.0.1.3:27017) sh.addShard(shard02/10.0.2.1:27017,10.0.2.2:27017,10.0.2.3:27017)加完之后用sh.status()看一下两个shard都显示为正常就说明集群骨架已经搭起来了。3.5 开启数据库和集合分片这一步是关键很多人在这里直接卡住。开启分片要分两步走// 1. 对数据库开启分片 sh.enableSharding(appdb) // 2. 对具体集合开启分片这里以orders表为例用hash分片 sh.shardCollection(appdb.orders, { orderId: hashed })enableSharding只是让这个库里的集合具备被分片的资格真正让数据切分存储的是shardCollection这一句。分片键一旦生成后续不能直接修改字段本身。这也是我前面反复强调分片键一定要一次性选对的原因。分片开启后balancer会根据chunk大小和数量自动把chunk搬到各个shard上。检查一下分布情况db.orders.getShardDistribution()如果两个shard的数据分布接近说明分片配置已经生效。到这里一个最小可用的分片集群就跑起来了。4. 十大生死坑拆解我踩过或者亲眼见别人踩过的全部教训这一章节是全文的精华。这些坑在官方文档里都找不到或者即使找到了也很难意识到它们在生产环境里有多致命。4.1 分片键选错且不可变想悔棋只能推倒重来MongoDB的分片键在shardCollection指定之后字段本身是不可变的。虽然4.x之后引入了refineCollectionShardKey支持通过追加后缀字段来调整分片键但前提是原分片键必须已是索引的前缀且新键必须包含原键本质上是“扩键”而不是“换键”。如果一开始选错了字段唯一的办法是导出所有数据、删除集合、重新建集合开启分片、再导回去。这个过程对于几百G甚至上T的线上表来说基本等于给业务放一个长维护窗口代价极高。我见过一个团队因为分片键选错花了整整一个周末做全量数据迁移中间还因为迁移脚本bug导致数据部分丢失最后靠备份二次恢复。所以选分片键之前务必把业务查询模型和写入模型彻底梳理清楚这条路没有捷径。4.2 分片键基数不够chunk再多也白搭基数是分片键取值空间的绝对大小。有人用布尔值做分片键有人用星期几还有人用省份编码。这些字段的取值空间小到可怜hash之后的可分布状态也极度有限。每次chunk分裂本质上还是在同一个小空间里切切切没有办法让chunk数量超过分片键的基数值。实际操作中我要求分片键的distinct值至少要在几千以上最好是百万级别。如果没有单一字段满足就用组合字段。举个例子物联网设备数据用deviceId timestamp组合做分片键既保证了单个设备的数据连续性又因为设备数量足够多而保证了整体分布均匀。4.3 单调递增字段做range分片写入热点根本跑不掉如果分片键是自增id或时间戳并且用range分片那么新的数据永远只会落在最后一个分片区间写入热点会死死压在一个shard上。这不是MongoDB分片的问题而是业务模型与分片策略不匹配的问题。解决办法有两个一是改用hash分片这是最直接有效的二是如果确实需要range分片的范围扫描优势可以在分片键里加入一个前缀字段比如deviceId timestamp让不同deviceId的写入分散到不同区间。不要天真的以为加自动化均衡就能解决热点写入均衡解决的是已有chunk的分布改变不了新数据写入位置的固有逻辑。4.4 mongos暴露单点和连接管理不当集群再稳也会被客户端击穿mongos是无状态的它可以无限横向扩展。但很多团队在接入层只配置了一个mongos地址mongos一旦CPU打满或重启整个应用层全部断连。正确做法是至少部署两个mongos在应用层连接串里配置多个地址或者通过负载均衡器统一接入。另外一个隐蔽的连接问题MongoDB驱动的连接池是应用侧的。如果应用实例很多每个实例默认的最大连接数又没做限制mongos可能会被连接数拖垮。我处理过一个案例一个分片集群mongos节点莫名其妙CPU飙到100%后来发现是应用端50个实例、每个实例默认200条连接1万条连接全部涌在一个mongos上。后来给每个实例的连接池上限调到50问题立刻消失。4.5 config server没做有效备份元数据一丢集群等于瘫痪config server保存的是整个集群的元数据包括数据库、集合、chunk分布、分片键定义。config server挂了集群的逻辑视图就没了哪怕所有shard里的数据文件还在也没有办法正常路由查询。很多人对config server的认知停留在“它就是个小元数据库”备份意识非常薄弱。我强烈建议对config server做定期mongodump备份并且把备份文件同步到异地存储。恢复流程也得提前演练别等出事的时候再翻文档。真实的教训是某团队误操作把config库里的集合drop了而所有chunk位置信息都在里面最后花了整整三天手工推断chunk边界才把元数据拼回来。4.6 批量导历史数据时没关balancer性能雪崩式下跌一次性往已开分片的集合里灌历史数据是一个非常典型的场景。如果不先关掉balancer数据导入过程中会产生大量chunk分裂、迁移。moveChunk要搬真实数据文件还会占用网络带宽和两边shard的CPU、内存。你会发现导入速度奇慢无比而且正常的业务读写也跟着遭殃。正确做法是导入前执行sh.stopBalancer()等所有数据都灌完了、chunk分布基本稳定了再执行sh.startBalancer()恢复均衡。注意关闭balancer不等于永久关闭集群里要有人记得在导入完成后恢复不然时间长了会出现严重的分布倾斜。4.7 chunk迁移过程里的锁等待和性能毛刺chunk迁移期间源shard会为被迁移的chunk加一个临界区锁critical section确保迁移过程中这个chunk的数据不会被修改。如果业务正在密集写入这个chunk写入操作会被阻塞直到迁移完成。一个大的chunk在慢速网络下可能要迁移几分钟这几分钟里相关文档的写入延迟会明显飙升。避免的办法包括控制chunk大小不要太大默认64MB就可以不必调大把balancer的活跃时间窗口设置到业务低峰期比如凌晨2点到6点监控db.currentOp()里是否有长期pending的moveChunk操作。如果确实遇到迁移卡死可以用sh.stopBalancer()暂停处理完再开。4.8 mongos和shard版本混用兼容性问题排查到怀疑人生生产环境里大家一般会按顺序升级mongos、config、shard但这个过程中很容易出现窗口期线上不同节点版本不统一。如果某个版本之间有已知bug或者驱动版本与数据库版本握手协议不兼容各种奇怪的错误就会出现随机的bulk write超时、连接被重置、命令返回not found之类。最好的做法是升级窗口越短越好最好在低峰期一次完成所有节点升级。应用端的Java/Python等驱动也必须对照官方兼容矩阵选择版本。我之前遇到过一个项目Java驱动一直停在3.x的老版本连MongoDB 5.0的集群握手阶段直接失败报authSourceadmin解析异常折磨了好几天才定位到是驱动太老。4.9 加了新shard后数据不迁移/迁移极慢很多人的预期是“加一个新shard进去balancer会自动把数据匀过去”。实际上balancer的迁移触发条件是chunk数量在shard之间的差值大于迁移阈值比如chunk数量超过80个时阈值为8个。如果整个集群的chunk总数还没超过这个阈值新增的shard很可能会长期处于“半空”状态。遇到这种情况可以强行手动迁移几个chunk过去或者等待数据继续增长、chunk数量突破阈值之后让自动均衡去处理。千万不要为了“快速均衡”把阈值调得非常激进因为并发的moveChunk太多会让集群IO吃不消。数据分布不均还有另一个原因就是最初的预分片没有考虑到后续shard的扩展这种情况只能靠手动搬迁慢慢修正。4.10 查询不带分片键导致广播查询比单机还慢的分布式地狱分片之后如果查询条件里不包含分片键mongos无法确定数据在哪个shard只能把查询广播到所有shard再在mongos上合并结果。这种广播查询在数据量大的时候性能完全取决于最慢的那个shard。举个例子orders表按orderId做hash分片业务方查询时却经常用userId过滤——如果userId不是分片键每次查询就是全分片扫描。这比单机更糟糕因为单机至少没有网络开销和聚合等待。解决方案是认真梳理高频查询把最核心的等值查询条件纳入分片键设计。如果实在做不到就只有额外建立一张按userId分区的新表做数据双写或同步用空间换查询效率。5. 日常运维与问题排查实录5.1 分片集群的监控指标和常用命令集群搭起来之后真正考验团队的是日常运维。我的习惯是每天看一遍sh.status()重点看chunk数量和分布状态然后针对具体的库表用getShardDistribution()确认有没有倾斜。db.adminCommand({listShards: 1})查看所有shard地址和状态sh.status()查看分片集合、chunk分布、balancer状态db.collection.getShardDistribution()查看某个集合在shard上的数据量分布db.currentOp({ command.moveChunk: { $exists: true } })确认是否有chunk迁移在运行sh.getBalancerState()和sh.getBalancerWindow()检查自动均衡的开关和时间窗口磁盘空间这块除了看系统整体的df之外一定要用db.stats()和db.collection.stats()持续跟踪逻辑数据大小。有时候物理磁盘还有空间但某个集合的chunk已经严重压制了单个shard的查询性能这种隐患光靠磁盘监控是发现不了的。5.2 常见故障场景速查表问题现象可能原因建议排查手段某个shard磁盘持续增长其他shard空闲分片键有热点、chunk不均、balancer未开检查getShardDistribution确认分片键是否均匀必要时手动迁移chunkmoveChunk一直pending大流量写入、chunk过大、从节点复制落后查看db.currentOp考虑暂停balancer或提升实例规格查询突然特别慢广播查询、无分片键、排序聚合在mongos合并用explain确认是否带分片键看是否走了单shard路由新增shard后数据长时间不迁移chunk总数未达迁移阈值等待chunk增长或手动迁移部分chunkmongos连接数爆满应用端连接池未限制限制连接池上限横向扩展mongos分片集合写入响应抖动chunk迁移抢占资源调整balancer窗口控制迁移并发集群无法路由查询config server不可用或元数据损坏检查config server状态启动备份恢复流程5.3 分片集群的扩容操作规范和实操心得新增shard的标准流程很简单部署好新的副本集然后sh.addShard()加入集群。但真正的工程难点在于新shard加入之后如何让存量数据平稳迁过去。我的经验是把扩容操作拆成三步来走第一步新shard加入后先跑24小时观察。不要急着迁移看新节点会不会拖累集群整体同时确认新shard副本集自身的健康度。第二步手动迁一批较小的chunk过去验证数据完整性和迁移后的查询响应。最好在业务低峰期操作一次不要迁太多。第三步数据量增加或调整balancer窗口后让自动均衡在低峰期持续工作几天直到chunk分布接近均匀线。如果是从集群里移除一个shard要明确removeShard是一个异步过程。它会先把该shard上的chunk全部迁移到其他shard然后才会真正把shard从集群配置里移除。期间该shard不能直接关停否则迁移会失败。整个过程可能持续很久数据量大时按天计算也正常要提前评估好窗口时间。6. 最后再分享一个小技巧回看这些年处理过的分片故障让我最感慨的不是技术本身而是很多问题明明可以通过前期设计规避最后都变成了火烧眉毛的线上事故。我自己有一次在评估分片键时差点用了纯时间戳做range分片当时觉得日志场景天然适合按时间归档后来画了一张写入热力图才发现日志写入在一天之内是持续产生的但chunk的尾部热点会死死压在最后一个shard上最后硬生生换成了“设备编号hash”的组合方案才逃过一劫。给正在做技术选型或者即将迁移分片集群的同学一个很实用的建议先把业务最近三个月的慢查询日志拉出来统计高频查询的条件字段再结合写入模型确定分片键候选列表。然后模拟灌入一周的真实数据反复验证chunk分布、查询路由和热点情况。不要在测试环境里只跑几条玩具数据就拍板上线分片键这种决定生死的东西值得多花两个星期来验证。如果你已经上线了分片集群建议这周就做一次全面的sh.status()巡检把chunk分布、balancer状态、config server备份都过一遍。分片的坑知道得越早后面越不慌。