文章目录
- 一、什么是事务
- 1、事务的具体定义
- 2、数据库事务的ACID属性
- 3、什么时候使用数据库事务
- 二、什么是分布式事务
- 1、分布式事务产生背景与概念
- 2、分布式事务的难点
- 三、分布式系统的一致性
- 1、CAP理论
- 2、CAP理论的延伸---BASE理论
- 3、数据一致性模型
- 四、常见分布式事务解决方案
- 1、2PC(二阶段提交)方案----强一致性
- （1）方案简介
- （2）处理流程
- （3）方案总结
- 2、3PC(三阶段提交)方案
- （1）方案简介
- （2）处理流程
- （3）方案总结
- 五、怎么保证事务一定提交？
一、什么是事务
介绍分布式事务之前，先介绍什么是事务。
1、事务的具体定义
事务提供一种机制：将一件事情涉及的所有操作放入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。
简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。
2、数据库事务的ACID属性
【原子性(Atomicity)】：
组成事务的系列操作是一个整体，要么全执行，要么不执行。通过上面例子就是从A同学扣除钱和向B同学增加100是一起发生的，不可能出现扣除了A的钱，但没增加B的钱的情况。
【一致性(Consistency)】：
在事务开始之前和事务结束以后，数据库的完整性和状态没有被破坏。这个怎么理解呢？就是AB两人在转账钱的总和是2000，转账后两人的总和也必须是2000。不会因为这次转账事务破坏这个状态。
【隔离性(Isolation)】：
多个事务在并发执行时，事务执行的中间状态是其他事务不可访问的。A转出100但事务没有确认提交，这时候银行人员对其账号查询时，看到的应该还是1000，不是900。
【持久性(Durability)】：
事务一旦提交生效，其结果将永久保存，不受任何故障影响。A转账一但完成，那么A就是900，B就是1100这个结果将永远保存在银行的数据库中，直到他们下次交易事务的发生。
3、什么时候使用数据库事务
简单而言，就是业务上有一组数据操作，需要如果其中有任何一个操作执行失败，整组操作全部不执行并恢复到未执行状态，要么全部成功，要么全部失败。
在使用数据库事务时需要注意，尽可能短的保持事务，修改多个不同表的数据的冗长事务会严重妨碍系统中的所有其他用户，这很有可能导致一些性能问题。
二、什么是分布式事务
1、分布式事务产生背景与概念
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。
上图中包含了库存和订单两个独立的微服务，每个微服务维护了自己的数据库。在交易系统的业务逻辑中，一个商品在下单之前需要先调用库存服务，进行扣除库存，再调用订单服务，创建订单记录。
可以看到，如果多个数据库之间的数据更新没有保证事务，将会导致出现子系统数据不一致，业务出现问题。
2、分布式事务的难点
- 事务的原子性：事务操作跨不同节点，当多个节点某一节点操作失败时，需要保证多节点操作的要么什么都不做，要么做全套（All or Nothing）的原子性。
- 事务的一致性：当发生网络传输故障或者节点故障，节点间数据复制通道中断，在进行事务操作时需要保证数据一致性，保证事务的任何操作都不会使得数据违反数据库定义的约束、触发器等规则。
- 事务的隔离性：事务隔离性的本质就是如何正确多个并发事务的处理的读写冲突和写写冲突，因为在分布式事务控制中，可能会出现提交不同步的现象，这个时候就有可能出现“部分已经提交”的事务。此时并发应用访问数据如果没有加以控制，有可能出现“脏读”问题。
三、分布式系统的一致性
前面介绍到的分布式事务的难点涉及的问题，最终影响是导致数据出现不一致，下面对分布式系统的一致性问题进行理论分析，后面将基于这些理论进行分布式方案的介绍。
1、CAP理论
见之前的一篇文章：。
2、CAP理论的延伸—BASE理论
BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。
- BA - Basically Available 基本可用：分布式系统在出现故障时，允许损失部分可用性，即保证核心可用。这里的关键词是“部分”和“核心”，实际实践上，哪些是核心需要根据具体业务来权衡。例如登录功能相对注册功能更加核心，注册不了最多影响流失一部分用户，如果用户已经注册但无法登录，那就意味用户无法使用系统，造成的影响范围更大。
- S - Soft State 软状态：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。
- E - Eventual Consistency 最终一致性：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充：
【CAP 理论是忽略延时的，而实际应用中延时是无法避免的】：
这一点就意味着完美的 CP 场景是不存在的，即使是几毫秒的数据复制延迟，在这几毫秒时间间隔内，系统是不符合 CP 要求的。因此 CAP 中的 CP 方案，实际上也是实现了最终一致性，只是“一定时间”是指几毫秒而已。
【AP 方案中牺牲一致性只是指发生分区故障期间，而不是永远放弃一致性】：
这一点其实就是 BASE 理论延伸的地方，分区期间牺牲一致性，但分区故障恢复后，系统应该达到最终一致性。
3、数据一致性模型
前面介绍的BASE模型提过“强一致性”和“最终一致性”，下面对这些一致性模型展开介绍。分布式系统通过复制数据来提高系统的可靠性和容错性，并且将数据的不同的副本存放在不同的机器上，由于维护数据副本的一致性代价很高，因此许多系统采用弱一致性来提高性能，下面介绍常见的一致性模型：
- 强一致性：要求无论更新操作是在哪个数据副本上执行，之后所有的读操作都要能获得最新的数据。对于单副本数据来说，读写操作是在同一数据上执行的，容易保证强一致性。对多副本数据来说，则需要使用分布式事务协议。
- 弱一致性：在这种一致性下，用户读到某一操作对系统特定数据的更新需要一段时间，我们将这段时间称为"不一致性窗口"。
- 最终一致性：是弱一致性的一种特例，在这种一致性下系统保证用户最终能够读取到某操作对系统特定数据的更新（读取操作之前没有该数据的其他更新操作）。"不一致性窗口"的大小依赖于交互延迟、系统的负载，以及数据的副本数等。
系统选择哪种一致性模型取决于应用对一致性的需求，所选取的一致性模型还会影响到系统如何处理用户的请求以及对副本维护技术的选择等。后面将基于上面介绍的一致性模型分别介绍分布式事务的解决方案。
四、常见分布式事务解决方案
1、2PC(二阶段提交)方案----强一致性
（1）方案简介
二阶段提交协议（Two-phase Commit，即2PC）是常用的分布式事务解决方案，即将事务的提交过程分为两个阶段来进行处理：准备阶段和提交阶段。事务的发起者称协调者，事务的执行者称参与者。
在分布式系统里，每个节点都可以知晓自己操作的成功或者失败，却无法知道其他节点操作的成功或失败。当一个事务跨多个节点时，为了保持事务的原子性与一致性，而引入一个协调者来统一掌控所有参与者的操作结果，并指示它们是否要把操作结果进行真正的提交或者回滚（rollback）。
二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。核心思想就是对每一个事务都采用先尝试后提交的处理方式，处理后所有的读操作都要能获得最新的数据，因此也可以将二阶段提交看作是一个强一致性算法。
（2）处理流程
（3）方案总结
2PC方案实现起来简单，实际项目中使用比较少，主要因为以下问题：
- 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。。
- 可靠性问题：如果协调者存在单点故障问题，如果协调者出现故障，参与者将一直处于锁定状态。
- 数据一致性问题：在阶段2中，如果发生局部网络问题，一部分事务参与者收到了提交消息，另一部分事务参与者没收到提交消息，那么就导致了节点之间数据的不一致。
2、3PC(三阶段提交)方案
（1）方案简介
三阶段提交协议，是二阶段提交协议的改进版本，与二阶段提交不同的是，引入超时机制。同时在协调者和参与者中都引入超时机制。
三阶段提交将二阶段的准备阶段拆分为2个阶段，插入了一个preCommit阶段，使得原先在二阶段提交中，参与者在准备之后，由于协调者发生崩溃或错误，而导致参与者处于无法知晓是否提交或者中止的“不确定状态”所产生的可能相当长的延时的问题得以解决。
（2）处理流程
【阶段1】：canCommit 协调者向参与者发送commit请求，参与者如果可以提交就返回yes响应(参与者不执行事务操作)，否则返回no响应：
【阶段2】：preCommit 协调者根据阶段1 canCommit参与者的反应情况来决定是否可以基于事务的preCommit操作。根据响应情况，有以下两种可能：
【阶段3】：do Commit 该阶段进行真正的事务提交，也可以分为以下两种情况：
（3）方案总结
- 优点：相比二阶段提交，三阶段降低了阻塞时间，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题，阶段3中协调者出现问题时，参与者会继续提交事务。
- 缺点：数据不一致问题依然存在，当在参与者收到preCommit请求后等待do commite指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。
五、怎么保证事务一定提交？
事务管理器将所有数据结点list存储，循环执行操作，设立flag标记状态。根据flag状态，执行操作或回滚。
