分布式事务概念、理论、及(2PC、3PC）
一. 简介
1. 什么是本地事务？
基于关系型数据库的事务通常被称为本地事务 ，也可称为数据库事务 。一般来说，在一个服务器上运行的应用程序与数据库之间通过利用数据库自身的事务特性来实现本地化的交易操作。
数据库事务的特性：ACID。
(1). 原子性（Atomicity）：指一个事务内的所有操作要么都执行，要么都不执行。
(2). 一致性（Data Integrity）：确保数据符合完整性规则，并且不存在中间态的数据。
(3). 互不干扰性（Isolation），指的是当多个事务同时执行时不会相互影响，并且每个事务自身的数据不会被其他事务所访问。
(4). 持久性（Durability），表示一旦某个事务被成功完成时的数据就已经永久地被存储下来，并且后续的所有操作或者任何故障都不会对该事务的结果产生任何影响。
PS: 在Redis中进行事务操作时不具备回滚功能属于例外情况之一。 可参考官方详细解析 https://www.cnblogs.com/yaopengfei/p/13922295.html
2. 什么是分布式事务？
(1). 含义：在分散化的系统架构中，默认情况下不同服务之间的交互是为了实现特定的功能或目标而进行的协作过程。这被定义为分布式事务处理机制。具体而言，在下单业务流程中，首先会发起订单创建操作；随后，在确认支付成功后会触发库存数量的减少步骤
A. 对于本地事务而言：通过数据库即可实现相关的功能。比如Ordering接口中的操作包括查询订单列表、创建新订单以及更新订单状态等详细信息。
begin transaction；
1. 访问订单表，创建订单
2. 访问库存表：扣减库存 (以上两个表是同一个DB)
commit transation;在分布式事务场景下涉及订单和服务层以及库存管理层。为了发起订单操作，在请求该Order接口时，请确保其不仅需要通过内部数据库生成新的订单（即完成支付与发货流程），还需协调与库存和服务层之间的交互以保证数据的一致性。从而引发网络通信需求。而传统的数据库事务处理机制无法应对这种复杂性。
begin transaction；
1. 订单微服务，创建订单 (本地DB)
2. 通过网络调用库存微服务中接口，进行扣减库存
commit transation;(2). 产生分布式事务的几种情况
A. 跨进程通信(典型微服务架构，多服务对应多DB)
常见的情况是，在 typical 下单操作中, 客户端会向 orders subsystem 发出请求, 该 subsystem 不仅负责将接收到的 orders 数据录入 orders database 中, 还需与 inventory subsystem 协作完成 goods 的入库流程, 这样一来就形成了一个分布式事务机制.
B. 单服务对应多DB
例如，在现代应用中，在面对大量数据时必须采用分库机制以提高效率和安全性。其中涉及多个数据库管理平台如用户表、订单表等常见的业务表。每个数据库对应独立的数据库连接口同样遵循分布式事务的原则。
C. 多服务对应单DB
例如，在某些情况下尽管服务被划分成了多个部分 但仍然只属于一个数据库 订单微服务与库存微服务会共享同一个数据库 在下单的过程中 类似地 涉及到了跨进程的操作 不同的微服务各自拥有独立的数据库连接 这种配置同样符合分布式事务的要求
基于C/C++的Linux服务器开发 高级级教师 / 高级级教师 - C++后台开发课程获取途径
文章福利
文章福利
文章福利
二. 理论分析
1. CAP理论分析
(分布式事务需要CAP理论支持)
(1). 什么是CAP？
CAP(C, A, P)，其中C代表一致性（Consistency），A代表可用性（Availability），P代表分区容忍性（Partition Tolerance）。
下面用1个增加、查询商品的流程来解释什么是CAP。
A. 增加商品，向主数据库中插入数据。
B. 主数据库写入成功，需要把数据同步给从数据库。
C.查询商品，访问从数据库读取。
① C-Consistency
一致性是指执行写操作后进行读取时能够获取到最新更新的数据状态，在数据被分散存储在多个节点时 从任何一个节点读取的数据都是当前最新的状态
上图中，商品信息的读写要满足一致性就是要实现如下目标：
- 当商品服务被写入主数据库顺利时，则从数据库查询新数据也会顺利。
- 当商品服务被写入主数据库出现故障时，则从数据库查询新数据同样无法完成。
如何实现一致性？
插入至主库后，在与从库进行数据同步的过程中必须将从库进行锁定操作，并待全部数据完成交换后再解锁。以避免因新数据的提交而造成旧数据被检索的问题。
分布式系统一致性的特点：
- 在执行数据同步操作时，写操作的响应时间会不可避免地有所延后。
- 为确保数据的一致性起先会对资源进行暂时锁定，在完成数据同步后及时解除对该资源的锁定。
- 当请求节点尝试进行非成功数据同步时将返回相应的错误信息而不提供旧的数据版本以避免混淆或误导。
② A-Availability
可用性是指所有事务操作均能即时处理，并且确保无一例外地避免任何响应超时或错误发生。
上图中，商品信息读取满足可用性就是要实现如下目标：
1. 从 数据库接收到数据查询的请求则立即能够响应数据查询结果 。
2. 从 数据库不允许出现响应超时或响应错误。
如何实现可用性？
1. 写入主数据库后要将数据同步到从数据库。
2. 由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
即使在尚未完成同步操作的情况下，在数据库中仍需提供所需的查询结果；即便这些结果属于过期数据，在无法获得任何过期数据的情况下也应依据协议规定输出一个预设的信息以避免发送错误信息或导致系统超时。
分布式系统可用性的特点：每个请求都能得到及时回应，并且不会发生响应超时或服务中断的情况
③ P-Partition Tolerance
在分布式系统中，各个节点通常被分布在不同的子网中。这即为网络分区；可能会因网络问题导致结点间通信可能失败；但即便如此仍可对外提供服务；我们称这种特性为分区容错性。（P一定是存在的！）
上图中，商品信息读写满足分区容忍性就是要实现如下目标：
1. 主数据库向从数据库同步数据失败不影响读写操作。
2. 其一个结点挂掉不影响另一个结点对外提供服务。
如何实现分区容忍性？
建议采用异步而非同步的方式进行数据传输，在处理过程中各节点之间能够实现松耦合的状态
2. 添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。
分布式分区容忍性的特点：分区容忍性分是布式系统具备的基本能力
要点：在所有分布式事务场景中不可能同时拥有CAP三个特性，在具备P的情况下C和A共同存在是不可能的。
(2). CAP常见的组合形式？
① AP
在分布式系统的设计中，选择这种策略是一种常见的做法。舍弃一致性的要求，在重视分区耐受性和可扩展性的前提下进行设计，在实践中是一种普遍的选择
例如：这部分商品管理完全能达到AP要求的前提是用户接受的数据在特定时间段内不是最新更新的。
一般来说，在实施AP的过程中能够确保最终的一致性
② CA
牺牲可用性以换取一致性和分区容错机制。本质上它致力于实现高度的一致性。例如，在跨行转账中一个转账请求只有在双方银行系统确认整个交易流程全部完成才会被认为是成功的。
③ CA
放弃分区协议，则无需划分虚拟分区，在网络断开或节点失效的情形下仍可保证数据的一致性和高可用性。这样的系统本质上成为一个单体结构。
(3). 总结
CAP理论是一个已被广泛认可的重要理论，在分布式系统中最多只能实现一致性（Consistency）、可用性（Availability）与分区容忍性（Partition Tolerance）这三个特性中的任意两个特性。它也被视为架构设计和技术选型的重要参考标准。在多数大型互联网应用中，节点数量庞大且分布广泛，并且集群规模持续扩大。因此节点故障和网络故障已成为常见问题；为了确保服务可用性达到N个9（即99.99...%），同时需要具备良好的响应性能以提升用户体验水平；因此通常的做法是优先保证P和A特性的同时放弃强一致性
2. Base理论分析
(1). 背景
CAP理论揭示了一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项性能中的两项。其中AP模式在实际应用中更为常见，“AP”代表的就是放弃了一致性这一项性能，在保证了可用性和分区容忍性的前提下运行。“尽管在实际生产环境中有很多场景都需要实现某种形式的一致性保障机制——例如我们在前面讨论的例子中提到的主数据库向从数据库同步数据的情况：即便放弃了一致性这一项要求，“但最终还是要确保数据能够成功同步完成以维持整体的一致状态”。然而，在这种情况下，“CAP”中的强一致性要求意味着：在任意给定的时间点上查询任意一个节点的数据时都必须保持一致的状态；而Base理论则强调的是最终一致性的概念：“它允许在某个时间段内各个节点的数据存在不一致的情况；但随着时间的推移，在这个系统运行到稳定状态后；每个节点的数据必须达到完全一致的状态”。
(2). Base理论
BASE 由 Basic Availability（基本可用）、Soft State（软状态）以及 Eventual Consistency（最终一致性）三个术语构成。它是 CAP 模型中 AP 部分的一个拓展，在保证系统可用性的前提下以换取更强的一致性要求，在出现故障时允许系统部分不可用但必须确保核心功能依旧在线，在线期间可能存在短暂不一致的情况但最终会实现一致状态。满足 BASE 理论要求的事务我们称之为 '柔性事务' 。
- 基本可用：即使分布式系统出现故障也能确保核心功能持续运行而不受影响。
- 非硬态中间态：基于BASE协议的分布式系统允许处于非硬态中间态而不影响整体可操作性。
- 其中包含两个层次：
- 非硬态中间态是指当某个组件无法及时响应请求或处理事务时所处的状态
- 这种状态下不会导致系统的不可用
- 其中包含两个层次：
- 最终一致性：经过足够长时间的运行后...各节点的数据趋于统一。
3. 分布式事务解决方案分类
(1). 强一致性
任意时刻数据都是一致的，常见的有：2PC、3PC。
(2). 弱一致性
允许多次运行之间存在短暂的一致性差异，在经过特定时间后保证统一性；常见的实现这一目标的方式包括TC/CTC（Try-Confirm-Cancel/Cancel-Transition-Commit）代码层面
(3). 最终一致性
虽然在某些情况下数据可能会出现不一致，在业务层面必须保持一致性。 常见的包括本地消息表和最大努力通知
三. 强一致性-2PC
1. 2PC原理
(1). 含义
Two-phase commit protocol,简称2PC,意为分两阶段提交. Prepare phase是准备阶段, commit phase是提交阶段. 2代表两个阶段,P代表Prepare phase,C代表commit phase.
(2). 流程
2PC引入一个新的角色，事务协调器 ，用来协调各个参与者的提交和回滚。
A. 准备阶段： 协调机构向各参与方发布预热指令，在同步阻塞状态等待所有参与方响应信号后进入提交环节。
PS：事务管理器向每个参与者发布Prepare消息，并指示其执行本地事务操作，并记录本地的撤销/重做日志信息；在此状态下该事务并未提交到数据库系统中（撤销日志用于回滚前的数据版本记录功能，重做日志用于后续提交后更新数据文件的功能）
B. 提交阶段：
如果某个参数在执行过程中出现故障，则协调器将通过发送通知指令的方式向所有参与者发出回滚事务的操作命令；该系统将在等待所有参与事务均完成回滚操作完成后才会继续进行后续操作；最终系统会将锁定资源释放出去以保证系统的稳定性
成功流程：
失败流程：
2. 2PC异常剖析
(1). 提交阶段失败
A. 发生事务提交失败：必须反复尝试。由于可能有其他参与者已经完成了他们的事务提交，并非所有参与者都处于相同的执行状态。因此，在此情况下必须持续尝试直至成功。如果一直无法解决，则需要手动干预处理
B. 事务发生故障时的回滚处理：系统将持续不断地进行尝试，并在所有参与者完成回滚操作后停止尝试。否则会导致那些已完成第一阶段准备的参与者继续阻塞。
总结：2PC是一种基于同步机制的阻塞协议，在其运行过程中，在第一阶段中（即第一阶段），协调者将等待所有参与者做出响应后才进行后续操作；然而，在第一阶段中存在超时机制：如果因网络延迟未能收到某个参与者的确切回应（或该参与者出现故障停止工作），则会在超时时判定事务失败并发送回滚指令给所有参与者；而在第二阶段中没有相应的超时机制：即无法通过重试来解决可能的问题。
(2). 事务协调器故障
（协调者故障，通过选举得到新协调者）
A. 假设协调者在发送准备命令之前挂了，还行等于事务还没开始。
B. 假设协调者在发送准备命令后失联了, 这样就不大好办了, 所有参与方实际上都陷入了事务资源被锁定的状态。不仅导致事务无法继续推进, 还会因被锁定的公共资源而使得系统其他操作停滞不前。
C. 如果协调者在发送回滚事务命令之前出现故障并被挂接，则该事务也将无法推进，并导致该阶段所有已完成准备的参与者均陷入停滞状态。
D. 假设协调者在发送回滚事务命令后因故脱节，则这一过程仍能正常运行。该系统会确保回滚事务指令得以发送，并且较高的概率能够成功回滚资源释放。然而，在网络分区发生时，则将导致这些参与者无法及时响应并可能出现阻塞现象。
E. 假设协调者在提交事务命令前崩溃了，则这种情况不可行——令人尴尬地发现所有资源都被阻塞。
当协调者在提交事务命令后出现故障时，至少能够将命令发送出去，并及时完成提交操作。这可能会成功完成提交并释放资源，但若发生网络分区问题，则可能导致部分参与者因无法接收到正确的事务执行指令而出现停滞现象。
3. XA方案
参考：https://www.cnblogs.com/dyzcs/p/13780668.html
4. .Net下的DTC模式
该框架具备良好的兼容性，并未集成类似功能；其系统实现中并未集成分布式事务功能；这使得无法通过现有的 TransactionScope 或 CommittableTransaction 实现多资源管理器之间的事务协调；传统的分布式事务解决方案通常依赖于Windows系统的Message Service for Distribution（MSDTC）；然而.NET Core要实现跨平台目标时会遇到障碍；因为基于跨平台环境下的分布式事务解决方案尚未形成统一标准；后续版本计划对此进行优化和完善
详见：https://www.cnblogs.com/yaopengfei/p/7748221.html 底部。
开启msdtc服务的步骤： cmd命令→net start msdtc
主要依赖下面这个服务：
5. Seata方案
参考：https://www.cnblogs.com/dyzcs/p/13780668.html
Seata实现2PC与传统2PC的差别
架构层次方面：传统 2PC 方案中的 RM 实际上位于数据库层面，在本质上等同于数据库本身，并通过 XA 协议实现了功能。相比之下 Seata 的 RM 则采用了 jar 包形式作为中间件层部署在应用程序的一侧
两阶段提交机制中，在任何情况下（不论是提交（commit）还是回滚（rollback）），事务性资源相关的锁定机制都需要等到Phase2完成才能解除。然而，在Seata的设计中，在Phase1阶段即完成本地事务提交工作后即可实现锁定解除功能（即避免了Phase2期间占用锁定资源的时间消耗），从而显著提升了整体处理效率
6. 总结
(1). 2PC是一种通过强化一致性机制实现高度一致性的分布式事务系统，在这种特性下会导致严重同步阻塞现象的发生进而引发严重的资源长期封锁问题。整体效率低下，并且容易发生单一协调节点故障，在极端工作负载下可能导致数据一致性问题
2PC主要应用于底层数据库系统的分布式事务处理模式 ，而我们的业务需求不仅限于数据操作服务 ，还包括图片上传操作以及短信发送请求 。
四. 强一致性-3PC
1. 3PC含义与流程
3PC 包含三个主要环节：包括但不限于准备环节（CanCommit）、预提交环节（PreCommit）以及提交环节（DoCommit）。相较于 2PC 模型，在参与者的协作流程中又增添了一个关键环节——超时机制的引入。此外，在协作流程中还新增了一个关键步骤以实现统一管理。
**PS：在功能流程上而言，在功能流程上而言，在操作流程上，在操作流程上，在功能流程上而言，在操作流程上，在功能流程上而言，在功能流程上而言，在操作流程上，在功能流程上而言，在操作流程上
(1). 准备阶段
准备阶段的变更改为不会立即执行事务, 而是会咨询当前参与者的接单条件, 因此在任何情况下都会避免立即开始工作并锁定资源, 进而导致当某些资源不可用时所有参与者都会被阻塞.
(2). 预提交阶段
建立统一的状态对于预提交阶段而言具有重要意义。如同一道分隔线，在预提交阶段之前参与者尚未全部完成回应，在这之后参与者已全部完成回应。
(3). 提交阶段
提交事务或者回滚事务。
2. 3PC剖析
(1). 根据上述分析, 2PC 属于同步阻塞的一种, 我们发现当协调者被卡在提交请求未发送阶段时, 系统效率达到最低点. 此时, 所有参与者均被锁定了资源并处于阻塞状态.
在3PC框架中加入了超时机制后，在线参与者将避免出现长时间静默等待的情况。当一个在线参与者发现其提交事务请求未响应而出现超时现象，则系统会自动触发事务提交流程；通常情况下处于这个阶段的系统状态倾向于完成提交操作；如果在线参与方发现其预提交状态未响应而出现超时，则该参与方可以选择主动发起事务提交请求或者保持当前状态；因此，在这种情况下不影响整体流程的正常运行
但是超时机制可能导致数据一致性问题。例如，在等待提交命令时发生超时的情况下，默认情况下参与者会执行提交事务操作；但是一旦发生超时情况，则可能会出现回滚事务的情况；这将导致数据不一致。
为了解决提交阶段中当2PC 协调者及某参与者的连接均失效后新选举协调者无法判断当前状态是否需要提交或应回滚的问题, 3PC 机制被引入.
当新协调员抵达时发现有一位参与者正处于预提交状态或已完成提交。这表明所有参与者均已进行了确认。因此，在此情况下所执行的就是提交命令。
据专家指出, 3PC 实际上是通过引入预提交阶段来实现参与者间的统一状态
然而这也仅能告知协调者当采取何种行动，并不能确保这种行动一定是正确的选择。事实上这与前述的2PC分析结果一致因为在这种情况下由于在故障中的参与者是否实际执行事务的情况无法判断因此相关的结论也难以得出明确的答案
通常来说，在预提交阶段中能够一定程度上降低故障恢复过程中的复杂性。然而这并不能确保数据的一致性除非当被挂掉的参与者重新加入系统时才能实现一致性
3. 总结
该方案通过引入参与者超时机制来实现，并通过增加预提交阶段，在故障恢复后降低了协调者决策的复杂度。然而整体交互过程变得更为漫长，并且性能表现有所下降。同样会面临数据不一致的问题。因此可以确定的是，在2PC和3PC架构中均无法实现完全的数据一致性。这也就意味着，在大多数情况下需要配置定时扫描补偿机制来解决这些问题。
第十四章：分布式事务的概念与理论分析及强一致性（2PC、3PC）剖析 - Yaopengfei - 博客园