使用Java驱动实现MongoDB多集合转单集合零停机迁移的最佳方案

1 第一阶段：数据访问层(DAL)双模式兼容改造 #

用门面模式+策略模式实现双模式兼容，不需要修改上层业务代码，避免业务侵入：

• 先定义统一的MongoDB操作抽象接口，原多集合实现类、新单集合实现类都实现该接口，上层业务仅调用接口方法，完全感知不到底层实现差异
• 新增双写路由实现类，同样实现上述统一接口，内部同时持有旧多集合DAO、新单集合DAO两个实例，执行逻辑如下：
  • 读请求：优先走旧多集合实现返回结果
  • 写请求（增/删/改）：先执行旧多集合操作，操作成功后同步执行新单集合的对应操作，双写都成功才返回成功；如果新集合操作失败，需记录错误日志、上报监控，但不要阻断主流程返回，避免新逻辑异常影响业务
  • 所有写入新单集合的文档自动嵌入collection_id字段，值为原操作的集合名，该逻辑封装在新单集合DAO内部，上层无需感知
• 代码改造完成后在K8s集群灰度发布，先切10%流量到双写版本，观察监控无报错、数据一致性无异常后全量发布所有节点。该阶段所有业务流量仍走旧逻辑，仅同步实时增量数据到新集合，完全不影响业务运行。

2 第二阶段：存量数据离线迁移 #

全量双写稳定运行至少24小时（覆盖完整业务峰值周期）后，启动存量数据迁移：

• 优先使用MongoDB原生工具mongodump+mongorestore配合脚本处理，或写轻量Java批量读取程序实现迁移：
  • 批量读取每个旧集合的存量文档，每批控制在1000~5000条，避免打满MongoDB带宽
  • 为每条文档添加对应collection_id字段后批量写入global_collection
  • 迁移时增加过滤条件，跳过双写阶段已经同步的增量数据（可通过文档创建时间戳、或迁移前记录的每个旧集合最大_id作为分界）
• 迁移过程必须限流，控制迁移工具QPS，避免占用过多数据库资源影响线上业务，同时监控MongoDB的CPU、内存、IO负载，超过阈值立刻暂停迁移
• 全量存量迁移完成后做数据一致性校验：
  • 统计每个旧集合的文档总数，和新集合中对应collection_id的文档总数比对
  • 随机抽取不同旧集合1%的文档，和新集合中对应_id+collection_id的文档做字段级比对，确认无数据丢失、字段内容正确
  • 由于双写逻辑持续运行，增量数据实时同步，只要全量数据校验一致即可确认迁移有效。

3 第三阶段：流量切到单集合模式 #

一致性校验通过后，逐步切读流量到新集合：

• 修改双写路由的读逻辑，先切1%读请求走新单集合实现，观察错误率、延迟指标是否正常，业务侧无报错后逐步提升读流量比例：10%→50%→100%，每一步预留足够的观察时间
• 全量读流量切到新集合后，观察至少一个完整业务峰值周期（通常24小时），确认无任何问题后调整双写逻辑顺序：先写新集合，成功后再写旧集合
• 再稳定运行24小时后，停掉旧集合的写操作，所有读写请求完全走新单集合实现，业务完成新数据模型切换。

4 第四阶段：冗余资源清理 #

• 业务稳定运行一周以上无异常后，删除DAL层的旧多集合实现、双写路由逻辑，仅保留新单集合DAO实现，发布新版本上线
• 确认所有业务不再访问旧集合后，备份旧集合数据，删除所有旧的collection_1、collection_2等集合，释放存储空间。

核心风险控制 #

• 所有变更预设回滚方案，任何阶段出现异常可立刻将流量切回旧多集合模式，不影响业务
• 全程监控核心指标：双写成功率、新集合读写延迟、数据一致性校验结果、MongoDB资源负载
• 存量迁移、流量切流操作优先选择业务低峰期执行，降低潜在风险影响面。

内容的提问来源于stack exchange，提问作者Vajira Prabuddhaka