多实例Spring Boot集成Embedded Debezium处理MongoDB重复DB事件

嵌入式Debezium启动时会在当前进程内独立运行MongoDB连接器，默认各实例单独维护消费位点、独立拉取MongoDB oplog，实例之间没有任何协调机制，因此多实例部署时每个实例都会拉取到全量变更事件，必然出现重复消费。

方案1：单实例消费+故障自动切换（改造成本最低，适配大多数中小流量场景） #

• 替换默认的本地文件offset存储为共享存储：将Debezium嵌入式引擎的offset.storage配置从默认的本地文件存储，改为现有技术栈里的高可用共享存储，可选实现包括Redis、MongoDB、关系型数据库，保证所有实例读取同一份消费位点，不会出现位点不一致导致的重复消费/丢数问题。
• 增加分布式锁抢占逻辑：服务启动时先通过分布式锁（可选Redis SETNX、ZooKeeper临时节点、MongoDB唯一索引、Spring分布式锁等任意已在使用的实现）抢占Debezium引擎的运行锁，只有抢到锁的实例才初始化并启动Debezium嵌入式引擎，未抢到锁的实例持续监听锁状态。
• 增加锁续期与故障转移：持锁实例需要定期给锁续期，若实例宕机导致锁过期释放，其余存活实例自动抢占锁，抢到锁的实例基于共享存储里的offset继续消费，保证服务高可用。

该方案全程不需要额外引入新的中间件，始终只有一个实例实际消费变更事件，从消费源头避免重复，适配90%以上嵌入式Debezium的使用场景。

方案2：多实例消费+MQ分发（适合大流量需要水平扩展消费能力的场景） #

如果单实例消费的性能满足不了业务流量，需要多实例并行消费，可以在现有架构基础上增加一层消息队列做分发：

• 所有Debezium实例保持现有逻辑正常拉取事件，拿到事件后根据事件的resumeToken + 集合命名空间 + 文档ID生成全局唯一ID，将事件投递到MQ的同一个Topic中。
• 业务处理逻辑作为MQ消费组的消费者订阅该Topic，利用MQ原生的消费组集群消费能力，保证同一条事件只会被投递到消费组内的一个实例处理。
• MQ侧开启消息幂等去重，避免多个Debezium实例投递同一条事件导致的消息重复。

方案3：业务幂等兜底（必加，所有方案都需要配套） #

分布式场景下不存在绝对的“恰好一次”语义，无论用上述哪种方案，都必须在业务处理层增加幂等校验：

• 每次处理事件前，先拿事件的全局唯一ID查询存储（Redis/业务库均可）中是否存在已处理标记，若存在直接跳过本次事件。
• 事件处理完成后，再写入已处理标记，标记保留时长设置为大于MongoDB oplog的保留周期即可（通常设置7天足够覆盖绝大多数场景）。

• 不要尝试自行拆分MongoDB oplog做分片消费，MongoDB oplog是全局严格有序的，硬拆分极易出现事件乱序、丢数问题，排查成本极高。
• 分布式锁必须配置合理的过期时间与自动续期逻辑，避免持锁实例正常运行时锁意外释放，导致多实例同时消费。
• 共享offset存储与分布式锁尽量使用同一个高可用组件，避免多组件状态不一致引发的消费异常。

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