论分布式事务及其解决方案

在订单创建和库存处理环节，我们采用事务消息来满足跨服务处理最终一致的要求

该平台在用户下单时需要同时完成订单生成、库存占用和后续通知等工作，如果把这些操作全部放在一个同步事务中，系统会长时间等待库存处理和外部接口结果，活动高峰期吞吐量明显下降；如果完全不做一致性控制，又可能出现订单已经生成但库存没有占用的情况

为解决这一问题，我组织项目组将订单创建作为本地事务的核心边界，在 MySQL 中保存订单及其初始状态，同时通过 RocketMQ 发送订单创建消息，通知库存和消息等模块继续处理

具体运行时，用户提交订单后，订单模块先保证订单记录可靠落库，再发布后续处理消息；库存模块收到消息后完成库存占用，并记录处理结果

以活动商品下单为例，即使库存处理短时间排队，订单记录和后续处理消息也能够保持对应关系

通过事务消息，系统在不长时间阻塞用户请求的前提下，使订单和库存处理达到最终一致

在支付确认和订单状态流转方面，我们采用补偿事务来满足外部支付结果延迟和异常恢复的要求

线上支付过程需要依赖第三方支付平台，支付回调可能出现延迟、重复或短暂失败，如果订单状态只依赖一次同步回调，就可能出现用户已经支付成功而平台订单仍停留在待支付状态的问题

为解决这一问题，我们将支付流水和订单状态分开记录，并设计了定时补偿机制

具体做法是，支付模块接收到回调后先保存支付流水，再通知订单模块更新状态；对于长时间未收到回调或状态不一致的订单，由 xxl-job 定时扫描订单和支付流水，并根据支付平台查询结果执行补偿确认或关闭处理

以支付成功但订单状态未更新为例，补偿任务会根据支付流水重新推动订单状态变更，并记录补偿过程供客服查询

通过补偿事务，系统能够处理外部接口不稳定带来的状态不一致问题，提高了交易流程的可恢复性

在重复提交和重复消费控制方面，我们采用幂等控制来满足交易结果唯一性的要求

如果没有幂等机制，就可能造成重复生成订单、重复扣减库存或重复发送通知等问题

为解决这一问题，我们在关键业务环节设置了业务唯一标识和处理状态判断

具体实现时，订单模块根据用户、商品和活动生成防重标识，库存模块根据订单号控制库存处理唯一性，支付模块根据支付流水号控制回调处理唯一性；Redis 用于快速拦截短时间重复请求，MySQL 唯一约束作为最终校验手段

以支付回调为例，同一支付流水只允许推动一次订单状态变更，后续重复回调只记录日志而不重复处理

通过幂等控制，系统在高并发、网络重试和消息重复投递情况下仍能保证交易结果正确，降低了分布式事务处理的风险