分布式事务

一、AT事务

上面这个图是什么意思呢？tx1和tx2是两个全局的事务,
这个时候tx1去对 a 表的 m 字段进行更新操作，m 的初始值 1000。tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 全局锁 ,本地提交释放本地锁。
tx2又开始对a表进行操作，tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 全局锁 ，注意 tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。
如果tx1没有释放全局锁,那么tx2就会一直等待全局锁，这样就可以保证数据的一致性了

1.1:AT事务如何保证数据的完整性?

假如接下来我们要对这些业务执行一系列操作，假如我们扣钱成功了，但是我们在调用另一个为服务扣库存的时候，异常了，那么如果使用TA来实现呢？

AT在对每个数据库操作的时候，必须有一个日志表，也就是如果中间的事务出错了，那么可以根据日志表来进行回滚，

1.2:AT优点?

• 使用简单只需要配置好服务，还有每个数据库的日志表就好了
• 速度快，效率高

1.3:AT的缺点?

• 如果AT事务服务宕机，那么事务将不再起作用。\

1.4:AT事务的回滚机制?

1. 一阶段：

• 解析sql根据sql生成一个xid，然后根据你的要修改的数据同步到log表中,
• 本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。

2. 二阶段：

• 收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作
• 根据log中的xid和数据进行一个回滚

多个服务的回滚：
假如说 我现在要调用三个服务的接口， 我调用了第一个接口后，这个接口执行完成了 生成了xid和数据存在了log表中，当我执行第二个服务的接口时，这时候接口报错了，tm会告诉tc说这个事务没有执行成功，那么tc就会把已经执行完的事务进行一个回滚操作。

二、TCC事务

从上图我们举个例子来讲述tcc事务，假如现在我们要执行这样一个逻辑，当用户下单以后，我们要去扣用户的钱，并且扣除对应商品的库存，然后增加用户在我们平台的积分，这个时候我们使用tcc事务来保证这几个事务的一致性

2.1 try操作

这时候我们要对，我们要扣的钱，弄到一个冻结表里 我们并不会去操作主表的数据 这就是tcc的一个try操作

2.2 confirm操作

所谓的confirm操作也就是 如果try都执行完成的情况下 那么就会执行confirm操作，并且把冻结表里面的数据都变成0

2.3 cancel操作

即上图，如果其中一个try执行失败的话，那么我们不必对数据库进行处理，直接对冻结表将上一个try的冻结表弄成0就可以了，那么这个事务就执行失败了

2.4 TCC的缺点

1. 对业务层需要大量的代码（这是个工作量问题）

四、MQ事务