分布式事务

CAP理论

一致性/可用性/分区容错性

BASE理论

base是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写。base是对cap中一致性和可用性的权衡的结果

是否真的要分布式事务

在说方案之前，首先要明确是否真的需要分布式事务？上面说过出现分布式事务的两个原因，其中有个原因是因为微服务过多。而微服务过多就会引出分布式事务，这个时候请把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了，千万不要因为追求某些设计，而引入不必要的成本和复杂度。

两阶段提交（2PC） XA Transactions

第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.

第二阶段：事务协调器要求每个数据库提交数据。

三阶段提交（3PC）

在两阶段提交的基础上增加了CanCommit阶段，并引入了超时机制，事务预提交

补偿事务（TCC）

TCC（Try-Confirm-Cancel）

Try阶段：主要是对业务系统做检测及资源预留。

Confirm阶段：确认执行业务操作。

Cancel阶段：取消执行业务操作。

举个例子，假入 Bob 要向 Smith 转账，思路大概是：

我们有一个本地方法，里面依次调用

1、首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。

2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。

3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。

现成tcc框架：

hmily（注解上指定confirmMethod、cancelMethod等）

atomikos

阿里巴巴的FESCAR（GTS开源版本）@GlobalTransactional

FESCAR 中有三大基本组件：

Transaction Coordinator(TC)：维护全局和分支事务的状态，驱动全局事务提交与回滚。

Transaction Manager™：定义全局事务的范围：开始、提交或回滚全局事务。

Resource Manager(RM)：管理分支事务处理的资源，与 TC通信以注册分支事务并报告分支事务的状态，并驱动分支事务提交或回滚。

FESCAR 管理分布式事务的典型生命周期：

1、TM 要求 TC 开始新的全局事务，TC 生成表示全局事务的 XID。

2、XID 通过微服务的调用链传播。

3、RM 在 TC 中将本地事务注册为 XID 的相应全局事务的分支。

4、TM 要求 TC 提交或回滚 XID 的相应全局事务。

5、TC 驱动 XID 的相应全局事务下的所有分支事务，完成分支提交或回滚。