一、事务（Transaction）：

是指作为单个逻辑工作单元执行的一系列操作，要么完全地执行，要么完全地不执行。它具有原子性（Atomicity），一致性(Consistency)，隔离性(Isolation)和持久性(Durability)，简称ACID。

二、分布式事务（Distributed Transaction）：

在分布式场景下，事务的参与者，资源和事务管理器位于不同的节点上，一个事务由多个节点或者多个应用的一系列操作组成，分布式事务要保证这些操作要么全部成功，要么全部失败，这样保证数据的一致性。

2.1 分布式事务理论CAP

CAP理论是由Eric Brewer教授提出的猜想，Lynch与其他人证明了Eric Brewer的猜想，从而把CAP上升为一个定理，即在一个分布式系统中，一致性(Consistency)，可用性(Availability)和分区容错性(Partition tolerance)，无法设计一种分布式协议，使得同时完全具备CAP三个属性，目前已经被行业奉为圭臬。

a.如果放弃P，选择CA，如果这时候有请求，为了保证C，只能拒绝请求，这又违背了A，故分布式场景不太可能选择CA架构，即不可能放弃分区容错性；

b.放弃A，选择CP，追求一致性和分区容错性，Zookeeper就是一个CP的架构；

c.放弃C，选择AP，放弃强一致性，追求容错性和可用性，实现最终一致性，后面的BASE理论就是该AP架构的扩展。

2.2 BASE理论

BASE理论即基本可用(Basically Available)、软状态(Soft state)和 最终一致性 (Eventually consistent)，通过牺牲强一致性来获得可用性，允许数据在一段时间内是不一致的，但是最终达到一致性状态。

三、常用分布式事务解决方案

3.1 XA协议，也即是2PC两阶段提交

XA协议通过事务中间件与DB之间使用XA接口规范，采用两阶段提交的方式实现，具体过程如下：

1.第一阶段：预提交阶段

事务管理器要求所有参与者预提交此事务操作，并
将本事务能否commit的信息反馈给事务管理者；

2.第二阶段：执行阶段

事务管理器根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上commit或者rollback。

说明：

XA协议简单，成本低，并尽量保证了数据的强一致性，目前主流数据库都已经支持XA协议，但是事务管理器有数据单点问题，而且是阻塞提交（影响性能，对高并发场景支持有限）。另外，XA协议的数据也存在数据不一致的情况，如第二阶段，有的参与者没有收到commit或者rollback，就会导致数据不一致性。

3.2 三阶段提交

由CanCommit、PreCommit和DoCommit三个阶段组成的事务处理协议

3.3 TCC(Try-Confirm-Cancel)

TCC是XA方案的改进，将两个阶段改成了Try，Confirm，Cancel三个操作，采用了补偿机制，其核心思想，针对每个操作，都要注册一个与其对应的Confirm和Cancel操作。具体如下（假如A向B转账）：

a.try阶段：

尝试执行，完成所有业务和资源检查，预留必需业务资源。此时事务管理器锁定A和B的账户；

b.Confirm阶段：

如果try阶段执行成功，Confirm阶段不再做业务检查，直接使用try预留的业务资源，执行确认commit，由于Confirm阶段有进行重试，因此要求Confirm操作具有幂等性。执行A转账给B，然后释放锁

c.Cancel阶段：

Cancel阶段：取消执行，释放 Try 阶段预留的业务资源，Cancel 操作满足幂等性。如果Confirm失败，则调用注册的Cancel方法

说明：

TCC解决了XA的事务管理器单点的问题，引入了集群，牺牲了一部分数据一致性。另外TCC代码需要实现try、confirm、cancel三个操作，使用成本高，要求confirm和cancel接口必须具有幂等性，不具有轻量化的特征。

3.4 基于消息的最终一致性方案

消息可以是本地消息，也可以是MQ消息，主要是将本地操作和消息发送二者放入一个事务中。该方案将分布式事务拆分成多个本地事务，当一个本地事务commit后，然后通过消息通知下一个本地事务。当有一个本地事务失败后，需要回滚。

a.本地消息方案：

事务开始：
    update db by id;
    send message to db;
事务结束：

b.MQ消息方案：

事务开始：
    send prepare message to MQ;
    receive prepare message success;
    update db by id; // 本地事务
    send message to MQ;
    call back;
事务结束：

该方案需要MQ支持，目前Kafka,RocketMQ（旧版本支持），RabbitMQ都不支持事务了。

说明：

基于消息的最终一致性方案要求需要消息的保存，事务的回滚非常复杂，一般通过自动或者来人工来发起重试，要求本地事务具有幂等性。因此这种方案适合一致性要求不高，而且事务失败率极低的场景。

3.5 阿里Seata全局事务服务

Seata（2016年之前叫TXC，后改为GTS(Global Transaction Service)，2019年改名Fescar，2019年4月起改名Seata，主要是因为实现原理和开源策略的调整）由阿里巴巴开发，目前已经在阿里巴巴内部成功实践。具有简单，性能好，支持dubbo，spring cloud，解决了事务管理器单点的问题

3.6 Sagas 事务模型

Sagas主要解决长时间运行的事务，针对分布式系统中的业务事务问题，其核心思想是将分布式的长事务拆分成多个本地事务，然后Sagas流程引擎负责管理，如果整个流程正常结束，那么分布式事务完成，如果流程中有失败，那么Sagas流程引擎就会以相反的顺序调用补偿操作，实现分布式事务回滚。

备注：可能不太准确，后续继续优化

未完待续......