做数据库这块时间长了被问得最多的问题之一就是MongoDB到底该用复制集还是分片集群很多刚接触的人觉得这俩是对立关系要么全上分片要么只搭复制集。实际上生产环境最稳的方案往往是“混合”在同一个业务系统里一部分数据跑独立复制集一部分数据跑分片集群甚至在分片集群内部每个分片本身就是复制集。这篇文章就从我实际维护过的架构出发把这种混合部署策略的设计思路、实操步骤和踩坑经验完整讲一遍。1. 为什么需要混合部署两种架构的定位差异1.1 复制集解决的是高可用不是容量上限一个标准的复制集由Primary、Secondary和灵活的投票节点组成核心能力是自动故障转移和读写分离。它给你的是“数据不丢、服务不断”的保证但容量上限依然受限于单台服务器。我见过不少团队上来就搭了一个复制集觉得三副本够了结果业务跑了大半年单节点磁盘快写满了才意识到复制集没法横向扩容。增加节点并不能分担Primary的读写压力Secondary再多写请求还是落在Primary上读压力可以通过readPreference分担一部分但写瓶颈和容量瓶颈始终存在。复制集适合的是数据量可控、增长曲线平稳、对一致性要求高的核心业务。比如用户基础信息、账户配置、订单状态表这类数据单节点几百GB以内都问题不大。1.2 分片集群解决的是容量和吞吐的横向扩展分片集群的本质是把数据按分片键拆成多个chunk分布到不同shard上。每个shard再各自承担一部分读写压力从架构层面解决了单机瓶颈。但分片集群带来的是运维复杂度的指数级上升多了mongos路由层、配置服务器需要管理chunk分裂、均衡器迁移还要精心选择分片键否则热点问题比容量问题更让你头疼。分片集群适合的是海量日志、行为轨迹、IoT设备上报、高并发写入的大数据量场景单节点装不下、单实例扛不住的那种。比如某块业务一天新增几十亿条记录一年下来几个TB这种数据塞进复制集就是自己给自己挖坑。1.3 混合部署的核心思路按数据的“性格”分而治之我维护的一个模拟项目中业务类型是电商加用户行为分析。订单、账户这类数据量不大但极其重要每天增长稳定用户点击、页面浏览这类行为数据量大、增长快、时效性强需要长期存储做分析。如果全部塞进分片集群订单表的查询和写事务会被mongos路由多一跳增加了不必要的延迟如果全部放进复制集行为数据一年后就会把磁盘撑爆。所以最终的架构是订单、账户等核心业务数据放进一套三节点的独立复制集行为数据放进一套两个shard的分片集群每个shard又是一个三节点复制集。应用层通过两条不同的MongoDB连接串访问不同数据源。这样的组合既保证了核心业务的高可用和低延迟又给了海量数据足够的扩展空间。2. 混合部署架构的整体设计规划2.1 分片集群内部的“复制集套娃”结构先说一个很容易被忽略的事实分片集群的每个shard本身必须是一个复制集。哪怕这个shard只有一个节点它也是一个单节点的复制集这样后续才能在不影响现有数据的情况下给某个shard扩容副本。config server从3.4版本开始也必须使用复制集模式。所以你会看到一套完整的分片集群里实际上是三套复制集在协同工作shard1复制集、shard2复制集、config复制集加上多个无状态的mongos路由进程。这样的嵌套结构不是随便定的每个组件都有明确的角色。shard复制集负责实际数据的存储和承担读写config复制集负责元数据记录每个chunk落在哪个shard上一旦config挂了整个集群的路由信息就丢了所有mongos都会失联mongos只是个“路由器”不存数据启动时从config加载路由表然后转发客户端请求到对应的shard。2.2 业务数据分流哪些进复制集哪些进分片集群分流的判断标准我总结成四条第一条是数据量。量级在百GB级别以内增长幅度每年不超过现有容量的50%优先复制集量级是TB级别或增长不可预测必须分片。第二条是访问模式。需要频繁点查、精准更新的核心业务走复制集少一跳路由延迟以写入为主、写入量巨大、偶尔做范围查询分析的数据走分片集群。第三条是生命周期。短期保存、随时可以清理的数据复制集就能解决需要长期留存、且随业务增长越来越多到无法预判的数据分片集群更稳妥。第四条是一致性要求。绝大多数业务场景下MongoDB复制集已经能通过writeConcern保证较强的一致性但分片集群在跨分片事务上的开销和复杂度明显更高。如果系统涉及大量多文档事务尽量避免分片到这个集合上。2.3 硬件资源规划不要平均分配我见过最典型的错误就是给复制集和分片集群用一模一样的服务器配置。实际上行为数据分片集群的shard节点需要大磁盘、多内存订单核心复制集需要的是高CPU主频和更稳定的本地盘。我在那个模拟项目里订单复制集用的是4核16G内存加500G SSD分片集群的shard节点用的是8核32G内存加2T SSDconfig节点反而配了比较低的配置因为它只存元数据负载很小。mongos则是两台2核4G的轻量云主机无状态挂在负载均衡后面。容量估算有个简单的经验公式业务日增数据量乘以保留天数乘1.5。其中0.5是留给索引、碎片和未来一周的缓冲。SQL类数据库的经验值在30%到50%之间MongoDB因为有文档填充因子和均衡迁移的冗余1.5倍算是偏保守的算法。如果是分片集群每个shard的空间分配还要额外留出10%到20%的空余均衡器在做chunk迁移时需要有“落脚点”磁盘满了再想迁移就有窒息风险。3. 核心配置与实操步骤3.1 环境规划与版本选择我选择MongoDB 6.0版本在写这篇文章时它已经相当稳定。5.0版本刚出时我踩过不少坑6.0的稳定性好很多。规划时确定好三套数据目录独立复制集一套分片集群的shard1和shard2各一套config复制集一套。每套复制集默认对应不同的端口避免部署在同一台机器上时端口冲突。独立复制集 rs_core: 三节点, 端口 27017/27027/27037 Shard1 复制集 rs_shard1: 三节点, 端口 27101/27102/27103 Shard2 复制集 rs_shard2: 三节点, 端口 27111/27112/27113 Config 复制集 rs_config: 三节点, 端口 27201/27202/27203 mongos 路由节点: 双节点, 端口 27301/27302目录规划也建议统一比如/data/mongodb/data、/data/mongodb/log、/data/mongodb/conf分开把配置文件和日志集中管理后面排查问题时会省很多事。3.2 搭建第一个复制集先初始化核心业务复制集rs_core。每个节点上mongod配置文件的区别主要在role参数和host地址上。# 复制集节点通用配置 storage: dbPath: /data/mongodb/data journal: enabled: true systemLog: destination: file path: /data/mongodb/log/mongod.log logAppend: true net: bindIp: 0.0.0.0 port: 27017 replication: replSetName: rs_core processManagement: fork: true三个节点都启动后在任意一个节点上执行初始化命令。rs.initiate({ _id: rs_core, members: [ { _id: 0, host: node1:27017 }, { _id: 1, host: node2:27027 }, { _id: 2, host: node3:27037 } ] })这里有个细节members数组里尽量避免以IP形式硬编码建议用内网域名或者稳固的内网IP。后续扩缩容换机器时只需改配置而不影响客户端连接串。执行rs.status()看到stateStr全部为PRIMARY或SECONDARY就说明复制集就绪了。3.3 初始化分片集群的底层复制集分片集群的shard复制集和独立复制集的搭建几乎一样区别只在启动参数里加一个--shardsvr。配置文件中增加对应字段# shard1节点配置 sharding: clusterRole: shardsvr三个shard节点全部启动后同样依次初始化shard1和shard2复制集。注意shard复制集的节点不需要priority设置因为后期如果某个shard的某个节点挂掉触发的是整个shard复制集的主从切换并不影响全局路由。config server复制集的搭建稍有不同配置文件里需要指定clusterRole为configsvr# config节点配置 sharding: clusterRole: configsvr并在启动前就预先规划好三个config节点。config复制集是分片集群的“大脑”它的可用性决定了整个集群的稳定性。我给的端口是27201到27203虽然是三个小节点但保证不在同一物理机上最好分布在不同的机架。3.4 启动mongos并完成分片集群组装mongos不是mongod它不存数据启动命令和配置也略有区别。每个mongos节点只需要一份配置指向config server复制集# mongos配置 sharding: configDB: rs_config/node1:27201,node2:27202,node3:27203 net: bindIp: 0.0.0.0 port: 27301这里最容易踩坑的是configDB格式必须写“复制集名称/节点列表”不是简单的IP列表。复制集名称错了、节点列表里端口错了mongos都会直接拒绝启动。启动mongos后需要通过它连接集群并添加shardmongosh --host localhost --port 27301 sh.addShard(rs_shard1/node1:27101,node2:27102,node3:27103) sh.addShard(rs_shard2/node1:27111,node2:27112,node3:27113)执行完sh.status()可以看到shards列表里出现两个shard每个shard显示对应的复制集状态。到了这一步一套完整的分片集群已经可以对外提供路由访问了。3.5 配置分片键与启用数据库分片分片集群不是建好就自动分片必须先创建集合、建立分片键索引、执行分片命令。这一步有很多人漏掉结果数据全部写进主shard其他shard始终是空的。// 启用数据库分片 sh.enableSharding(behavior_db) // 切换到目标数据库 use behavior_db // 创建哈希分片键索引 db.user_actions.createIndex({ user_id: hashed }) // 执行分片集合 sh.shardCollection(behavior_db.user_actions, { user_id: hashed })分片键选型是接下来影响整个集群性能的关键决策。用户行为数据最典型的分片键是user_id读写都按用户维度分散。而像时间戳这种单调递增字段如果直接作为分片键会导致所有新数据都落到同一个chunk里产生热点分片。哈希分片能打散写入热点但对范围查询不友好。在代码里需要对shard内部的复制集和独立复制集做区分分片键选型时尤其要注意业务读写模式不能为了“平均分布”牺牲掉点查效率。3.6 应用层连接双数据源混合部署在应用层体现为一个服务连接两个MongoDB地址。以Node.js为例const coreMongo new MongoClient(mongodb://node1:27017,node2:27027,node3:27037/?replicaSetrs_corewmajority) const behaviorMongo new MongoClient(mongodb://mongos1:27301,mongos2:27302/?wmajority) // 核心业务请求走复制集 await coreMongo.db(core_db).collection(orders).insertOne(orderDoc) // 行为数据写分片集群 await behaviorMongo.db(behavior_db).collection(user_actions).insertOne(actionDoc)特别注意复制集连接串一定要带上replicaSet参数否则mongod会认为你只想连单节点不会自动发现其他节点也无法正确触发读偏好和故障转移。mongos连接串不需要指定副本集因为mongos本质上还是无状态路由不参与复制。4. 数据的生产流转、切换与扩容4.1 复制集的主从切换细节核心复制集出现Primary宕机时其余节点会自动发起选举。投票节点通常设置为3个两个节点即可达成多数。这时客户端现有连接的writeConcern为majority的写操作会等待新Primary确认体验上的表现是“写请求卡了一会儿”但不会报错。因此应用层必须设置合理的写入超时时间比如5到10秒不要给一个无限长的等待。数据库连接串的URI里如果写了多个host驱动会自动发现新Primary但TCP连接本身存在超时所以应用层最好再加一层重试逻辑。这个细节在故障演练时表现得很明显没有重试机制的客户端在切换瞬间会出现大量连接错误日志。分片集群中某个shard复制集发生主从切换时mongos会感知到shard内部的新Primary应用层无需感知但这段时间该shard上的读写会暂时失败或超时。所以mongos前面的业务代码最好也有一层基础重试我习惯把MongoClient的操作封装一个简单retry函数遇到MongoServerSelectionError或NotWritablePrimary错误时自动重试三次。4.2 chunk分裂与平衡器的工作机制分片集群里每个chunk默认64MB数据增长后chunk自动分裂。分裂是逻辑上的数据不真正移动只有balance均衡器才会把chunk从数据量大的shard搬到数据量少的shard上。均衡器的迁移过程会占用磁盘IO和网络带宽这属于集群的正常碾压式震荡。刚开始分片时我建议先关闭均衡器等业务低峰期再开启避免刚上线就被迁移任务拖垮。// 关闭均衡器窗口 sh.setBalancerState(false) // 在业务低峰期打开 sh.setBalancerState(true)更精细的方式是设置均衡窗口让chunk迁移只在一天内某个时段进行db.settings.updateOne( { _id: balancer }, { $set: { activeWindow: { start: 02:00, end: 06:00 } } }, { upsert: true } )高频写入时如果开启了均衡很可能出现chunk裂变跟不上写入速度导致单shard热度过高。遇到这种情况处理顺序是先关均衡器再检查chunk大小和分片键热点分布排查完再开均衡。4.3 混合架构下的扩容与降级策略独立复制集要扩容时新增节点直接加到rs_core复制集里等待同步旧数据同步完成后自动变成SECONDARY不需要停服务。分片集群扩容则是新建一个shard复制集然后执行sh.addShard均衡器会自动把部分chunk迁过去。整个过程业务无感知但注意不要在业务高峰期操作迁移带宽会挤占业务流量。混合架构里最有意思的一点是如果分片集群某天压力不大可以将部分行为数据按时间维度做归档清理比如3个月前的历史数据导出到冷存储再删除分片集群上的原始数据从而释放shard空间。复制集的核心数据则不能随便清理因为订单、账户随时都会被查询。这种“冷热分层”操作让分片集群的存在意义更加灵活不需要一味为了容量而扩容。5. 常见问题与排查技巧实录5.1 分片之后数据分布不均衡症状sh.status()显示某个shard的chunk数量明显偏多哪怕hash分片也分布不均。排查方向是先看分片键的哈希值是否均匀。如果分片键某个值占比奇高即使哈希那个值的数据也会均匀拆到多个chunk但查询时都归到同一批chunk里也还是热点。还有一个常见坑是集合在启用分片之前已经有大量数据启用分片后所有数据先落到主shard然后靠balancer慢慢迁。此时最好的做法是预分片按分片键提前创建空chunk并调整chunk大小到16MB或32MB让写入一开始就有足够的分布空间sh.enableSharding(behavior_db) db.user_actions.createIndex({ user_id: hashed }) for (let i 0; i 100; i) { sh.splitAt(behavior_db.user_actions, { user_id: NumberLong(i) * 100000 }) }5.2 复制集节点长时间无法赶上同步症状rs.status()中某个SECONDARY的state为RECOVERINGoptimeDate和主节点差距越来越大。最常见原因是oplog大小不够写入量大时Secondary来不及清空旧oplog。oplog默认容量在64位Linux上是磁盘剩余空间的5%但高写入业务下根本不够。我在shard节点上会显式把oplog设到10GB到20GB。replication: replSetName: rs_shard1 oplogSizeMB: 20480设置oplog需要在mongod启动前修改配置文件并重启运行中无法调整。所以规划存储空间时一定要给oplog单独预留空间。5.3 mongos路由性能瓶颈的隐性问题mongos本身无状态可以横向扩展。但客户端如果只连接一个mongos等于把所有路由压力集中到单点上。我碰到过一次mongos所在机器内存被挤爆导致所有分片查询卡顿的情况。解决办法就是部署至少两台mongos前端用负载均衡或驱动层的multiple seeds连接。mongos诚实说是一个比较轻量的模块但并发上万时CPU和内存同样会吃紧。5.4 从“读写偏好”排查慢查询应用层配置readPreference为secondaryPreferred时复制集的大部分读会走Secondary这能有效分担Primary压力但Secondary的数据有一定延迟。某个业务偶发读不到刚写入的数据排查一圈发现代码里用了女巫式“只读从库”的配置但业务没有接受延迟。我的处理是把这类严格要求实时一致性的操作强制指定readPreference为primary。分片集群的慢查询排查则要看执行计划是否命中分片键。通过explain查看查询是否走mongos的某个shard如果查询条件不包含分片键mongos会广播到所有shard造成全分片扫描。这类查询在数据量变大后性能会急剧劣化最有效的思路是尽可能把分片键作为查询的第一过滤条件。6. 运维监控与备份恢复的组合拳6.1 关键监控指标复制集核心指标包括主从延迟、心跳状态、选举次数。分片集群核心指标包括chunk分布数量、均衡器状态、mongos路由延迟。统一的监控表格里我至少会盯这几项监控项采集方式阈值参考含义主从延迟rs.status()单秒内延迟 2s同步健康度当前主节点rs.isMaster()有主节点复制集可用性chunk分布sh.status()各shard差距 20%数据倾斜balancer状态db.settings非持续开启避免迁移占用oplog剩余时间replSetGetStatus至少能容纳24h写入防止同步追不上mongos连接数db.serverStatus().connections稳定或可控增长连接泄漏信号mongostat、mongotop这类工具适合临时爆发问题诊断长期监控我更倾向用Prometheus加mongo_exporter方式配AlertManager做告警。6.2 备份策略复制集和分片集群差异很大复制集备份最简单可用mongodump加oplog方式导出前提是要在Secondary节点上执行避免影响Primary的写入。更推荐直接对文件系统做快照配合固定时间点的oplog回放恢复速度最快。分片集群备份则要麻烦得多。如果直接用mongodump导出整个集群因为数据跨shard分布导出结果可能不一致。标准做法是在config server上关闭balancer确保没有chunk迁移然后对每个shard的mongod执行mongodump最后再对config复制集执行mongodump。恢复时按顺序恢复shard和config最后启动mongos并重新导入分片元数据。这个顺序出错会导致恢复出来的集群路由和实际存储严重不一致。我踩过一次坑恢复时漏了config server的dump结果启了mongos后连接正常但读不到任何数据排查了半天才发现元数据丢了。6.3 上线后必做的几次小实验新环境搭建完成后我会花半小时做三个小实验成本很低但非常值先做一次故障注入杀掉核心复制集的Primary观察应用是否在10秒内恢复写入如果超过30秒还没恢复多半是驱动重试参数配得不对。然后做一次分片数据迁移手动把其中一个chunk从一个shard管理到另一个shard观察终端业务是否报错。这能验证均衡器配置和mongos路由的稳定性。最后做一次备份恢复演练把分片集群dump出来的数据恢复到一套临时环境中确认能正常查询。备份“能导出”和“能恢复”是两回事不恢复一次等于没备份。个人实际操作中的体会混合部署不是一开始就规划的往往是业务演进过程中被逼出来的。我最初只搭了一个复制集行为数据暴涨后不得不临时加了一组分片集群。由于最早没做好数据分流设计中间迁移老数据花了近一个月。后来复盘总结出这套“按数据性格分而治之”的思路再遇到新业务时就可以先画数据分类表再定部署形态。如果你当前也正面临“复制集还是分片集群”的选择我的建议是先看数据量级和增长趋势不看别的。数据量可控就用复制集具备不确定性就早点规划分片键。如果已经运行了复制集且数据快吃紧也不一定要推倒重来把增长最快的数据拆到新建分片集群里老数据留在复制集归档就是最常见的混合部署演进路径。混着搭保持核心链路简单把复杂度留给真正需要扩展的数据是这套架构最有价值的地方。