一图看懂整个分布式事务

三阶段提交是为解决两阶段提交协议的缺点而设计的。

概念

引入超时机制 - 同时在协调者和参与者中都引入超时机制。

在第一阶段和第二阶段中插入一个准备阶段，保证了在最后提交阶段之前各参与节点的状态是一致的

与两阶段区别

协调者事务询问，并开始等待

正常情况下，如果其自身认为可以顺利执行事务，则返回Yes响应，并进入预备状态；否则反馈No；

第一阶段：CanCommit

协调者向所有参与者节点发出 preCommit 的请求，并进入 prepared 状态

参与者会执行事务操作，对应 2PC 准备阶段中的 “执行事务”，也会 Undo 和 Redo 信息记录到事务日志中

如果参与者成功执行了事务，就反馈 ACK 响应，同时等待指令：提交（commit） 或终止（abort）

成功

协调者向所有参与者节点发出 abort 请求 。

参与者如果收到 abort 请求或者超时了，都会中断事务。

失败

第二阶段：PreCommit

协调者接收到各参与者发送的ACK响应，那么他将从预提交状态进入到提交状态。并向所有参与者发送 doCommit 请求

参与者接收到 doCommit 请求之后，执行正式的事务提交。并在完成事务提交之后释放所有事务资源。

事务提交完之后，向协调者发送 ACK 响应。

协调者接收到所有参与者的 ACK 响应之后，完成事务。

协调者向所有参与者发送 abort 请求。

参与者接收到 abort 请求之后，利用其在阶段二记录的 undo 信息来执行事务的回滚操作，并在完成回滚之后释放所有的事务资源。

参与者完成事务回滚之后，向协调者发送 ACK 消息。

协调者接收到参与者反馈的 ACK 消息之后，完成事务的中断。

第三阶段：Do Commit

主要解决的单点故障问题，并减少了阻塞的时间

优点

如有参与者节点出现了崩溃等情况而导致协调者始终无法获取所有参与者的响应信息，这时协调者将只能依赖协调者自身的超时机制来生效

缺点

优缺点

3PC

TCC事务机制相对于传统事务机制（X/Open XA），其特征在于它不依赖资源管理器(RM)对XA的支持，而是通过对（由业务系统提供的）业务逻辑的调度来实现分布式事务。

尝试执行业务；

完成所有业务检查（一致性）；

预留必须业务资源（准隔离性）；

初步操作 Try

确认执行业务；

真正执行业务，不作任何业务检查；

只使用Try阶段预留的业务资源；

Confirm操作满足幂等性；

确认操作 Confirm

取消执行业务；

释放Try阶段预留的业务资源；

Cancel操作满足幂等性。

取消操作 Cancel

TCC实际上把数据库层的二阶段提交上提到了应用层来实现，对于数据库来说是一阶段提交

规避了数据库层的2PC性能低下问题

TCC的Try、Confirm和Cancel操作功能需业务提供，对业务的侵入强， 开发成本高。

TCC

简单/松耦合

好处

不好理解/多了之后乱/会产生循环依赖关系/紧耦合风险等

协同式

编排式

协调方式

客户通过补偿进行回滚的事务

可补偿性事务

关键性事务

可重复性事务

事务分级

语义锁

重读值

隔离策略

缺乏隔离的问题

Saga

出自一位 Google 大神之口。Paxos 也是出名的 晦涩难懂，推理过程极其复杂。

一致性算法Paxos

这个过程如同选举一样，参选者 需要说服 大多数选民 (服务器) 投票给他，一旦选定后就跟随其操作。

Leader（领袖）Follower（群众）Candidate（候选人）

一致性协议Raft

对比

延伸

C（一致性）

P（分区容错性）

A（可用性）

CAP

正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果

1. 响应时间上的损失

在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

2. 功能上的损失

基本可用（Basically Available）

相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”，我们可以把符合传统的ACID叫做刚性事务。

软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

软状态（Soft State）

定义：数据的最终一致有个时间期限。在期限过后，应当保证所有副本保持数据一致性，从而达到数据的最终一致性。

如果节点A在更新完某个数据后通知了节点B，那么节点B之后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制。

因果一致性（Causal consistency）

节点A更新一个数据后，它自身总是能访问到自身更新过的最新值，而不会看到旧值。其实也算一种因果一致性。

读己之所写（Read your writes）

系统能保证在同一个有效的会话中实现 “读己之所写” 的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

会话一致性（Session consistency）

如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

单调读一致性（Monotonic read consistency）

一个系统要能够保证来自同一个节点的写操作被顺序的执行。

单调写一致性（Monotonic write consistency）

分类

最终一致性（Eventually Consistent）

BASE

最大努力交付（best-effort delivery）

XA是X/Open CAE Specification (Distributed Transaction Processing)模型

应用程序（ AP ）

事务管理器（ TM ）：交易中间件等

资源管理器（ RM ）：关系型数据库等 

通信资源管理器（ CRM ）：消息中间件等 

组件

性能问题比较严重（阻塞性协议，增加响应时间、锁时间、死锁）

数据库支持完善度（MySQL 5.7之前都有缺陷）；

协调者依赖独立的J2EE中间件（早期重量级Weblogic、Jboss、后期轻量级Atomikos、Narayana和Bitronix）；

并不是所有资源都支持XA协议；

大厂懂所以不使用，小公司不懂所以不敢用。

现状

XA

主程序负责一次性调用多方的提交操作， 如果发生错误则调用多方的回滚操作

1PC

每个参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报，决定各参与者是否要提交操作还是中止操作。

参与者执行事务

参与者反馈事务询问的响应

第一阶段：准备阶段（投票阶段）

协调者向所有参与者发出commit请求

参与者节点正式完成操作，并释放在整个事务期间内占用的资源

参与者节点向协调者节点发送\"完成\"消息

协调者节点收到所有参与者节点反馈的\"完成\"消息后，完成事务

协调者节点向所有参与者节点发出\"回滚操作\"的请求

参与者节点利用之前写入的Undo信息执行回滚，并释放在整个事务期间内占用的资源

参与者节点向协调者节点发送\"回滚完成\"消息

协调者节点收到所有参与者节点反馈的\"回滚完成\"消息后，取消事务

第二阶段：提交阶段（执行阶段）

原理简单，实现方便

二阶段提交算法的最大缺点就在于它的执行过程中间，节点都处于阻塞状态

这是另外一个重要的优化： “最末参与者优化”（Last Participant Optimization，术语来自支付宝），即允许两阶段提交协议中有一个参与者不实现“准备”操作，在其余参与者都prepare ok的情况下，直接提交自己的分式事务。

LPO

2PC

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。TXC（Taobao Transaction Constructor，阿里于2014开始着手解决分布式事务的内部框架）-》GTX（Global Transaction Service，阿里于2016年将TXC发布于云服务并且改名为GTX）-》Fescar（阿里于2019将GTS开源并改名为Fescar）-》Seata（Simple Extensible Autonomous Transaction Architecture，阿里将蚂蚁金服框架DTX与Fescar结合并且改名为Seata）

应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性；

将分布式事务中TC（事务协调者）独立部署，负责事务的注册、回滚；

通过全局锁实现了写隔离与读隔离， 没有了脏读、幻读的问题

Seata的引入全局锁会额外增加死锁的风险，但如果实现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延长了对数据库锁的占有时间。

死锁问题

全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点数据，这个问题会更加严重。

热点数据

为了进行自动补偿，需要对所有交易生成前后镜像并持久化， 并同步undo log生成记录

性能损耗

GTS（Global Transaction Service 全局事务服务）是阿里云上的分布事务中间件产品，用于实现分布式环境下特别是微服务架构下的高性能事务一致性。

简单来讲，Seata 项目 2019 年之初的创建是 GTS 的开源版本，经过一年的演进，GTS 商业版本开始全面提供对 Seata 的支持。

GTS

2014 年，阿里巴巴中间件团队发布分布式事务中间件产品 TXC（Taobao Transaction Constructor），为集团内部应用提供服务。2016 年，TXC 经过产品化改造，以 GTS 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。2019 年，阿里巴巴中间件团队基于 TXC 和 GTS 的技术积累，发起了开源项目 Seata（曾用名 Fescar），和社区一起建设这个分布式事务解决方案。开源项目 Seata 的基础是基于 GTS 架构定义的分布式事务框架以及 GTS 独创的的 AT（Automatic Transaction）模式。Seata 项目经过近一年的发展，收获包括蚂蚁金服分布式事务领域核心技术合作，以及开源社区的大力投入，加入 TCC 和 Saga 模式支持，于 2019 年底发布 GA 版本。2020 年 2 月，基于 Seata 项目 GA 后的版本，GTS 实现与 Seata 的协议兼容，支持使用 Seata 的应用无缝迁移到云上基于 GTS 提供的服务来高效运行。

历史

Seata架构

一图看懂整个分布式事务