分布式事务对比及方案

前言

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。

2PC

两阶段提交协议(Two Phase Commitment Protocol)中，涉及到两种角色

一个事务协调者（coordinator）：负责协调多个参与者进行事务投票及提交(回滚)
多个事务参与者（participants）：即本地事务执行者

主要流程：通俗来说分为预操作和确认操作

Seata

Seata的设计目标其一是对业务无侵入，在传统2PC的基础上演进，并解决2PC方案面临的问题。Seata把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回滚。

具体的执行流程如下：

1、正常提交流程

2、回滚流程

1、每个RM使用DataSourceProxy连接数据库，其目的是使用ConnectionProxy，使用数据源和数据连接代理的目
的就是在第一阶段将undo_log和业务数据放在一个本地事务提交，这样就保存了只要有业务操作就一定有
undo_log。
2、在第一阶段undo_log中存放了数据修改前和修改后的值，为事务回滚作好准备，所以第一阶段完成就已经将分
支事务提交，也就释放了锁资源。
3、TM开启全局事务开始，将XID全局事务id放在事务上下文中，通过feign调用也将XID传入下游分支事务，每个
分支事务将自己的Branch ID分支事务ID与XID关联。
4、第二阶段全局事务提交，TC会通知各各分支参与者提交分支事务，在第一阶段就已经提交了分支事务，这里各
各参与者只需要删除undo_log即可，并且可以异步执行，第二阶段很快可以完成。
5、第二阶段全局事务回滚，TC会通知各各分支参与者回滚分支事务，通过 XID 和 Branch ID 找到相应的回滚日
志，通过回滚日志生成反向的 SQL 并执行，以完成分支事务回滚到之前的状态，如果回滚失败则会重试回滚操
作。

优点	缺点
阿里开源，完整中间件方案	只支持JAVA，不适合资源竞争激烈的场景
代码入侵性低，自动生成回滚sql完成回滚	回滚日志包含了数据的前镜像和后镜像，这意味着，事务影响的数据越多，回滚日志越大，回滚日志存放在本地数据库中（redo_log表）

TCC

TCC 是 Try - Confirm - Cancel 的首字母缩写，把事务提交分为 Try - Confirm - Cancel 3个操作，Try为第一阶段，Confirm / Cancel为第二阶段，是一种应用层面侵入业务的两阶段提交。

操作方法	含义
Try	预留业务资源
Confirm	事务执行成功，实际提交数据
Cancel	事务回滚，并回滚数据

优点	缺点
锁粒度小，不会锁定整个资源	侵入性强，每个事务都必须实现try，confirm，cancel等3个方法，开发维护成本高

SAGA

优点	缺点
轻量 ，易理解	对于超时事务、重启等场景需要另起线程回滚，不适合资源竞争激烈的场景
分布式事务发起者作为协调者	协调者负责回滚
每个操作对应回滚接口	每个参与者需要提供幂等的回滚接口

回滚接口的要求和技术要点

空回滚

分两种情况：

(1) 定义：在正向操作时，由于网络超时或者丢包引起，中间件没有收到事务提交的请求，而直接执行反向操作。

解决方案：开启分支事务前，需往事务记录表插入一条数据，回滚时，判断是否存在事务记录数据，若没有，直接返回回滚成功

(2) 定义：在正向操作时，由于网络超时或者丢包引起，中间件没有收到事务提交的请求，而直接执行反向操作。

此时正向操作刚好执行

解决方案：拒绝本次回滚请求，中间件等待，重试回滚

防悬挂

定义：反向操作比正向操作先执行

解决方案：即先有空回滚，正向接口执行时，判断是否已经有过回滚，有的话需要拒绝正向请求，此事务已经回滚

幂等

定义：网络原因，或者重试操作都有可能导致这几个操作的重复执行

解决方案：最好在业务侧进行幂等判断，利用状态或去重表