> For the complete documentation index, see [llms.txt](https://hswsp.gitbook.io/algorithm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hswsp.gitbook.io/algorithm/parallelism/fen-bu-shi-shi-wu-xiang-jie.md).
# 分布式事务详解
这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。
相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。
## 什么是事务
介绍分布式事务之前，先介绍什么是事务。
### **事务的具体定义**
事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。
简单地说，事务提供一种“ **要么什么都不做，要么做全套（All or Nothing）**”机制。
### **数据库事务的 ACID 属性**
事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。
ACID 指数据库事务正确执行的四个基本特性的缩写，包含：
**原子性（Atomicity）**
整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。
事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。
例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤：
* 从 A 账户取 100 元。
* 存入 100 元至 B 账户。
这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了 100 元。
**一致性（Consistency）**
在事务开始之前和事务结束以后，数据库数据的一致性约束没有被破坏。
例如：现有完整性约束 A+B=100，如果一个事务改变了 A，那么必须得改变 B，使得事务结束后依然满足 A+B=100，否则事务失败。
**隔离性（Isolation）**
数据库允许多个并发事务同时对数据进行读写和修改的能力，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。
隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
例如：现有有个交易是从 A 账户转 100 元至 B 账户，在这个交易事务还未完成的情况下，如果此时 B 查询自己的账户，是看不到新增加的 100 元的。
**持久性（Durability）**
事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。
简单而言，ACID 是从不同维度描述事务的特性：
* 原子性：事务操作的整体性。
* 一致性：事务操作下数据的正确性。
* 隔离性：事务并发操作下数据的正确性。
* 持久性：事务对数据修改的可靠性。
一个支持事务（Transaction）的数据库，需要具有这 4 种特性，否则在事务过程当中无法保证数据的正确性，处理结果极可能达不到请求方的要求。
### **什么时候使用数据库事务**
在介绍完事务基本概念之后，什么时候该使用数据库事务？
简单而言，就是业务上有一组数据操作，需要如果其中有任何一个操作执行失败，整组操作全部不执行并恢复到未执行状态，要么全部成功，要么全部失败。
在使用数据库事务时需要注意，尽可能短的保持事务，修改多个不同表的数据的冗长事务会严重妨碍系统中的所有其他用户，这很有可能导致一些性能问题。
## 什么是分布式事务
介绍完事务相关基本概念之后，下面介绍分布式事务。
### **分布式产生背景与概念**
随着互联网快速发展，微服务，SOA 等服务架构模式正在被大规模的使用，现在分布式系统一般由多个独立的子系统组成，多个子系统通过网络通信互相协作配合完成各个功能。
有很多用例会跨多个子系统才能完成，比较典型的是电子商务网站的下单支付流程，至少会涉及交易系统和支付系统。
而且这个过程中会涉及到事务的概念，即保证交易系统和支付系统的数据一致性，此处我们称这种跨系统的事务为分布式事务。
具体一点而言，分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
举个互联网常用的交易业务为例：
上图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库。
在交易系统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服务，创建订单记录。
可以看到，如果多个数据库之间的数据更新没有保证事务，将会导致出现子系统数据不一致，业务出现问题。
### **分布式事务的难点**
**事务的原子性**
事务操作跨不同节点，当多个节点某一节点操作失败时，需要保证多节点操作的要么什么都不做，要么做全套（All or Nothing）的原子性。
**事务的一致性**
当发生网络传输故障或者节点故障，节点间数据复制通道中断，在进行事务操作时需要保证数据一致性，保证事务的任何操作都不会使得数据违反数据库定义的约束、触发器等规则。
**事务的隔离性**
事务隔离性的本质就是如何正确处理多个并发事务的读写冲突和写写冲突，因为在分布式事务控制中，可能会出现提交不同步的现象，这个时候就有可能出现“部分已经提交”的事务。
此时并发应用访问数据如果没有加以控制，有可能出现“脏读”问题。
分布式系统的一致性
前面介绍到的分布式事务的难点涉及的问题，最终影响是导致数据出现不一致，下面对分布式系统的一致性问题进行理论分析，后面将基于这些理论进行分布式方案的介绍。
## **可用性和一致性的冲突：CAP 理论**
CAP 定理又被称作布鲁尔定理，是加州大学的计算机科学家布鲁尔在 2000 年提出的一个猜想。
2002 年，麻省理工学院的赛斯·吉尔伯特和南希·林奇发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。
布鲁尔在提出 CAP 猜想时并没有具体定义 Consistency、Availability、Partition Tolerance 这 3 个词的含义，不同资料的具体定义也有差别。
为了更好地解释，下面选择Robert Greiner的文章《CAP Theorem》作为参考基础：
*
*
### **CAP 理论的定义**
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
Consistency、Availability、Partition Tolerance 具体解释如下：
**C - Consistency 一致性：**A read is guaranteed to return the most recent write for a given client.
对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
这里并不是强调同一时刻拥有相同的数据，对于系统执行事务来说，在事务执行过程中，系统其实处于一个不一致的状态，不同的节点的数据并不完全一致。
一致性强调客户端读操作能够获取最新的写操作结果，是因为事务在执行过程中，客户端是无法读取到未提交的数据的。
只有等到事务提交后，客户端才能读取到事务写入的数据，而如果事务失败则会进行回滚，客户端也不会读取到事务中间写入的数据。
**A - Availability 可用性：**A non-failing node will return a reasonable response within a reasonable amount of time (no error or timeout).
非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。
这里强调的是合理的响应，不能超时，不能出错。注意并没有说“正确”的结果，例如，应该返回 100 但实际上返回了 90，肯定是不正确的结果，但可以是一个合理的结果。
**P - Partition Tolerance 分区容忍性：**The system will continue to function when network partitions occur.
当出现网络分区后，系统能够继续“履行职责”。
这里网络分区是指：一个分布式系统里面，节点组成的网络本来应该是连通的。
然而可能因为一些故障（节点间网络连接断开、节点宕机），使得有些节点之间不连通了，整个网络就分成了几块区域，数据就散布在了这些不连通的区域中。
### **一致性、可用性、分区容忍性的选择**
虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。
如果我们选择了 CA（一致性 + 可用性） 而放弃了 P（分区容忍性），那么当发生分区现象时，为了保证 C（一致性），系统需要禁止写入。
当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A(可用性) 冲突了，因为 A（可用性）要求返回 no error 和 no timeout。
因此，分布式系统理论上不可能选择 CA （一致性 + 可用性）架构，只能选择 CP（一致性 + 分区容忍性） 或者 AP （可用性 + 分区容忍性）架构，在一致性和可用性做折中选择。
**①CP - Consistency + Partition Tolerance （一致性 + 分区容忍性）**
如上图所示，因为 Node1 节点和 Node2 节点连接中断导致分区现象，Node1 节点的数据已经更新到 y，但是 Node1 和 Node2 之间的复制通道中断，数据 y 无法同步到 Node2，Node2 节点上的数据还是旧数据 x。
这时客户端 C 访问 Node2 时，Node2 需要返回 error，提示客户端 “系统现在发生了错误”，这种处理方式违背了可用性（Availability）的要求，因此 CAP 三者只能满足 CP。
**②AP - Availability + Partition Tolerance （可用性 + 分区容忍性）**
同样是 Node2 节点上的数据还是旧数据 x，这时客户端 C 访问 Node2 时，Node2 将当前自己拥有的数据 x 返回给客户端了。
而实际上当前最新的数据已经是 y 了，这就不满足一致性（Consistency）的要求了，因此 CAP 三者只能满足 AP。
**注意：**这里 Node2 节点返回 x，虽然不是一个“正确”的结果，但是一个“合理”的结果，因为 x 是旧的数据，并不是一个错乱的值，只是不是最新的数据。
值得补充的是，CAP 理论告诉我们分布式系统只能选择 AP 或者 CP，但实际上并不是说整个系统只能选择 AP 或者 CP。
在 CAP 理论落地实践时，我们需要将系统内的数据按照不同的应用场景和要求进行分类，每类数据选择不同的策略（CP 还是 AP），而不是直接限定整个系统所有数据都是同一策略。
另外，只能选择 CP 或者 AP 是指系统发生分区现象时无法同时保证 C（一致性）和 A（可用性），但不是意味着什么都不做，当分区故障解决后，系统还是要保持保证 CA。
### **CAP 理论的延伸：BASE 理论**
BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。
它的核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。
**BA - Basically Available 基本可用**
分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。
这里的关键词是“部分”和“核心”，实际实践上，哪些是核心需要根据具体业务来权衡。
例如登录功能相对注册功能更加核心，注册不了最多影响流失一部分用户，如果用户已经注册但无法登录，那就意味着用户无法使用系统，造成的影响范围更大。
**S - Soft State 软状态**
允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
**E - Eventual Consistency 最终一致性**
系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
这里的关键词是“一定时间” 和 “最终”，“一定时间”和数据的特性是强关联的，不同业务不同数据能够容忍的不一致时间是不同的。
例如支付类业务是要求秒级别内达到一致，因为用户时时关注；用户发的最新微博，可以容忍 30 分钟内达到一致的状态，因为用户短时间看不到明星发的微博是无感知的。
而“最终”的含义就是不管多长时间，最终还是要达到一致性的状态。
**BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充：**CAP 理论是忽略延时的，而实际应用中延时是无法避免的。
这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。
因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。
AP 方案中牺牲一致性只是指发生分区故障期间，而不是永远放弃一致性。
这一点其实就是 BASE 理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。
## **数据一致性模型**
前面介绍的 BASE 模型提过“强一致性”和“最终一致性”，下面对这些一致性模型展开介绍。
分布式系统通过复制数据来提高系统的可靠性和容错性，并且将数据的不同的副本存放在不同的机器上，由于维护数据副本的一致性代价很高，因此许多系统采用弱一致性来提高性能。
下面介绍常见的一致性模型：
* 强一致性：要求无论更新操作是在哪个数据副本上执行，之后所有的读操作都要能获得最新的数据。 对于单副本数据来说，读写操作是在同一数据上执行的，容易保证强一致性。对多副本数据来说，则需要使用分布式事务协议。
* 弱一致性：在这种一致性下，用户读到某一操作对系统特定数据的更新需要一段时间，我们将这段时间称为"不一致性窗口"。
* 最终一致性：是弱一致性的一种特例，在这种一致性下系统保证用户最终能够读取到某操作对系统特定数据的更新（读取操作之前没有该数据的其他更新操作）。 "不一致性窗口"的大小依赖于交互延迟、系统的负载，以及数据的副本数等。
系统选择哪种一致性模型取决于应用对一致性的需求，所选取的一致性模型还会影响到系统如何处理用户的请求以及对副本维护技术的选择等。
后面将基于上面介绍的一致性模型分别介绍分布式事务的解决方案。
## **柔性事务**
### **柔性事务的概念**
在电商等互联网场景下，传统的事务在数据库性能和处理能力上都暴露出了瓶颈。在分布式领域基于 CAP 理论以及 BASE 理论，有人就提出了柔性事务的概念。
基于 BASE 理论的设计思想，柔性事务下，在不影响系统整体可用性的情况下(Basically Available 基本可用)，允许系统存在数据不一致的中间状态(Soft State 软状态)，在经过数据同步的延时之后，最终数据能够达到一致。
并不是完全放弃了 ACID，而是通过放宽一致性要求，借助本地事务来实现最终分布式事务一致性的同时也保证系统的吞吐。
### **实现柔性事务的一些特性**
下面介绍的是实现柔性事务的一些常见特性，这些特性在具体的方案中不一定都要满足，因为不同的方案要求不一样。
**可见性(对外可查询) ：**在分布式事务执行过程中，如果某一个步骤执行出错，就需要明确的知道其他几个操作的处理情况，这就需要其他的服务都能够提供查询接口，保证可以通过查询来判断操作的处理情况。
为了**保证操作的可查询，需要对于每一个服务的每一次调用都有一个全局唯一的标识**，可以是业务单据号（如订单号）、也可以是系统分配的操作流水号（如支付记录流水号）。除此之外，操作的时间信息也要有完整的记录。
**操作幂等性：**幂等性，其实是一个数学概念。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。
幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。也就是说，同一个方法，使用同样的参数，调用多次产生的业务结果与调用一次产生的业务结果相同。
**之所以需要操作幂等性，是因为为了保证数据的最终一致性，很多事务协议都会有很多重试的操作，如果一个方法不保证幂等，那么将无法被重试。**
幂等操作的实现方式有多种，如在系统中缓存所有的请求与处理结果、检测到重复操作后，直接返回上一次的处理结果等。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://hswsp.gitbook.io/algorithm/parallelism/fen-bu-shi-shi-wu-xiang-jie.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.