分布式事务常见的几种实现方式

事务概念：

单机事务（本地事务）：
对于单系统事务它必须满足四大特性ACID:原子性、数据一致性、隔离性、持久性。
其中C(数据一致性)是要达到的目的，也就是说通过AID来实现C。
原子性是通过undo log来实现的；
持久性是通过redo log来实现的。
隔离性是通过读写锁+MVCC来实现的。

分布式事务：
它有CAP理论：一致性（Consistency）、可用性（Avalibility）、分区容错性（Partition Tolerance）。对于分布式系统只能同时满足这三点中的其中两个。不能选择CA架构，只能选择CP或者AP架构。
BASE理论：Basically Available(基本可用)、soft state(软状态)、Eventually consistent(最终一致性)

分布式事务常见的实现方式

1.全局事务XA模式（一般不使用）

XA(eXtended Architecture)
有两个角色：TM协调者（分布式事务管理者），RM资源参与者（一般是数据库），CRM（TM和RM之间的通信中间件），AP（微服务）
这种一般是数据库实现的，不用业务代码实现，效率相对较低，一般不使用这种模式。
两阶段提交协议（2PC）
在该模型中，一个分布式事务可以被拆分成多个本地事务，运行在不同的AP和RM上，分布式事务必须保证每个本地事务都能同时成功，有一个本地事务失败，则其他事务都必须回滚。使用CRM来通知各个本地事务，同步本地事务执行的状态。
2PC:
第一阶段：准备阶段：各个本地事务完成本地事务的准备工作
第二阶段：执行阶段：各个本地事务根据上一阶段执行结果，进行提交或回滚。
这个过程需要一个TM协调者和RM参与者
缺点：
1.单点故障，如果在第二阶段协调者故障了，参与者就不能知道上一阶段它们是否执行成功
2.在准备阶段和提交阶段，每个事务参与者都会锁定本地资源，并且等待其他事务的执行结果，如果阻塞时间较长，资源锁定时间太久，执行效率就会降低

2.TCC模式

TCC(Try,Commit,Cancel)是一种补偿型事务。它可以解决2PC资源锁定和阻塞的问题
该模型要求应用的每个服务提供try,confirm,cancel三个接口。
准备阶段：try :资源的检查和预留
执行阶段：confirm（提交）/cancel（补偿）:根据上一步结果，判断下面的执行方法，如果上一步中所有事务参与者都成功，则这里执行confirm,反之执行cancel.
try,confirm,cancel都是独立的事务，不受其他参与者的影响，不会阻塞等待其他人。它们由程序员在业务层编写，锁粒度由代码控制。
优点：TCC执行的每一个阶段都会提交本地事务并释放锁，并不需要等待其他事务的执行结果。如果其他事务执行失败，最后不是回滚，而是执行补偿操作（相当于一个反向操作）。这样就避免了资源的长期锁定和阻塞等待，执行效率较高。
缺点：需要人为编写代码实现try,confirm,cancel
开发成本高：一个业务需要拆分为三个步骤，业务编写较为复杂
cancel动作如果执行失败，资源就无法释放，需要引入重试机制，而重试机制可能导致重复执行，还需要考虑重试的幂等问题。

3.可靠消息服务

设计思想是将远程分布式事务拆分成一系列的本地事务。
基本原理：
一般分为事务的发起者A和事务的其他参与者B
1.事务发起者A执行本地事务
2.事务发起者A通过MQ将需要执行的事务信息发送给事务参与者B
3.事务参与者B接收到消息后执行本地事务

为了避免消息发送失败或丢失，我们可以把消息持久化到数据库中。
要保证消息可靠。
消息事务的优点：
业务相对简单，不需要编写三个阶段业务。
是多个本地事务的结合，因此资源锁定周期短，性能好。
缺点：
依赖于MQ的可靠性。
消息发起者可以回滚，但是消息参与者无法引起事务回滚。
事务时效性差，取决于MQ发送消息是否及时，还有消息参与者的执行情况。

4.AT模式

Seata开源了AT模式。
AT模式是一种无侵入的分布式事务解决方案，可以看做是对TCC或者二阶段提交模型的一种优化，解决了TCC模式中的代码侵入，编码复杂等问题。

在AT模式下，用户只需要关注自己的业务SQL,用户的业务SQL作为一阶段，Seata框架会自动生成事务的第二阶段提交和回滚操作。
TC事务协调者，TM事务管理器，RM资源管理器