MongoDB与DynamoDB双向实时复制方案选型咨询

我们需要同时使用两套独立数据库：前端团队基于MongoDB Atlas开展业务开发，AWS云架构团队侧统一使用DynamoDB。

既定架构要求 #

• Web应用侧所有数据插入、更新、查询操作走MongoDB执行
• MongoDB与DynamoDB需保持实时数据同步
• 后台AWS服务所有数据插入、更新、查询操作走DynamoDB执行
• 两个数据库任意一端产生数据变更，都需要双向同步到对端

已验证过的路径 #

• 初版方案通过DynamoDB Streams、MongoDB Atlas Trigger分别监听两侧数据库的变更事件，借助Lambda做变更转发，但当前复制逻辑健壮性不足，生产环境风险高
• 曾评估用支持持续复制的AWS Database Migration Service做同步，暂未完成业务场景适配，暂时作为备选方向
• 已调研过CData Sync这类第三方同步服务，暂未落地

核心诉求 #

优先选择AWS原生解决方案，若没有适配度足够的原生方案，可靠的第三方服务也可纳入选型范围，需要可落地的实现思路参考。

AWS原生方案（优先推荐） #

方案1：优化现有Streams+Trigger+Lambda链路 #

你之前搭的基础链路逻辑完全可行，健壮性不足基本都是缺失了三个核心机制，补全后完全可以满足生产级要求，整体改造成本远低于适配其他新服务：

• 循环同步阻断：给所有同步链路写入的记录统一加元数据标记字段，比如sync_source，写入时标记来源是mongo还是dynamo，两侧的变更监听规则直接过滤掉带该标记的变更事件，从根源避免无限循环触发
• 幂等写入保障：两侧数据表统一配置业务主键+版本号/更新时间戳字段，Lambda处理变更事件时，先查询目标库对应记录的版本，仅当待同步记录版本更新时才执行写入操作，避免旧数据反向覆盖新数据
• 异常兜底机制：Lambda处理失败的事件不要直接丢弃，统一投递到专用死信队列，配置独立的定时任务做补偿重试，同时给死信队列配置告警规则，同步异常出现时第一时间感知处理
• 预定义冲突规则：提前明确数据冲突的解决逻辑，比如默认按最新更新时间戳生效、或者按业务侧优先级判定（比如前端写入的Mongo数据优先级高于后台DynamoDB同字段更新），避免出现数据不一致后无规则可依

如果不想自己维护大量Lambda逻辑，可以直接用EventBridge Pipes托管连接器搭建同步链路，服务内置了事件过滤、字段转换、死信队列配置能力，比自定义Lambda的运维成本低很多，属于全托管AWS原生服务。

方案2：AWS DMS适配优化 #

如果你的数据结构没有过于复杂的嵌套、不需要做大量自定义字段转换，DMS是可以支持MongoDB和DynamoDB的双向持续同步的。适配时注意几个核心配置：开启双向同步参数、在源端配置事件过滤规则排除同步链路写入的记录避免循环、提前配置好字段类型映射规则。正式上线前先拿测试表跑满24小时全场景压测，覆盖单条增删改、批量写入、字段删除、大字段更新等场景，验证数据一致性后再推生产。

第三方服务备选 #

如果团队没有多余人力维护自定义同步链路，可以选择经过AWS认证的商业化第三方数据同步服务，这类服务一般已经内置了循环阻断、幂等写入、冲突处理、监控告警全链路能力，只需要配置两侧数据库的访问权限、选择需要同步的表/集合、配置同步规则即可直接使用，适合运维人力不足的团队。

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