分布式事务常见方案

微服务网关

MQ订阅方

调用红包服务

调用代理层

本地事务

原子接口

调用逻辑层

事务状态服务

正常结束

记录调用

MQ发送方

Proxy

2.半消息发送成功

DB1

Msg Table

1. 发送半消息

调用减红异常

返回失败

微服务（MQ 客户端）

订单服务

补偿接口

MQ Server

事务服务

回滚：删除消息不投递

修改事务组状态

proxy

成功流程，下单：锁库存--减红包--创建订单

方案一、业务方提供本地操作成功回查功能（RocketMQ）    1. 事务消息：MQ提供类型XA的分布式事务功能，通过MQ事务消息能达到分布式事务的最终一致    2. 半消息：暂不能投递的消息，发送方已经将消息发送到MQ服务器，服务器未收到生产者的二次确认，此消息被标记为暂不能投递，即半消息    3. 消息回查：由于网络原因，生产者重启等原因，导致某条消息的二次确认丢失，MQ服务端扫描发现有消息长期处于半消息状态，需要主动向消息消息生产者询问改消息的最终状态，即消息回查    4. MQ事务消息作为异步确保性事务，将两个事务通过MQ解耦，整个事务设计借鉴了两阶段提交

7.根据事务的状态提交或者回滚消息

发送方不幂等：1. At most once：至多一次2. Only once：仅一次3. At least once：至少一次

分布式事务补偿服务

1. 写入业务数据和消息数据（本地事务）

同步场景分布式事务设计方案（Saga实现）

5.未收到4的确认，发起消息回查

调用订单服务

事务DB

3.执行本地事务

抛出异常

库存服务

微服务业务逻辑层

6.检查本地事务状态

微服务数据访问层

调用库存服务

补偿红包服务

序列化服务

RPC 客户端

4. 消息回执

RPCProxy

调用减库存成功

3.将消息写入MQ

总体架构

提交：投递消息

创建事务组

方案二、本地事务消息表（常用方案）    1. 本地操作和发送消息通过本地事务强一致

发起事务补偿

DB2

红包服务

提示：同一个服务部署多个，需要通过分布式锁，避免消息重复提交到MQ

Proxy作为代理，记录事务组信息，包括事务ID、事务状态、时间戳等RPCProxy记录调用参数，并记录到事务DB，包括事务ID、事务步骤、补偿方法、参数类型、参数值等，一旦出现失败的情况，发起补偿，由补偿服务根据补偿方法和参数进行RPC调用

Rocket MQ Server

调用订单成功

补偿库存服务

事务组完成

2. 从消息表获取消息

Biz Table

4.提交或回滚

事务调度服务

调用减红包成功

创建订单

优点：通用缺点：业务方提供回查接口，业务侵入大；发送消息非幂等；消息消费端需要处理幂等

异常处理：A--B--C，AB成功，C失败：1. 记录错误日志2. 告警3. 人工介入

优点：业务侵入小缺点：发送消息非幂等；消息消费端需要处理幂等

5. 删除消息

异步场景分布式事务设计方案（MQ驱动）