分布式事务

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 的相应全局事务下的所有分支事务,完成分支提交或回滚。