分布式事务解决方案

基础概念

刚性事务

强一致性，遵循 ACID 原则

柔性事务

最终一致性，基于 BASE 理论，允许一段时间内不一致，但最终要一致

一、2PC模式（刚性）

2 phase commit 两阶段提交，又叫做 XA Transaction，由数据库提供原生支持

• 第一阶段
  事务管理器，要求涉及到该事务的数据库预提交此操作，并反馈是否可以提交
• 第二阶段
  事务管理器要求每个数据库提交数据，如果有任何一个数据库否决了本次提交，所有的数据库都会进行回滚操作
  
• 缺点
  性能比较差，不适合高并发场景
  实现不完善

二、TCC（柔性）

T(try) —— C(confirm)——C(cancel)

三、最大努力通知（柔性）

主要用于和第三方进行通讯，不保证一定通知成功，但要提供可查询操作结果的接口，如果第三方通知我们失败了，我们还可以调用第三方的查询接口进行结果查询

比如下单失败回滚了，但是库存已经冻结了。此时订单服务可以给库存服务发送 MQ 消息，但是不能只发送一条，万一发送失败了库存服务就接受不到我们的通知了，所以我们要设置一个最大通知次数，每隔一段时间发送一条通知。直到库存服务告诉我们，他已经收到通知了，或是达到了最大通知次数就不再发送了。

案例： 调用支付宝进行支付，支付宝对我们的支付结果通知就是最大努力通知

四、可靠消息 + 最终一致性方案（柔性）

异步，最终达到一致

事务提交之后，发送一个消息通知其他服务，其他服务通过订阅消息异步达到最终一致性

比如下单成功之后，发送一条 MQ 消息去给用户增加购物积分

总结

如果是高并发场景推荐使用方案三、四，基于消息通知