分布式事务核心概念小结

# 写在文章开头

这是一篇关于分布式事务的基本核心概念的介绍，涉及分布式事务基础理论和常见解决方案和一些常见问题的解决思路，希望对你有帮助。

我是 SharkChili ，Java 开发者，Java Guide 开源项目维护者。欢迎关注我的公众号：写代码的SharkChili，也欢迎您了解我的开源项目 mini-redis：https://github.com/shark-ctrl/mini-redis (opens new window)。

# 详解分布式事务基础概念

# 什么是CAP理论，为什么不能同时满足CP或者AP

回答这个问题我们优先需要了解CAP的3个概念:

C(Consistency):一致性,每次读取到的数据都是实时最新的数据。
A(Availability)：可用性,每次发起调用都可以得到非错误的正常响应。
P（Partition tolerance）：分区容错性，即分布式系统遇到某节点或者网络分区故障的时候，系统仍然能够对外提供一致性或者可用性的服务。

回答这个问题，为什么CAP不能同时满足，这里我们给出这样一个场景，有一个订单服务的集群，提供系统订单的业务操作，因为业务体量原因采用分布式集群，各自一份库源，服务之间会不断进行数据的同步：

以这套集群架构为例可以看到，P是必须可以且必须满足的条件，即环境因为节点下线或者网络波动后网络节点分区故障后系统依然可以对外提供服务：

我们可以通过反证法来印证C一致性或者A可用性是否可以同时存在，假设我们的系统是CP即一致性和分区容错性都符合，这意味着即使集群环境因为某个节点因为网络波动后依然可以对外提供正确的服务，但他们必须通过分布式协议将节点间数据同步后保证一致性才能对外提供服务，这意味着服务节点数据没有完全同步期间，系统不可以对外提供服务(因为数据不一致)：

同理假设分布式系统是AP那么，假设集群某节点网络波动通信出现故障，服务依然可以实时的对外提供服务，那么因为节点间没有及时的同步就无法保证一致性，也就收达不到C一致性的要求。

# 什么是分布式BASE理论

BASE是CAP理论的一种延伸，BASE理论也可以按照以下几个概念组合：

B（Basically Available）：基本可用，即不要求分布式场景在出现故障之后，允许损失部分可用性，只要保证分布式系统服务基本核心可用即可。
S(Soft State)：软状态，允许分布式系统执行过程中数据存在中间状态，例如：初始化、处理中、已完成，有了软状态才能保证分布式系统失败后不断重试，保证数据最终处理完成。
E(Eventual Consistency)：最终一致性,即分布式系统所有的副本在一段时间后都会达到一致状态，举个简单例子在传统事务情况下，用户下单的流程是创建订单、用户扣款、库存扣减3个步骤，在传统的强一致性的情况下，这三个步骤在单位时间内用户要么看到没创建订单、没扣款、没扣减库存，要么看到创建订单、用户扣款、库存扣减：

而分布式环境因为事务发布在不同系统之间，为了保证执行性能而牺牲操作的原子性，这意味着操作的过程中可能出现脏读，即软状态，例如创建了订单、扣减了用户余额、但是查看库存还没有完成扣减，但是在过一段时间后，这几个操作都会完成，这就是最终一致性。

# 什么是分布式事务

传统事务即MySQL事务处于单个库源中，通过数据库自带的事务即可保证ACID，当系统库表处于分布式节点的情况下，需要利用XA协议、TCC事务、最大努力通知、可靠性消息队列等方式协同多个节点完成分布式事务ACID。

# 分布式事务的几种方案

# XA协议下的2PC和3PC

解决分布式事务本质上就是要将分布在不同硬件资源上的事务参与者、支持事务的服务器、事务资源管理器以及资源服务器进行统一协调管理。我们先来说说基于XA协议的分布式事务解决方案，整体上是有事务协调者和本地资源管理器构成，对应的实现方式分为2PC和3PC。

我们先来说说2PC解决方案，也就是所谓的2阶段提交，它分为2个阶段：

一阶段询问各个分支事务是否准备好，此时分支事务(假设是MySQL)就会准备好相应的redo和undo日志，然后告知事务协调者准备完成。
二阶段事务协调者会基于各个分支事务准备结果进行进一步全局操作，假设所有分支事务都准备成功那么就通知所有分支事务提交，反之若有单个事务准备失败则通知所有事务回滚。

2PC严格的遵守了事务的ACID的四大原则，同时也相应的导致事务执行期间会出现数据会被锁定(这也就是我们常说的刚性事务)，所以在并发场景之下性能表现会差一些。

同时，2PC在二阶段若因为网络抖动等某些原因，可能会导致某些分支事务无法被提交而导致数据长时间被锁定，导致业务夯住，进而还会导致一些数据不一致的问题：

基于上述的二阶段死锁问题就有了3PC的解决方案，与2PC步骤不同的是它有三阶段，一阶段是预提交阶段，它会先询问各个分支事务是否具备事务提交操作的条件，明确都具备之后通知分支事务进行prepare准备这一步的2PC的一阶段一致，都是准备undo和redo日志，成功后再进入三阶段全局事务提交：

可以看出3PC本质上是想通过一阶段的询问操作视图避免2PC的死锁问题，虽然一定程度上可以避免死锁问题，但在一阶段明确正常后，三阶段还是可以存在commit的失败问题，并且为了保证事务最终一致性各个节点又增加了一次网络IO和系统实现的复杂度，似乎是有点得不偿失。

# AT模式(自动提交模式)

关于AT模式基本概念和实践可以参考笔者这篇文章:https://mp.weixin.qq.com/s/d6NRfpkuu_9hSGNPEKqaRA (opens new window)

# TCC模式

TCC也就是try-confirm-cancel的缩写，是一种业务入侵性较强的解决方案，可以保证资源的隔离，且性能表现较好，我们以一个下单业务来讲解一下TCC的大体执行流程。整体来说用户针对单个商品的下单流程为：

创建订单。
检查用户额度是否足够，若足够则扣款。
扣减库存。

在分布式事务的场景下，3个操作是分布式在不同节点上的，所以为保证数据的最终一致性，执行步骤为：

事务管理器告知每个事务执行try操作，订单服务创建预订单，将状态设置为预下单状态，用户服务锁定部分额度存入冻结资源表，库存服务同理，锁定数量库存到冻结表。
若上述的try服务都执行成功，则将订单设置为已下单，另外两个服务都基冻结数据进行扣减这也就是confirm操作，若单个事务失败则全局回滚，则将冻结表数据清除(也就是cancel操作)，一切回到初始的样子。

需要注意的是因为网络波动的原因，活动管理器对应的confirm或者cancel通知没有收到分支事务的确认操作时可能会重复发送，这也就可能导致confirm或者cancel会重复执行，所以我们的业务上要尽可能保证幂等：

TCC相较于XA来说它只需要保证最终一致性，所以是存在中间状态，不会存在数据锁，所以性能表现会相对出色一些，但是它却存在如下几个问题:

业务侵入性较强，相较于XA这种业务层无感知的实现，TCC很明显会让开发者感觉到二阶段过程，整个分布式事务的数据管理都需要交由开发实现，整体考虑的维度较多，实现相对复杂。
空回滚问题：假设我们try操作因为网络波动导致分支事务延迟执行，而事务管理器却通知我们的事务进行回滚，此时我们的分支事务就回滚不到任何东西，也就收事务空回滚：
空悬挂问题：基于上述场景，此时悬挂的try的操作开始执行，可是业务上我们明明已经回滚，而这份try的数据却落到库中，导致部分数据被锁定，业务上出现不一致问题。

# saga模式

saga：也比较易于理解，就目前seata的官方文档的说法，它的特点是：

是一种长事务，适用于长、多的业务流程。
一种基于补偿实现的事务。
一阶段本地提交、无锁性能表现好。

就目前seata的实现来说，它是一种基于状态机引擎实现，不过整体思路也是大差不差：

顺序执行每个事务，注意这里的每个事务都有相应的补偿方法，一个事务执行完成走到下一个事务。
顺序执行过程中，如果某个事务执行失败，则基于这个事务往回走反向执行补偿方法将数据回滚：

# 本地消息表

本地消息表也是解决分布式事务的一种有效手段，整体思路是通过本地消息表维护其他事务需要消费的信息，通过定时扫描将消息投递到消息队列，让其他事务完成消息消费从而保证业务最终一致性。

这里我们以下单业务为例讲解一下大体流程：

订单服务基于本地数据库原子性将订单信息和消息(状态为待消费)写入到本地数据库中。
业务定时扫表将数据写入消息队列。
库存服务从消息队列中获取消息完成库存扣减。
库存服务通知订单服务扣减完成，消息可以更新为已完成了。

整体来说本地消息表实现比较简单但需要考虑一下问题：

定时扫表的延迟。
本地消息表建议和MQ进行重试次数等工作的协调维护，便于追踪问题。
因为延迟导致消息消费满。
避免消息重复消费，消费者可能需要考虑幂等操作。
消费完成后的通知操作可能会失败，同样可以借助消息队列完成这一点。

# 最大努力通知

最大努力通知模型整体逻辑与前者大体一致，只不过在细节上有所区别：

分支事务-1执行本地事务操作，完成后通过RPC、HTTP、MQ同步或者异步发送消息告知其它事务执行自己的逻辑以保证业务的最终一致性。
对于消息发送这个过程，发送方会尽自己最大的努力去交付消息，但不可避免某些情况下消息可能无法送达。
如果接收方长时间没有收到消息，则接收方可以主动询问发送消息的详情。
基于消息内容，接收方完成本地事务操作，实现业务最终一致性。

与本地消息事务不同的是，本地消息消息需要发送方去保证消息发送的可靠性以保证消费方能够正确消费，以实现业务的最终一致性。

而最大努力通知模型则是要求发送方尽自己的最大的努力去交付(甚至消息是可以重复发送的)，并不能保证消息一定能够送达，所以它允许接收方去主动找发送方查询消息，也就是说消息的可靠性可能依赖于接收方：

由此，最大努力交付模型的场景，需要考虑的问题可能会更多：

消息丢失：最大努力通知模型不保证消息送达，即使发送方发送多次也无法消除该风险。
消息幂等
数据不一致：因为消息通知不可靠或者消息消费失败等情况导致数据不一致。
主动询问等系列操作带来的性能开销
消息表高性能保证：即索引和表结构设计，是否需要结合业务维度进行分库分表等
补偿复杂性：针对接受、发送、消费等多个维度的失败都需要结合问题的场景针对性的措施阻断并完成补偿，这会增加系统的复杂性。
不适合关键业务。

# 基于事务消息的分布式事务

深度解析：基于 RocketMQ 实现分布式事务的技术实践与原理探究:https://mp.weixin.qq.com/s/RMrmrwWuQIrMESLhYGhlRg (opens new window)

# 分布式事务常见问题

# 有了2阶段提交为什么还需要3阶段提交

2PC和3PC在上文中都已经做了详尽的介绍了，我们在这里也针对该问题进行相应的补充，2PC是XA分布式事务中的一个重要解决方案，通过TC一阶段通知各个分支事务做好准备(生成undo.log和redo.log)然后根据各个分支事务的提交情况决定二阶段是全局提交还是回滚，只有明确所有事务预成功后再进行事务提交。

2PC在特定场景下可能无法保证最终一致性，明确一阶段准备成功后某个分支事务没有收到提交通知或者提交失败，所以就有了3PC，3PC本质上就是基于2PC基础上先执行的预提交明确一下各个分支事务是否可以正常执行再决定是否进行后续的分支事务准备和提交工作，由此在一定程度上避免同步阻塞、单点故障、数据不一致等问题。

# 什么是TCC，和2PC有什么区别

关于TCC上文也已经提到过，它是一种相对而言业务侵入性较强的分布式事务解决方案，通过手动编写try-confirm-cancel实现每个事务资源预留、confirm提交、rollback回滚逻辑，通过在try阶段进行资源预留，其他节点同理，只有所有分布式节点的try逻辑都成功之后统一进行confirm操作，如果有一个失败的统一cancel。

相较于XA协议的2PC而言，它有着如下几个不同点：

XA的2PC是强一致性协议，操作期间会持有资源的锁，它可以一定程度上避免脏读问题，TCC是最终一致性协议。
XA的2PC执行期间存在数据锁的情况，而TCC则是通过逻辑层面实现资源预留，也就是所谓的补偿型事务，它不会锁数据，性能表现更加出色。
XA的2PC对于用户而言整个二阶段是无感知的，而TCC可以让开发明确的感受到各个阶段的执行，业务侵入性较强。
在实现层面上，TCC需要用户自行实现资源预留、提交和补偿逻辑相较于2PC实现更复杂，而且在功能层面还需要考虑到空悬挂和空回滚的问题，实现成本相较于2PC更高一些。

# 什么是柔性事务

柔性事务是业内解决分布式事务的常用解决方案，与之相反的就是以MySQL的innodb存储引擎为例的刚性事务，它要求数据实时的ACID，而柔性事务则是基于BASE理论即保证性能只要保证事务最终一致性，对于ACID原则，它也是的支撑程度为：

原子性：遵循。
一致性：为保证性能有些解决方案会做出妥协，例如AT模式，它只能保证最终一致性。
隔离性：分布式事务中间处理过程在安全的情况下允许看到。
持久性：遵循。

# 如何基于本地消息表实现分布式事务

大体步骤为：

执行本地事务。
事务执行成功后创建消息到消息表
其他节点同步轮询消息表消费消息
失败后不断处理
完成后更新消息状态。

# 什么是最大努力通知？

与本地消息表不同，最大努力通知不保证消息交付到消费者手里，完成本地事务后会创建消息到消息表中，然后通过接口、消息队列等形式通知消费者消费，但是不保证消费者可以准确收到消息，需要消费者主动去确认，这就可能考虑到以下几个问题：

幂等
一致性
可靠性

# 最大努力通知、事务消息、本地消息表三者区别

最大努力通知它所对应的消息发送方放不保证消息可靠性，允许接收方进行主动会查等操作，在发送方层面实现比较简单，也就是消息没有成功发送的地方做个重试机制就好了，总的来说它是一种最终一致性的解决方案，仍然是存在数据不一致和消息重复消费的问题。

再来说说事务消息，它要求发送方保证消息发送的可靠性，但是这套方案实现上业务的侵入性比较强，它要求我们的发送方需要做到如下两点：

发送的消息必须是half消息，即必须MQ回复ack之后才能才能消息发送成功。
在接收方明确ACK后，发送方必须执行本地事务并提交执行成功发送消息的通知，如果接收方长时间没有收到该确认信号需要发送方提供一个回查接口询问该情况。
接收方需要保证消息消费的幂等判断以避免消息重复消费。

总的来说，MQ这套事务消息方案业务入侵性较强，实现相对复杂一些，但是整体可靠性相较于前者会高一些。

本地消息表相较于上述来说做了较好的折中，业务入侵性不算很高，做好消息表设计然后定时扫表准确投递到MQ中，然后提供一个消费者完成消费后的通知接口即可。它也是同样要求发送方保证消息可靠性，但针对消息表的维度我们还是需要做好表结构设计和索引调优，并要的情况下需要考虑一下分库分表，所以在明确MQ不支持事务消息的情况下，我们可以考虑用这套方案。

# TCC的空回滚和悬挂问题和解决方案

空悬挂和空回滚问题上文中都已经做了详细的介绍，大体来说就是全局事务协调者执行confirm/cancel操作时没有感知到try操作的状态，导致时许错误出现的不一致问题，对应的我们可以在这几个阶段执行期间通过一张表(如下tcc_transaction_status)维护各个分布式事务的状态。

CREATE TABLE tcc_transaction_status (
tx_id varchar(128) NOT NULL COMMENT '事务id', 
state int(1) DEFAULT NULL COMMENT'事务状态，0:try，1:confirm，2:cancel' ,
PRIMARY KEY(tx_id) u
)