Spring Cloud part26—认识和理解分布式下的事务

理解分布式事务

分布式事务了解吗？你们是如何解决分布式事务问题的？

带着这个疑问

这玩意容易越学越忘本

回顾事务

事务大家应该还记得，是操作数据库中某个数据项的一个程序执行单元，事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。

事务的四个特征再回顾一下：

Atomic原子性：事务必须是一个原子的操作序列单元，事务中包含的各项操作在一次执行过程中，要么全部执行成功，要么全部不执行，任何一项失败，整个事务回滚，只有全部都执行成功，整个事务才算成功。
Consistency一致性：事务的执行不能破坏数据库数据的完整性和一致性，事务在执行之前和之后，数据库都必须处于一致性状态。
Isolation隔离性：在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。即不同的事务并发操纵相同的数据时，每个事务都有各自完整的数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的各个事务之间不能相互干扰
- 读未提交
  - 允许读取尚未提交的数据变更。
  - 这是最低的隔离级别，它可能导致脏读、不可重复读和幻读。
  - 在这个级别，一个事务可以读取到另一个尚未提交事务的修改，这可能导致数据的不一致性。
- 读已提交
  - 只允许读取并发事务已经提交的数据。
  - 这个级别可以防止脏读，但仍可能导致不可重复读和幻读。
  - 在这个级别，每个事务只能看到它开始时的数据状态以及它提交时其他事务所做的提交。
- 可重复读
  - 这是MySQL的默认隔离级别。
  - 它确保在同一事务中多次读取同一数据时，看到的是相同的数据版本，即使其他事务在此期间修改了这些数据。
  - 尽管可以避免脏读和不可重复读，但在这个级别下仍可能出现幻读（即在一个事务中，两次相同的查询可能会返回不同的结果集，因为其他事务在此期间插入了新的记录）。
- 串行化
  - 这是最高的隔离级别。
  - 它通过强制事务串行执行来避免脏读、不可重复读和幻读。
  - 在这个级别，每个事务在执行时都会完全锁定它所访问的数据，从而确保数据的一致性。但这也可能导致性能下降，因为并发事务必须等待其他事务完成才能执行。
Durability持久性：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中对应数据的状态变更就应该是永久性的。

单机下事务的实现基础

在单机数据库（如 MySQL 单节点）中，事务依赖以下机制保证 ACID：

日志机制：通过 redo log（保证持久性）和 undo log（保证原子性和回滚）记录数据变更。
锁机制：通过行锁、表锁等控制并发（如 InnoDB 的行级锁）。
MVCC（多版本并发控制）：通过数据多版本实现高并发下的隔离性（如 MySQL 可重复读级别依赖 MVCC）。

并发下依旧存在的三大问题：脏读、不可重复读和幻读

脏读（Dirty Read）特点：一个事务读取到另一个尚未提交事务的修改。

理解：读到其他事务没有提交的数据，注意，这数据还没有被其他事务提交，彻底的脏数据。

隔离性：当前事务和其他事务没有做任何隔离。

不可重复读（Non-repeatable Read）：在同一个事务内，多次读取同一数据返回的结果有所不同。

理解：在事务A中先后两次读取同一个数据，两次读取的结果不一样，这种现象称为不可重复读。记录里边的数据变了，但是，读到的是其他事务已经提交的数据。其他事务没有提交的数据，还是被隔离了

隔离性：隔离性稍微好点，其他事务未提交的修改数据被隔离了。没有隔离其他事务的修改操作、插入或删除操作，数据值的有可能变化，数据记录的数量有可能变化。

幻读（Phantom Read）：一个事务在执行两次相同的查询时，因为另一个并发事务的插入或删除操作，导致两次查询返回的结果集不同。

理解：幻读是结果集的层面发生了变化，数据记录的数量变了，没有隔离其他事务的插入或删除操作。在事务A中按照某个条件先后两次查询数据库，两次查询结果的条数不同，这种现象称为幻读。

隔离性：隔离性更好点，其他事务未提交的修改数据被隔离了。没有隔离其他事务的插入或删除操作，数据记录的数量有可能变化。

隔离级别并发事务三大问题之间的关系如下

分布式下事务的新问题

当本地事务要扩展到分布式时，它的复杂性进一步增加了。

数据被分片存储在多个节点（或多个数据库），一个业务操作可能涉及多个节点的修改（如跨库转账、订单创建同时库存扣减）

分布式系统会把一个应用系统拆分为可独立部署的多个服务，因此需要服务与服务之间远程协作才能完成事务操作，这种分布式系统环境下由不同的服务之间通过网络远程协作完成事务称之为分布式事务。

本地事务依赖数据库本身提供的事务特性来实现，本地事务这样进行一个事务

begin transaction；
//1.本地数据库操作：张三减少金额
//2.本地数据库操作：李四增加金额
commit transation;

但是在分布式环境下，会变成下边这样：

begin transaction；
//1.本地数据库操作：张三减少金额
//2.远程调用：让李四增加金额
commit transation;

假如出现了问题，当远程调用让李四增加金额成功了，由于网络问题远程调用并没有返回，此时本地事务提交失败就回滚了张三减少金额的操作，此时张三和李四的数据就不一致了。

所以，分布式的情况下，会出现这样的问题：

网络不可靠性：通信延迟与故障
节点状态不一致：单机事务中，节点可通过本地日志掌握全局状态；但分布式系统中，各节点仅知本地状态，缺乏全局视角。
隔离性难以保证：多节点并发操作时，隔离性控制变得复杂，并发冲突加剧
- 跨节点的锁机制难以协调，如节点 A 持有锁，节点 B 等待锁时超时。
- 分布式环境下的 “幻读” 更难处理，如两个事务同时跨节点查询并修改，导致结果不一致。

因此在分布式架构的基础上，传统数据库事务就无法使用了，张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。

典型的分布式事务场景

所以，分布式事务最典型的场景就是微服务之间通过远程调用完成事务操作。也就是，跨JVM进程产生分布式事务。

而单体系统访问多个数据库实例时候，也会产生分布式事务，假如用户信息和订单信息分别在两个MySQL实例存储，用户管理系统删除用户信息，需要分别删除用户信息及用户的订单信息，由于数据分布在不同的数据实例，需要通过不同的数据库链接去操作数据，此时产生分布式事务。也就是，跨数据库实例产生分布式事务。

而多服务访问同一个数据库实例，也就是订单微服务和库存微服务即使访问同一个数据库也会产生分布式事务，原因就是跨JVM进程，两个微服务持有了不同的数据库链接进行数据库操作，此时产生分布式事务。

如果一个库数据量比较大或者预期未来的数据量比较大，都会进行水平拆分，也就是分库分表。

对于分库分表的情况，一般开发人员都会使用一些数据库中间件来降低sql操作的复杂性。单库情况下，可以保证事务的一致性。

但是由于现在进行了分库分表，开发人员希望将1号记录插入分库1，2号记录插入分库2。所以数据库中间件要将其改写为2条sql，分别插入两个不同的分库，此时要保证两个库要不都成功，要不都失败，因此基本上所有的数据库中间件都面临着分布式事务的问题。

困难

不仅上面说的如此，分布式还涉及到存储端的多样性，本地事务的情况下，所有数据都会落到同一个DB中，但是，在分布式的情况下，就会出现数据可能要落到多个DB，或者还会落到Redis，落到MQ等中。

本地事务的情况下，通常所有事务相关的业务操作，会被我们封装到一个Service方法中。

而在分布式的情况下，请求链路被延展，拉长，一个操作会被拆分成多个服务，它们呈现线状或网状，依靠网络通信构建成一个整体。在这种情况下，事务无疑变得更复杂。

基于上述两个复杂性和上面说的各种情况，期望有一个统一的分布式事务方案，能够像本地事务一样，以几乎无侵入的方式，满足各种存储介质，各种复杂链路，是不现实的

所以，一般情况下，在分布式下，事务会被拆分解决，并根据不同的情况，采用不同的解决方案。

什么是分布式事务？

分布式事务是指事务操作涉及多个分布式节点（如不同数据库、不同服务的存储），需要保证这些跨节点的操作要么全部成功，要么全部失败，最终实现数据一致性的特殊事务。

对于分布式系统而言，需要保证分布式系统中的数据一致性，保证数据在子系统中始终保持一致，避免业务出现问题。分布式系统中对数要么一起成功，要么一起失败，必须是一个整体性的事务。

分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

也就是说，在分布式系统上一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务节点上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。

任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务。对于分布式事务而言，即使不能都很好的满足，也要考虑支持到什么程度。

因为行业中没有 “万能方案”，需根据业务场景（如支付需强一致、日志同步可接受最终一致）选择，核心思路是 “用不同机制平衡一致性、可用性、性能”。

分布式事务基础理论

与本地事务不同的是，分布式系统之所以叫分布式，是因为提供服务的各个节点分布在不同机器上，相互之间通过网络交互。不能因为有一点网络问题就导致整个系统无法提供服务，网络因素成为了分布式事务的考量标准之一。因此，分布式事务需要更进一步的理论支持。

CAP理论

CAP 定理是分布式系统设计的基础理论之一，它揭示了分布式系统中三个核心特性的内在矛盾

CAP 定理（CAP theorem）又被称作布鲁尔定理（Brewer’s theorem），是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在 2000 年的 ACM PODC 上提出的一个猜想。2002 年，麻省理工学院的赛斯·吉尔伯特（Seth Gilbert）和南希·林奇（Nancy Lynch）发表了布鲁尔猜想的证明，使之成为分布式计算领域公认的一个定理。对于设计分布式系统的架构师来说，CAP 是必须掌握的理论。

他指出WEB服务无法同时满足一下3个属性：

一致性(Consistency) ：客户端知道一系列的操作都会同时发生(生效)
可用性(Availability) ：每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) ：即使出现单个组件无法可用，操作依然可以完成

具体地讲在分布式系统中，一个Web应用至多只能同时支持上面的两个属性。因此，设计人员必须在一致性与可用性之间做出选择。

CAP的一致性、可用性、分区容错性具体如下：

一致性：
- 指 “所有节点在同一时间看到的数据是相同的”。当数据发生更新后，所有节点必须立即同步到最新状态，保证无论访问哪个节点，获取的数据都是一致的（强一致性）。
- 也就是说，更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致，不能存在中间状态。分布式环境中，一致性是指多个副本之间能否保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处理一致的状态。
- 例如：分布式数据库中，某节点修改了数据，其他节点必须立即能读到这个修改，否则就违反了一致性。
- 数据一致性分为强一致性、弱一致性、最终一致性。
  - 如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的，那么称之为强一致性。
  - 如果允许存在中间状态，只要求经过一段时间后，数据最终是一致的，则称之为最终一致性。
  - 此外，如果允许存在部分数据不一致，那么就称之为弱一致性。
可用性：
- 指 “只要有一个节点正常工作，系统就能响应客户端的请求”。即系统在任何时候都能提供服务，不会因为部分节点故障而拒绝请求（允许响应延迟，但不能无响应）。
- 也就是说，系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
- 这样是两个度量的维度：
  - 有限时间内：对于用户的一个操作请求，系统必须能够在指定的时间（响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。即这个响应时间必须在一个合理的值内，不让用户感到失望。
  - 返回正常结果：要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确地反映出对请求的处理结果，即成功或失败，而不是一个让用户感到困惑的返回结果。比如返回一个系统错误如OutOfMemory，则认为系统是不可用的。
分区容错性：
- 指 “当分布式系统中的节点间出现网络分区（即节点间通信中断）时，系统仍能继续工作”。网络分区是分布式系统的常态（如网络故障、超时、丢包等），因此分区容错性是分布式系统必须具备的特性。
- 也就是说，分布式系统在遇到任何网络分区故障时，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障
- 网络分区，是指分布式系统中，不同的节点分布在不同的子网络（机房/异地网络）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状态，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干孤立的区域。组成一个分布式系统的每个节点的加入与退出都可以看做是一个特殊的网络分区。

为什么三者不可兼得？

虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象，放弃分区容错性的话，则放弃了分布式，放弃了系统的可扩展性。

如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。

分布式系统的本质是 “多节点通过网络通信协同工作”，而网络是不可靠的（必然存在分区 P）。因此，CAP 定理的核心矛盾可以简化为：当网络分区（P）发生时，系统只能在一致性（C）和可用性（A）中二选一，具体逻辑如下：

假设系统必须保证分区容错性（P）（这是分布式系统的前提，否则就退化为单机系统）。
当网络分区发生时（例如节点 A 和节点 B 无法通信）：
- 若要保证一致性（C）：
  
  节点 A 收到更新请求后，必须等待节点 B 同步数据成功才能返回结果。但此时 A 和 B 已断连，A 会一直等待，导致无法响应请求（牺牲可用性 A）。
- 若要保证可用性（A）：
  
  节点 A 收到更新请求后，立即执行本地操作并返回结果（不等待 B 同步）。此时 A 和 B 的数据不一致（牺牲一致性 C）。

因此，在分布式系统中，P 是必须接受的前提，C 和 A 只能取舍，不存在 “同时满足 C、A、P” 的完美系统。

而且在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。大多数分布式事务方案（如 TCC、Saga）本质是 “放弃强一致性，追求最终一致性”，即在 CAP 中选择 AP，通过补偿机制让数据在分区恢复后逐渐一致，平衡可用性和一致性。

但是，通过 CAP 理论，我们知道无法同时满足一致性、可用性和分区容错性这三个特性，那要舍弃哪个呢？

对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到 N 个 9，即保证 P 和 A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。

对于涉及到钱财这样不能有一丝让步的场景，C 必须保证。网络发生故障宁可停止服务，这是保证 CA，舍弃 P。貌似这几年国内银行业发生了不下 10 起事故，但影响面不大，报道也不多，广大群众知道的少。还有一种是保证 CP，舍弃 A。例如网络故障是只读不写。

CAP 的取舍组合

这个其实在 Nacos 之前讲解原理的时候，涉及到了这些内容

CP 系统

当网络分区发生时，为了保证数据一致，系统可能拒绝部分请求（牺牲可用性）。

例如，为了保证一致性，当发生分区现象后，N1 节点上的数据已经更新到 y，但由于 N1 和 N2 之间的复制通道中断，数据 y 无法同步到 N2，N2 节点上的数据还是 x。这时客户端 C 访问 N2 时，N2 需要返回 Error，提示客户端 C“系统现在发生了错误”，这种处理方式违背了可用性（Availability）的要求，但是满足了C 和 P

这种系统一般在对一致性要求极高，可接受短期不可用的场景（如金融交易、分布式数据库的强一致性模式）。

AP 系统

当网络分区发生时，系统优先保证所有节点都能响应请求，但允许数据暂时不一致（最终会通过补偿机制修复）。也就是，牺牲一致性，保证可用性和分区容错性

例如如下图所示，为了保证可用性，当发生分区现象后，N1 节点上的数据已经更新到 y，但由于 N1 和 N2 之间的复制通道中断，数据 y 无法同步到 N2，N2 节点上的数据还是 x。这时客户端 C 访问 N2 时，N2 将当前自己拥有的数据 x 返回给客户端 C 了，而实际上当前最新的数据已经是 y 了，这就不满足一致性（Consistency）的要求了，因此 CAP 三者只能满足 AP。注意：这里 N2 节点返回 x，虽然不是一个“正确”的结果，但是一个“合理”的结果，因为 x 是旧的数据，并不是一个错乱的值，只是不是最新的数据而已。

这种系统一般用在对可用性要求极高，可接受短期数据不一致的场景（如社交软件的消息同步、电商商品评论）。

BASE 理论

CAP是分布式系统设计理论，BASE是CAP理论中AP方案的延伸，对于C我们采用的方式和策略就是保证最终一致性；

eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结，在ACM上发表文章提出BASE理论，BASE理论是对CAP理论的延伸，核心思想是即使无法做到强一致性（StrongConsistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。满足BASE理论的事务，我们称之为“柔性事务”。

基本可用 Basically Available：
- 基本可用是指分布式系统在出现不可预知的故障的时候，允许损失部分可用性，但不等于系统不可用。
- 响应时间上的损失
  - 当出现故障时，响应时间增加
- 功能上的损失
  - 当流量高峰期时，屏蔽一些功能的使用以保证系统稳定性（服务降级）
软状态 Soft state
- 指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。
- 与硬状态相对，即是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性 Eventual Consistency
- 强调系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。其本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
  - 最终一致性可分为如下几种：
    - 因果一致性（Causal consistency）：即进程A在更新完数据后通知进程B，那么之后进程B对该项数据的范围都是进程A更新后的最新值。
    - 读己之所写（Read your writes）：进程A更新一项数据后，它自己总是能访问到自己更新过的最新值。
    - 会话一致性（Session consistency）：将数据一致性框定在会话当中，在一个会话当中实现读己之所写的一致性。即执行更新后，客户端在同一个会话中始终能读到该项数据的最新值
    - 单调读一致性（Monotonic read consistency）：如果一个进程从系统中读取出一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
    - 单调写一致性（Monotoic write consistency）：一个系统需要保证来自同一个进程的写操作被顺序执行。

BASE理论是提出通过牺牲一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的。它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。

但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。

BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

BASE理论其实就是对CAP理论的延伸和补充，主要是对AP的补充。牺牲数据的强一致性，来保证数据的可用性，虽然存在中间装填，但数据最终一致。

柔性事务和刚性事务

分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。

上述场景就是分布式一致性问题，追根到底，分布式一致性的根本原因在于数据的分布式操作，引起的本地事务无法保障数据的原子性引起。

分布式一致性问题的解决思路有两种，一种是分布式事务，一种是尽量通过业务流程避免分布式事务。分布式事务是直接解决问题，而业务规避其实通过解决出问题的地方(解决提问题的人)。其实在真实业务场景中，如果业务规避不是很麻烦的前提，最优雅的解决方案就是业务规避。

所以，分布式事务可以这样被分类：

分布式事务实现方案从类型上去分刚性事务、柔型事务
- 刚性事务满足CAP的CP理论
- 柔性事务满足BASE理论（基本可用，最终一致）

首先用一张表直观对比二者的核心差异，再展开细节：

对比维度	刚性事务（Rigid Transaction）	柔性事务（Flexible Transaction）
核心目标	追求强一致性（符合 ACID 完整特性）	追求最终一致性（放松 ACID 中的强一致性要求）
CAP 取舍	典型的 CP 方案（牺牲可用性保一致性）	典型的 AP 方案（牺牲强一致性保可用性）
执行机制	基于 “锁 + 阻塞” 确保操作原子性	基于 “补偿 + 异步” 允许中间不一致，最终修正
适用场景	金融转账、支付等对一致性要求极高的场景	订单创建、库存扣减、积分发放等对可用性要求高的场景
性能与阻塞	性能低，可能因锁或网络问题阻塞	性能高，无阻塞（或低阻塞）