分布式事务解决方法

方法一、补偿事务（TCC)  严选、阿里、蚂蚁金服

Tcc 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作，它分为三个阶段

try阶段：主要是对业务系统做检测及预留资源

confirm阶段：主要是对业务系统做确认提交，try阶段执行成功并开始执行confirm阶段时，默认-- confirm阶段是不会错误的，即只要try成功，confirm一定成功

cancel阶段：主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放

☛ 举例说明

张三要向李四转账，思路大概是：我们有一个本地方法，里面依次调用

  ①. 首先在try阶段，要先调用远程接口把两个人的钱冻结起

  ②. 在confirm阶段，执行远程调用的转账的操作，转账成功进行解冻

  ③. 第二步执行成功，则转账成功，如失败，则调用远程冻结接口对应的解冻方法（cancel）

➳ 优点：跟2pc相比，实现及流程相对简单些，但数据的一致性比2pc要差一些

✷ 缺点：第2、3步都有可能失败，Tcc属于应用层的补偿方式，需程序员在实现时写很多补偿代码

方法二、本地消息表（异步确保）

比如：支付宝、微信支付主动查询支付状态，对帐单的形式

本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性

✦ 操作流程

①. 在分布式事务操作的一方，完成写业务数据的操作之后，向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中

②. 之后将本地消息表中的消息转发到Kafka等消息队列中，如果转发成功，则将消息从本地消息表中删除，否则继续重新转发

③. 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作

基本思路就是：

消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。

消息消费方，需要处理这个消息，并完成自己的业务逻辑。此时如果本地事务处理成功，表明已经处理成功了，如果处理失败，那么就会重试执行。如果是业务上面的失败，可以给生产方发送一个业务补偿消息，通知生产方进行回滚等操作。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。如果有靠谱的自动对账补账逻辑，这种方案还是非常实用的。

➳ 优点：一种非常经典的实现，避免了分布式事务，实现了最终一致性

✷ 缺点：消息表会耦合到业务系统中，如何没有封装好的解决方案，会有很多杂活需要处理