分布式事务几种解决方案

1、分布式事务从数据一致性分类

1. 强一致性设计（2PC）
2. 最终一致性（TCC，可靠消息事务，本地事件表）

2、2PC

1. XA是一个分布式事务协议，该协议大致分为两部分：事务管理器（协调者）和本地资源管理器（参与者），定义一个事务的执行过程分为两个阶段(2PC) ，二阶段分别指的是准备 和 提交/回滚 两个阶段
2. 2PC 是一个基于同步阻塞协议。
3. 准备阶段 协调者会给各参与者发送准备命令,协调者有超时机制即参与者超时未返回 会执行回滚事务。
4. 提交阶段，参与者有重试机制

• 假如在第一阶段所有参与者都返回准备成功，那么协调者则向所有参与者发送提交事务命令，然后等待所有事务都提交成功之后，返回事务执行成功。

• 假如在第一阶段有一个参与者返回失败，那么协调者就会向所有参与者发送回滚事务的请求，即分布式事务执行失败

5.2PC优缺点

• 优点:利用数据库自身的功能进行本地事务的提交和回滚，强一致性的分布式事务。
• 缺点:协调者存在单点问题，同步阻塞导致长久的资源锁定问题 效率低，2PC 适用于数据库层面的分布式事务场景，没法满足基于业务需求层面的布式事务场景。

3、TCC

1. TCC 指的是Try - Confirm - Cancel（补偿机制）

   • Try 指的是预留，即资源的预留和锁定，注意是预留。
   • Confirm 指的是确认操作，这一步其实就是真正的执行了。
   • Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。

   

2. TCC优缺点

   • 优点:TCC是基于业务层面实现的分布式事务，可以跨数据库、跨不同的业务系统来实现事务。
   • 缺点:业务的侵入较大和业务耦合度增加，撤销和确认操作的执行可能需要重试，需要保证操作的幂等，开发工作量加大。

4、可靠消息事务

1. 消息中间件需要对消息事务的支持，RocketMQ 就很好的支持了消息事务

2. 消息事务实现过程:

   • 第一步先给消息中间件 发送事务消息即半消息（待确认消息），而是这个消息对消费者来说不可见，然后发送成功后发送方再执行本地事务，再根据本地事务的结果向 消息中间件 发送 Commit 或者 RollBack 命令。
   • 第二步消息中间件有超时询问机制，如果一段时间内半消息（待确认）没有收到任何操作请求，那么 消息中间件 会通过反查接口得知发送方事务是否执行成功，然后执行 Commit 或者 RollBack 命令。

1. 消息事务优缺点:

   • 优点: 最终一致性时间敏感度较高，降低业务被动方实现成本，吞吐量优于本地事件表方案
   • 缺点: 消息事务支持的很好的中间件并不多，需要实现事务反查接口

5、本地事件表事务

1. 本地事件表其实就是利用了 本地的事务来实现分布式事务(将业务的执行和将事件放入事件表中的操作放在同一个事务中)
2. 后台任务定时去读取本地事件表，筛选出还未成功的事件再调用对应的服务，服务执行成功了再变更事件表事件的状态。
3. 需要有重试，重试就得保证对应服务的方法是幂等的，而且一般重试会有最大次数，超过最大次数可以记录下报警让人工处理。

1. 本地事件表事务优缺点:

• 优点：从应用设计开发的角度实现了事件数据的可靠性，事件数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖
• 缺点: 事件表与具体的业务场景绑定，耦合性强，不可公用

6、案例分享

1. 电商-交易系统