分布式事务解决方案

1 DTP

5.2 2PC模型

整个事务分为Prepare和Commit阶段：Prepare->Commit

事务执行成功时：

Prepare阶段

Commit阶段

事务执行失败时：

Prepare阶段

Commit阶段

两阶段模型的问题：

• 同步阻塞问题：事务在执行过程中，所有参与事务的节点都会对其占用的公共资源加锁，导致其他访问公共资源的进程或线程阻塞
• 单点故障问题：如果事务管理器发生故障，则资源管理器会一致阻塞
• 数据不一致问题：如果在Commit阶段，由于网络或部分资源管理器发生故障，导致部分资源管理器没有接收到事务管理器发送过来的commit消息，会引起数据不一致的问题
• 无法解决的问题：如果Commit阶段，事务管理器发出Commit消息之后宕机，并且唯一接受到这条Commit消息的资源管理器宕机了，则无法确认事务是否已经提交

5.3 3PC模型

3PC把2PC中的Prepare阶段一分为二，最终为：CanCommit->PreCommit->DoCommit/Rollback

事务执行成功时：

CanCommit

PreCommit

DoCommit

事务执行失败时：

CanCommit

PreCommit

DoRollback

3PC的问题

• 在3PC中，如果资源管理器没有及时收到来自事务管理器发出的消息，那么资源管理器就会执行提交事务的操作，会导致数据不一致；
• 如果网络故障发生，资源管理器没有收到事务管理器发送的Abort消息，则资源管理器会在一段时间之后提交事务，会导致与其他收到Abort消息并执行了事务回滚操作的资源管理器的数据不一致

5.4 TCC

TCC三个阶段：Try - > Confirm -> Cancel

• Try：不执行任何业务逻辑，制作业务一致性检查和预留相应的资源，这些资源能和其他操作保持隔离
• Confirm：一般任务Confirm阶段不会失败，如果失败了要引入重试机制或者人工干预
• Cancel：业务执行错误时，进行回滚。一般认为Cancel一定成功，如果失败了要引入重试机制或者人工干预

关键技术：

• AOP切面
• 反射技术
• 持久化技术
• 序列化技术
• 定时任务
• 动态代理
• 多配置源技术

5.5 可靠消息最终一致性

事务发起方执行完本地事务之后，发出一条消息，事务参与方（消息的消费者）一定能收到这条消息并执行成功。

主要适用于：消息能够独立存储，降低系统之间的耦合度，并且业务对数据一致性的时间敏感度高的场景。

需要注意：

• 本地事务和消息发送的原子性问题：通过消息确认机制解决
• 事务参与方接收消息的可靠性和幂等性问题：通过恢复服务解决可靠性问题；通过消费方的方法幂等机制解决幂等性问题

幂等：只要参数相同，无论调用多少次接口或者方法，得出的结果和第一次调用接口或方法得出的结果相同。

5.5.1 本地消息表

通过本地事务，将业务数据和消息数据分别保存到本地数据库的业务数据表和本地消息表中，然后通过定时任务读取本地消息表中的消息数据，将消息发送到消息中间件，等到消息消费者成功接收到消息后，再将消息表中的消息删除。

5.5.2 RocketMQ

RocketMQ的事务消息主要是为了让Producer端的本地事务和消息发送逻辑形成一个完整的原子操作。

5.6 最大努力通知

使用场景：分布式事务跨越多个不同的系统时可以使用；适用于最终一致性时间敏感度低，并且事务被动方的处理结果不会影响主动方的处理结果。如：支付成功之后发通知

执行流程：

1）业务主动方完成业务处理之后，向业务被动方发送消息通知。发送消息通知时，允许消息丢失；

2）业务主动方可以设置时间梯形通知规则，在消息通知失败后，可以按照规则再次通知，直到达到最大通知次数为止；

3）业务主动方需要提供查询接口给业务被动方使用，用于恢复丢失的消息。