分布式事务
在微服务架构中，一个业务操作往往涉及多个服务、多个数据库的协同工作。典型的场景如：创建订单时需要同步扣减库存、生成发运单等。由于这些操作分布在不同的服务中，各自拥有独立的数据源，传统的本地事务（ACID）无法跨服务保证数据一致性。
HMX 平台的设计理念
平台 不提供 强一致性的分布式事务解决方案（如 2PC、TCC 等），原因如下：
| 考虑因素 | 说明 |
|---|---|
| 性能损耗 | 强一致性方案（如 2PC）需要锁定资源，事务时间长，严重影响系统吞吐量 |
| 复杂性高 | 引入分布式事务框架会增加系统的复杂性和维护成本 |
| 业务耦合 | 强一致性方案对业务代码侵入较大，改造困难 |
| 场景差异 | 不同业务对一致性的要求不同，统一方案难以适配所有场景 |
平台采用更务实、更契合微服务架构的 最终一致性 理念：基于消息队列的异步事务模式。
RabbitMQ 集成方案
平台封装了 RabbitMQ 消息队列的集成能力，建议业务系统通过 本地消息表 + 消息队列 的模式实现分布式事务的最终一致性。
核心流程
以"创建订单并扣减库存"为例：
关键设计要点
| 要点 | 说明 |
|---|---|
| 本地消息表 | 消息记录与业务数据在同一数据库事务中写入，保证原子性 |
| 可靠投递 | 后台异步扫描本地消息表，确保消息至少发送一次到 RabbitMQ |
| 可靠消费 | 消费者手动确认（ACK），业务处理成功后才确认，保证消息不丢失 |
| 重试机制 | 消费失败的消息重新入队，支持配置重试次数和死信队列 |
| 幂等设计 | 消费者需实现幂等处理，防止重复消费导致数据异常 |
平台封装能力
平台提供以下开箱即用的能力：
- 消息发送封装：简化 RabbitMQ 连接、交换机、队列的配置与管理
- 本地消息表基类：提供消息实体的标准定义和基础操作接口
- 后台调度服务：自动扫描本地消息表并推送到 RabbitMQ
- 消费者基类：封装消息接收、手动确认、异常处理等通用逻辑
- 重试与死信：支持配置消费失败的重试次数和死信队列
使用建议
| 场景 | 建议 |
|---|---|
| 跨服务、跨数据库 | 采用本地消息表 + RabbitMQ 方案，保证最终一致性 |
| 强一致性要求极高 | 评估是否可将相关操作放到同一个服务/同一个数据库中 |
| 对性能要求极高 | 评估业务是否可接受异步补偿，或调整业务模型 |
设计优势
- 解耦服务：服务之间通过消息交互，降低直接依赖
- 提高吞吐：异步处理，避免同步等待
- 可靠性高：消息持久化 + 手动确认，保证消息不丢失
- 灵活可控：业务系统可根据场景选择是否使用、如何重试
- 运维简单：复用 RabbitMQ 生态，监控、管理工具完善