基于 RocketMQ 事务消息的分布式事务架构设计一、方案简介1.1 解决问题微服务分布式场景下保证本地数据库事务操作与发送MQ消息原子一致本地事务成功则消息一定可投递本地事务失败则消息不会下发杜绝资金不一致、漏通知、资损问题。1.2 核心实现思路基于RocketMQ两阶段半消息机制 本地事务状态落库持久化 Broker定时事务回查做宕机/断连兜底实现最终一致性分布式事务适配支付、账务、清结算金融场景。1.3 适用范围支付扣款、充值、退款、订单状态同步、账务流水异步通知等跨服务异步业务场景。二、核心架构角色业务生产者服务发送半消息、执行业务本地事务、持久化事务状态、实现本地事务执行与事务回查双回调接口。RocketMQ Broker存储未投递半消息、定时发起事务回查、根据回查结果提交/删除半消息、配置回查频次与最大回查次数。下游消费者服务消费事务消息业务幂等处理手动ACK保证可靠消费。三、完整业务执行流程正常无故障流程生产者向Broker发送半消息PREPAREDBroker持久化半消息但不对外投递。执行executeLocalTransaction回调开启本地数据库事务执行业务操作扣款、生成订单、账务流水同一事务插入本地事务记录表标记状态为「处理中」本地事务执行成功更新事务记录为「成功」向Broker发送Commit指令Broker将半消息转为可投递消息下游可消费。本地事务执行异常回滚事务记录表同步回滚消失向Broker发送Rollback指令Broker直接删除半消息。宕机/断连兜底回查流程生产者发送半消息后宕机、网络中断未向Broker提交Commit/Rollback。Broker到达配置间隔默认60s触发定时任务调用生产者checkLocalTransaction回查接口。回查接口通过消息携带的RocketMQ事务唯一ID-transactionId查询本地事务记录表返回三种状态COMMIT_MESSAGE存在且事务成功Broker放行消息ROLLBACK_MESSAGE无事务记录本地事务回滚Broker删除半消息UNKNOW事务仍在处理Broker等待下次回查达到最大回查次数默认15次仍返回UNKNOWBroker自动回滚丢弃消息触发系统告警人工介入。四、数据库设计本地事务记录表金融强制落地CREATETABLEmq_trans_record(idBIGINTPRIMARYKEYAUTO_INCREMENTCOMMENT主键,transaction_idVARCHAR(64)NOTNULLCOMMENTRocketMQ事务唯一ID,business_noVARCHAR(64)COMMENT业务单号订单/充值流水号,topicVARCHAR(64)NOTNULLCOMMENT消息Topic,tagVARCHAR(32)COMMENT消息标签,trans_statusTINYINTNOTNULLCOMMENT1-处理中 2-本地事务成功 3-本地事务失败,create_timeDATETIMEDEFAULTNOW(),update_timeDATETIMEDEFAULTNOW()ONUPDATENOW(),UNIQUEKEYuk_transaction_id(transaction_id))ENGINEInnoDBDEFAULTCHARSETutf8mb4;表核心作用服务重启后内存数据丢失回查接口依靠本表持久化凭证判断本地事务真实结果防止宕机导致消息悬停、资损。五、关键接口核心逻辑1. executeLocalTransaction执行本地事务接收半消息提取transactionId开启本地数据库事务执行业务账务/订单SQL插入mq_trans_record状态1业务无异常更新记录状态2提交本地事务返回COMMIT_MESSAGE业务抛异常本地事务回滚记录同步删除返回ROLLBACK_MESSAGE。2. checkLocalTransactionBroker定时回查接口从消息中获取transactionId查询mq_trans_record匹配记录无记录本地事务已回滚返回ROLLBACK_MESSAGE记录存在且status2本地事务成功返回COMMIT_MESSAGE记录存在且status1事务未执行完毕返回UNKNOW六、Broker关键配置参数参数默认值说明transactionCheckInterval60000ms首次半消息回查间隔transactionCheckMax15最大回查次数超限自动丢弃消息consumerMaxReconsumeTimes16消费者最大重试次数耗尽转入死信七、金融级约束与异常兜底规范强制落表禁止仅内存存储事务状态必须使用独立事务记录表或业务主表持久化事务结果消费幂等下游消费以业务唯一流水号做幂等校验防止重复扣款、重复发权益死信隔离消费失败消息进入死信队列生成人工复核工单支持资金冲正补偿告警机制达到最大回查次数未确认、死信消息堆积触发短信/运维平台告警禁止混用事务消息Topic仅允许发送事务消息不支持批量、延时、顺序消息消费模式约束统一使用集群消费手动ACK禁用广播消费避免消息丢失死信专属补偿程序规范禁止依赖原有业务消费者自动处理死信需独立补偿消费服务监听死信队列搭配告警、日志归档、冲正补偿逻辑定期巡检死信堆积。八、下游消费失败场景一致性保障RocketMQ事务消息仅保障生产者本地库与消息投递原子性无法原生保证下游消费必然成功针对上游事务已提交、消息投递成功但下游消费失败场景通过四层闭环机制保障全链路数据一致自动重试自愈消费异常不执行ACK消息进入重试队列按阶梯间隔重试处理网络抖动、下游临时宕机等可恢复故障下游全局业务流水号做幂等拦截避免重复执行业务产生资损。死信隔离与统一处理方案消息达到最大重试次数仍失败自动转入独立死信队列脱离正常消费链路防止脏数据持续重试阻塞业务死信堆积实时触发告警通知运营复核。死信Topic%DLQ%消费组名不会被原有业务消费者自动消费提供两类标准化处理手段自动补偿消费部署独立补偿消费者订阅死信队列批量读取消息根据业务单号校验上下游数据状态人工运维操作运维平台查询死信详情按需将消息重投原Topic或标记归档。基于校验结果分两种处理分支- 可修复场景服务故障、临时配置错误重新投递消息依靠幂等完成下游业务补处理- 不可逆场景账户注销、渠道失效上游发起资金逆向冲正事务生成冲正账务流水并发送冲正事务消息抹平双边数据差额。定时对账兜底每日定时任务比对上游事务记录表、业务账务流水、下游业务表、消费日志统计交易差额生成异常清单自动定位未完成消费数据作为全链路最终兜底防线。九、方案优缺点优点无XA分布式事务锁竞争性能更高Broker自带定时回查具备天然宕机兜底能力消息重试、死信、对账多层兜底上下游全链路可追溯满足金融对账监管要求架构简单无额外中间件依赖。缺点需要额外维护本地事务记录表增加开发量事务消息吞吐略低于普通消息长时间未完成事务会持续触发回查消耗服务与Broker资源需要配套实现幂等、对账、人工冲正流程运维复杂度提升。