分布式事务（项目）

1.为什么会有分布式事务？

分布式系统经常出现的异常如： 机器宕机，网络异常，消息丢失，消息乱序，数据错误，不可靠的TCP，存储数据丢失等...

分布式事务是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个

东西，特别是在微服务架构中，几乎可以说是无法避免。

2.CAP定理与BASE理论

2.1CAP理论

2.2 BASE理论

是对 CAP 理论的延伸，思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但可

以采用适当的采取弱一致性，即 最终一致性。

详细的分布式事务：

分布式事务（ 图解 + 秒懂 + 史上最全 ） - 疯狂创客圈 - 博客园 (cnblogs.com)

3.分布式事务的几种方案

3.1 2PC模式

Seata:（类似于微服务和Nacos的关系，TC和TM）（Alibaba Seata，2PC的一种变形）

Seata和普通的2PC模式的区别在于 ，一阶段和二阶段的具体行为不同。（高并发场景，如下单阶段  Seata将不再适合）

 Seata的分布式交易解决方案：

 具体的使用Seata可以参照开发手册。

项目中的操作步骤为：

 3.2 柔性事务-TCC事务补偿型方案(TCC——高性能分布式事务解决方案)

在高并发场景下，通常使用以下的分布式事务解决方案：

 3.3 柔性事务-最大努力通知型方案

按规律进行通知， 不保证数据一定能通知成功，但会提供可查询操作接口进行核对 。这种

方案主要用在与第三方系统通讯时，比如：调用微信或支付宝支付后的支付结果通知。这种

方案也是结合 MQ 进行实现，例如：通过 MQ 发送 http 请求，设置最大通知次数。达到通

知次数后即不再通知。

理解为：  如库存服务订阅MQ中的消息，但是由于订单业务创建失败，我们本身不清楚库存服务是否真正的接收到了创建失败的消息，因此订单业务会往 MQ中每隔一段时间 发出一条“创建失败” 的消息，当库存服务接收到该“创建失败”的消息之后，就会执行相应的业务逻辑，当业务逻辑执行完毕，就会告诉MQ（“收到MQ创建失败的消息”），由此MQ将不再通知“创建失败”的消息。

案例：银行通知、商户通知等（各大交易业务平台间的商户通知：多次通知、查询校对、对

账文件），支付宝的支付成功异步回调。

3.4 柔性事务-可靠消息 + 最终一致性 方案 （异步确保型）（项目中使用）

实现该分布式事务模式，需要使用RabbitMQ的延时队列，实现定时任务。

 定时任务还存在一定的缺点，如：

1.定时任务的时效性问题；

MQ实现延时队列：只需要将订单创建或者取消的消息放入到MQ中存放一定的时间，并让库存服务或者订单服务监听MQ的消息，就可以实现最终一致性。