12.Spring Cloud Alibaba Seata分布式事务使用入门

事务四大特性

一组批量的SQL语句(insert,update,delete)执行来操作数据库数据，使用事务来处理，保证数据的完整性，要么全部执行，要么全部不执行。这组批量SQL可视为一个完整的逻辑处理工作单元。

比如：转账，借钱的批量更新操作，删除用户所有信息级联删除的操作。

那么事务应满足四个条件(ACID)：

• 原子性-Atomicity

  事务作为一个整体(不可分割的工作单元)，要么全部成功(commit)，要么全部失败(rollback)。不可能只执行其中的一部分操作。

• 一致性-Consistency

  事务在开启之前和结束之后，数据的完整性没有被破坏。

• 隔离性-Isolation

  一个事务的执行，不影响其他事务的执行。即：并发执行的事务之间不能互相干扰。

• 持久性-Durability

  已提交的事务对数据的操作是永久的。

分布式事务

分布式系统CAP原则包括：Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)。

分布式事务是解决分布式系统中数据一致性的常用方案。

分布式事务实现

1. 2PC

Two-phase commit protocol 二阶段提交

XA协议由X/Open组织(最先是Tuxedo)提出的资源管理器(数据库)与事务管理器的接口标准。XA协议采用两阶段方式来管理分布式事务。

JTA(Java Transaction API)定义了Java的XA协议接口(并没有实现)，由各个厂商实现JAT接口。

回到重点：二阶段提交引入一个事务协调者来管理参与者(各微服务)的提交或回滚。

• 准备阶段

  

• 提交阶段

  等所有的参与者返回准备成功，那么协调者则向所有参与者发送提交事务命令。

  

  一旦某一个参与者准备失败，那么那么协调者则向所有参与者发送回滚事务命令。

  

2PC存在的缺陷：

1. 同步阻塞。所有的参与者在等待其他参与者时处于阻塞状态。
2. 单点问题。协调者在2PC中的作用从图中可以看到非常重要，一旦发生故障，影响很大 。
3. 存在数据不一致的情况。如果协调者在给某个参与者发生提交消息时，种种原因导致发生失败，只有部分参与者的数据进行了提交。
4. 2PC适用于数据库层面的分布式场景。

2. 3PC

为了解决2PC的一些缺陷，3PC(准备阶段，预提交阶段，提交阶段)出现了，在2PC的基础上多了一个预提交阶段。但整体的交互过程更长了，且还是会出现数据不一致的问题。

• 准备阶段 CanCommit

  

• 预提交阶段 PreCommit

  

• 提交阶段 doCommit

  

3PC中参与者也引入了超时机制，在等待超时后协调者和参与者会中断事务，与2PC中只有协调者才有超时机制相比，降低了阻塞时间。但是治标不治本啊，在第三阶段发给某一协调者的消息超时，还是会出现数据不一致的情况。

3. TCC

TCC(Try - Confirm - Cancel)与2PC，3PC(数据库层面)不同，TCC是业务层面的分布式事务。也称为补偿事务。针对每一个操作，都注册一个与其对应的确认和撤销(补偿)操作。

• Try

  对资源做预留和锁定。

• Confirm

  确认操作

• Cancel

  撤销。将Try阶段的操作撤销。

TCC的缺点：

在Confirm或Cancel阶段，都有可能失败。这样一来，会额外的编写撤销代码融入到业务中，对业务入侵较大。并且有些特定的业务场景，失败后需要人工介入。

4. 本地消息表

使用系统本地的事务来实现分布式事务(将一个大的分布式事务分解为若干微服务中的小事务)。

首先需要在本地新建一张消息表(与业务数据表处于同一个库)，利用本地的事务特性保证对这两个表的操作，使用消息队列将消息表中的消息进行通知，调用下一个操作。调用成功，则更新消息表中的状态即可。调用失败，后台定时任务会定时读取本地消息表，将未成功的消息再调用对应的服务，等调用成功更新状态。存在消息对应的操作不成功，都会重试。这里要保证对应服务的方法是幂等。一般重试会有最大次数，超过了最大次数会有人工处理。

这样一来，本地消息表是保证了数据的最终一致性。

但是，这样严重依赖于数据库的消息表来管理事务，频繁的读写给数据库也带来了压力，高并发下也会有瓶颈。

5. 消息事务

直接使用MQ(RocketMQ)来实现事务，不再使用本地消息表。

Rocket MQ 中文文档

首先A服务向Brock发送事务消息，这个事务消息对服务B不可见(Half Message)。

服务A确认消息发送成功后，开始执行本地事务。根据执行事务的结果给Broker回复。

事务执行成功，A发送Commit至Broker，则B服务可以消费该事务消息；