不借助消息中间件，基于内存消息总线实现最终一致性的方案探讨

针对采用内存消息总线（中介者模式）的模块化单体应用，在不使用事件溯源的前提下，以下几种可落地的简便最终一致性保障思路：

1. 本地事务性发件箱+内存投递重试 #

• 核心逻辑：将领域事件与业务操作绑定到同一个本地数据库事务中，事件先写入数据库的event_outbox表（字段包含事件内容、状态、重试次数、创建时间），事务提交后再触发投递。
• 投递机制：启动后台线程（或定时任务）扫描event_outbox中状态为待投递的事件，将其发送到内存消息总线。若投递失败（如目标模块临时不可用），更新事件状态为投递失败并递增重试次数，按指数退避策略重试；达到最大重试次数后标记为死信，等待人工介入。
• 优势：复用本地事务保证事件与业务操作的原子性，实现“至少一次”投递，复杂度远低于分布式发件箱。

2. 轻量进程内2PC协议 #

• 核心逻辑：利用进程内模块通信的低延迟特性，简化分布式2PC流程：
  1. 主模块执行业务操作的预提交（如数据库中标记数据为待确认状态）；
  2. 向所有依赖模块发送事件，等待各模块返回处理完成并持久化成功的确认信号；
  3. 若所有模块确认成功，主模块提交最终事务（将预提交数据改为已确认）；若任一模块失败或超时，触发全局回滚（主模块回滚预提交，通知各模块撤销已执行操作）。
• 注意：仅适合模块数量较少的场景，避免因模块过多导致的超时或协调成本上升。

3. 进程内TCC（补偿事务） #

• 核心逻辑：将每个模块的业务操作拆分为三个阶段：
  • Try：预留资源（如冻结订单库存），不执行最终状态变更；
  • Confirm：确认执行操作（扣减冻结的库存），仅在所有模块Try成功后触发；
  • Cancel：释放预留资源（解冻库存），若任一模块Try失败则触发。
• 实现细节：在进程内维护全局状态跟踪器，记录各模块的阶段执行结果；Confirm/Cancel操作需实现幂等性，避免重复执行导致数据异常；若Confirm/Cancel失败，持续重试直到成功或进入死信处理。

4. 事务绑定的内存事件队列 #

• 核心逻辑：通过AOP或事务拦截器，为每个数据库事务绑定一个内存事件队列。业务执行过程中产生的领域事件先加入该队列，仅当事务提交成功后，才将队列中的事件批量发送到内存消息总线；若事务回滚，队列直接清空。
• 容错处理：若事件发送到总线后目标模块处理失败，可将失败事件写入本地数据库的重试表，后续由后台任务重新投递；同时要求模块的事件处理逻辑实现幂等性，避免重复处理导致数据不一致。

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