RDS MySQL Aurora行变更待事务提交后触发AppSync Mutation方案咨询

方案一：基于CDC（变更数据捕获）的Binlog监听方案 #

• 核心逻辑：MySQL Binlog仅会在事务成功提交后写入，基于Binlog的变更事件触发逻辑完全规避了事务未提交就推送的问题
• 实现步骤：
  1. 开启Aurora MySQL的Binlog功能，将binlog_format参数设置为ROW模式，确保可以获取每行变更的完整新旧值
  2. 选用AWS DMS（数据库迁移服务）作为Binlog消费组件，设置源端为你的Aurora实例，目标端为AWS Lambda，DMS会自动捕获已提交的行变更事件并推送给Lambda
  3. 在Lambda中解析变更数据，调用AppSync GraphQL Mutation即可，此时获取到的所有变更都是已经完成事务提交的有效数据，不会出现事务回滚导致的状态不一致
• 优势：完全无侵入业务代码，无需修改原有数据库触发器或业务逻辑，依托AWS托管组件无需自行维护Binlog消费的高可用性

方案二：业务层事件表异步解耦方案 #

如果不想引入CDC相关组件，可以通过轻量的业务改造实现：

• 核心逻辑：将触发器直接调用推送的逻辑替换为同事务内事件落库+异步校验推送的逻辑
• 实现步骤：
  1. 原有AFTER INSERT/AFTER UPDATE触发器不再直接调用Lambda触发AppSync，改为向同库的pending_events表插入待推送事件，携带变更行主键、变更类型等信息，该插入操作和原业务操作处于同一个事务中，若事务回滚，事件记录也会同步回滚
  2. 部署定时触发的Lambda（触发频率可根据延迟要求设置为1-5秒），每次执行时查询pending_events表中未处理的事件，先对目标事件加行锁标记为处理中，再读取变更行的最新数据调用AppSync Mutation，调用成功后删除pending_events中的对应记录
  3. 补充异常重试逻辑：若调用AppSync失败，保留事件记录供下次重试，可搭配死信队列处理多次推送失败的异常事件
• 优势：无需开启Binlog，无需引入额外AWS服务，实现成本低，逻辑可控性高

方案三：Aurora原生EventBridge集成方案 #

• 核心逻辑：新版Aurora MySQL支持原生事件推送功能，事务提交后会自动将行变更事件推送到Amazon EventBridge，无需自行维护监听逻辑
• 实现步骤：
  1. 在Aurora集群参数组中开启event_notification功能，配置需要监听的库、表以及变更类型（INSERT/UPDATE等）
  2. 在EventBridge中配置事件规则，匹配Aurora推送的变更事件，将目标设置为触发Lambda
  3. Lambda层解析事件数据，调用AppSync Mutation即可
• 优势：全托管服务，配置简单，无需额外开发监听逻辑，事件推送延迟低

注意：三种方案都建议给Lambda添加幂等处理逻辑，由于Binlog、事件推送都可能存在重复投递的情况，可使用「变更行主键+事务ID/变更时间戳」作为幂等键，避免重复调用AppSync Mutation导致的数据异常。

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