Java中实现MongoDB集合跨环境周度复制的最佳方案是什么

方案适配性说明 #

Change Streams 本身是实时增量变更监听组件，不是专门为周度批量同步设计的，但配合周期全量快照做组合方案，比每次周度同步全量拷贝集合的性能开销低70%以上，适合作为长期稳定的同步方案。
如果你的需求只是每周一次性导一次数据、没有持续同步增量的要求，直接用mongodump/mongorestore加时间范围查询是成本最低的选择，没必要上Change Streams。

具体实现步骤 #

• 第一步：生成同步基线
  首次部署、以及后续每次resumeToken失效兜底时，对源集合做一致性快照导出导入到目标端。导出时必须使用snapshot读关注，导出完成后立刻记录当前游标对应的resumeToken，作为后续增量同步的唯一起点，不要用系统时间戳当起点，会出现数据丢失或者重复。
  记录resumeToken不需要额外执行命令，快照查询的游标执行完后直接调用getResumeToken()方法就能拿到。
• 第二步：常驻增量监听
  部署一个常驻的监听进程，从上次记录的resumeToken开始开启Change Stream，配置参数必须加fullDocument: "updateLookup"，否则update事件只会返回变更的字段，拿不到完整文档内容，会导致目标端数据缺字段。
  监听时过滤掉非业务操作事件，只保留insert/update/replace/delete四类文档级变更，把拿到的变更事件持久化存储（可以存在目标MongoDB的临时集合，不要存在进程内存里，进程重启会丢数据），不要直接实时写入目标集合——周度同步的核心要求是目标环境保留固定周期的稳定数据版本，实时写入会导致目标端数据持续变动，无法满足测试、对账类场景要求。
• 第三步：周度同步窗口执行
  到每周预设的同步时间点，先暂停新变更的入队操作，把持久化队列里截止到当前时间点的所有变更，按事件发生顺序在目标端逐次回放。回放完成后做一致性校验：对比两边集合的文档总数、索引数量、随机抽取1%~5%的文档做字段hash校验，确认数据一致后，记录当前最新的resumeToken作为下一个周期的同步起点，再恢复增量监听即可。
  如果你们需要留存每周的历史版本数据，可以在回放完成后直接给目标集合打一个快照，不用每次重新导全量。
• 第四步：异常兜底
  每次启动监听前先校验resumeToken的有效性，如果遇到源端oplog被覆盖、token失效的报错，直接触发一次全量基线同步，重新生成新的resumeToken即可，不要无限重试无效token导致同步链路卡住。

常见踩坑规避 #

• 不要每周重新开Change Stream追过去7天的变更：MongoDB默认oplog保留窗口不是固定7天，业务写入高峰时oplog可能几小时就被覆盖，大概率会报InvalidResumeToken错误，最后还是要跑全量，浪费资源。
• 不要漏处理delete事件：很多人同步时只配置监听insert、update事件，漏掉删除操作，最后两端文档数长期不一致，排查成本极高。
• 不要在回放变更时乱序执行：Change Stream返回的事件是严格按源端操作顺序排列的，乱序回放会导致数据覆盖错误，比如先执行后提交的update、再执行先提交的delete，最后目标端会残留已经被删掉的脏数据。

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