【Java】分布式事务几种解决方案
1、分布式事务" title="分布式事务">分布式事务从数据一致性分类
- 强一致性设计（2PC）
- 最终一致性（TCC，可靠消息事务，本地事件表）
2、2PC
- XA是一个分布式事务协议，该协议大致分为两部分：事务管理器（协调者）和本地资源管理器（参与者），定义一个事务的执行过程分为两个阶段(2PC) ，二阶段分别指的是准备 和 提交/回滚 两个阶段
- 2PC 是一个基于同步阻塞协议。
- 准备阶段 协调者会给各参与者发送准备命令,协调者有超时机制即参与者超时未返回 会执行回滚事务。
- 提交阶段，参与者有重试机制
- 假如在第一阶段所有参与者都返回准备成功，那么协调者则向所有参与者发送提交事务命令，然后等待所有事务都提交成功之后，返回事务执行成功。
- 假如在第一阶段有一个参与者返回失败，那么协调者就会向所有参与者发送回滚事务的请求，即分布式事务执行失败
5.2PC优缺点
- 优点:利用数据库自身的功能进行本地事务的提交和回滚，强一致性的分布式事务。
- 缺点:协调者存在单点问题，同步阻塞导致长久的资源锁定问题 效率低，2PC 适用于数据库层面的分布式事务场景，没法满足基于业务需求层面的布式事务场景。
3、TCC
TCC 指的是Try - Confirm - Cancel（补偿机制）
- Try 指的是预留，即资源的预留和锁定，注意是预留。
- Confirm 指的是确认操作，这一步其实就是真正的执行了。
- Cancel 指的是撤销操作，可以理解为把预留阶段的动作撤销了。
TCC优缺点
- 优点:TCC是基于业务层面实现的分布式事务，可以跨数据库、跨不同的业务系统来实现事务。
- 缺点:业务的侵入较大和业务耦合度增加，撤销和确认操作的执行可能需要重试，需要保证操作的幂等，开发工作量加大。
4、可靠消息事务
- 消息中间件需要对消息事务的支持，RocketMQ 就很好的支持了消息事务
消息事务实现过程:
- 第一步先给消息中间件 发送事务消息即半消息（待确认消息），而是这个消息对消费者来说不可见，然后发送成功后发送方再执行本地事务，再根据本地事务的结果向 消息中间件 发送 Commit 或者 RollBack 命令。
- 第二步消息中间件有超时询问机制，如果一段时间内半消息（待确认）没有收到任何操作请求，那么 消息中间件 会通过反查接口得知发送方事务是否执行成功，然后执行 Commit 或者 RollBack 命令。
消息事务优缺点:
- 优点: 最终一致性时间敏感度较高，降低业务被动方实现成本，吞吐量优于本地事件表方案
- 缺点: 消息事务支持的很好的中间件并不多，需要实现事务反查接口
5、本地事件表事务
- 本地事件表其实就是利用了 本地的事务来实现分布式事务(将业务的执行和将事件放入事件表中的操作放在同一个事务中)
- 后台任务定时去读取本地事件表，筛选出还未成功的事件再调用对应的服务，服务执行成功了再变更事件表事件的状态。
- 需要有重试，重试就得保证对应服务的方法是幂等的，而且一般重试会有最大次数，超过最大次数可以记录下报警让人工处理。
- 本地事件表事务优缺点:
- 优点：从应用设计开发的角度实现了事件数据的可靠性，事件数据的可靠性不依赖于消息中间件，弱化了对 MQ 中间件特性的依赖
- 缺点: 事件表与具体的业务场景绑定，耦合性强，不可公用
6、案例分享
- 电商-交易系统
以上是 【Java】分布式事务几种解决方案 的全部内容， 来源链接： utcz.com/a/95785.html
