面向客户服务的事件驱动架构设计与实现方案选型咨询

现有三种方案评估与优化建议 #

方案1：DB事务提交后发送Kafka事件 #

你提到的顺序和一致性问题有成熟的低成本解法：

• 给customer表加version乐观锁字段，每次更新请求都携带当前版本号做校验，只有版本匹配的更新才能执行成功，并发提交的多个修改请求只会有一个生效，不会产生多余事件，自然不存在顺序冲突问题
• 如需保证多笔有效变更的事件顺序，把同一个客户ID的所有事件都投递到Kafka的同一个分区，Kafka同分区天然保证消息顺序，只要你在DB事务提交成功后再发事件，事件顺序必然和DB变更顺序一致
• 避免分布式事务的轻量方案：新增本地事件表，将DB更新和插入事件记录放在同一个本地事务中执行，再单独启动一个后台线程轮询本地事件表发送Kafka消息，发送成功后标记事件为已发送即可，该方案完全解决DB提交成功但Kafka发送失败的一致性问题，远比重型分布式事务更实用。

方案2：CDC捕获DB变更生成事件 #

你顾虑的问题都有成熟的规避方式：

• 业务信息补充：更新DB时可以将事件类型、需要携带的额外业务参数存入customer表的冗余扩展字段，CDC捕获变更时可以直接读取该字段获取完整业务信息，不需要反向推导业务含义
• CDC事件转业务事件的加工逻辑非常轻量，用Kafka Streams或者Flink SQL写简单的映射规则即可完成，维护成本很低，同时整个链路天然保证事件和DB变更100%一致，不会出现漏发、错发事件的问题。

方案3：先发事件再落库 #

该方案确实不适配你当前的用户交互类场景，仅适合非实时交互的后台异步链路，比如批量数据同步、离线报表生成等不需要给用户同步返回结果的场景。 #

推荐成熟替代方案：发件箱模式（Outbox Pattern） #

这是目前行业内解决这类DB与事件一致性问题的主流方案，刚好适配你的PoC需求：

• 业务服务处理用户请求时，将业务数据更新和事件数据写入同库的outbox发件箱表，两个操作放在同一个本地事务中提交，保证要么同时成功要么同时失败
• 事件发布组件可以选择用Debezium直接捕获outbox表的CDC变更投递到Kafka，也可以用轻量的定时轮询服务读取outbox表的未发送事件投递，投递成功后标记事件为已发送即可
• 下游邮件服务直接监听CustomerLoggedIn、CustomerChangeName两类业务事件执行邮件发送逻辑即可

该方案完全规避了你提到的三个方案的所有缺陷：保证DB变更和事件的强一致性、事件顺序与DB变更顺序完全一致、可以直接在写outbox表时填充所有需要的业务信息、用户请求可以同步返回更新成功，因为业务数据已经在DB中提交完成。 #

不同方案适用场景 #

• 方案1（DB提交后直接发Kafka+乐观锁）：适合业务规模小、事件可靠性要求不高、并发量低的场景，实现最简单，不需要引入额外组件
• 方案2（CDC捕获转业务事件）：适合有大量DB操作需要转换为业务事件、经常有直接操作DB的运维需求、要求事件与DB变更绝对一致的场景，更适合中大规模团队使用
• 方案3（事件驱动最终一致性）：适合非用户交互的后台链路、可以接受秒级到分钟级最终一致性延迟的场景
• 发件箱模式：适合绝大多数业务场景，兼顾一致性、可靠性、易用性，大中小规模项目都适用，是当前的主流选型

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