分布式事务的图文详解

这次使用分布式事务框架过程中了学习了一些分布式事务知识，所以本文我们就来聊聊分布式事务那些事。首先我们先回顾下什么是事务。

事务

什么是事务？这个作为后端开发，日常开发中只要与数据库有交互，肯定就会使用过事务。现在摘抄一段wiki的解释，解释下什么是事务。

是数据库管理系统执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成

数据库系统具有事务特性，这是其有别与文件系统重要特性。传统的文件系统，如果正在写文件，操作系统突然崩溃，此时文件可能被破坏。数据库系统引入事务特性，可以保证数据库从一种状态转换为另一种状态。在提交工作时,可以确保要么所有修改都被保存，要么所有都不保存。

通常一个事务会有多个读写操作构成。

事务具有四个基本特性，俗称ACID。

A(Atomicity):原子性。事务会被当做一个整体，要么所有语句都成功，要么都失败，不能存在部分语句成功，部分失败的情况。

C(Consistenc):一致性。数据库的状态从一种状态转变为另外一种状态，事务开始之前和是事务结束之后，数据库完整性约束不变。什么叫数据库完整性约束不变？举个例子，若一个表姓名字段为唯一约束，若在事务提交或回滚后，姓名字段变成非唯一了，这就破坏数据库的完整性约束。

I(Isolation):隔离性。多个并发事务执行，互不影响。

D(Durability):持久性。事务提交之后，其对数据库相关修改能永久保存在数据库。所以该特性需要数据库系统可以在崩溃时需要恢复时也能提交的数据都不丢失。

因此早期我们的系统只在存在一个数据源情况下，这个时候可以依靠数据库系统事务来保证业务的正确性。

但是随着业务的不断扩展，我们业务的一个单表可能就存在千万数据，在使用再使用一个数据库实例，就会可能存在性相关能问题。这个时候我们就会考虑分库分表。但是这样就有可能导致，单个应用连接多个数据源的情况。如下图示例。

这种情况下我们更加不能保证所有调用都成功。

由上面的例子下我们可以看出，随着业务发展，传统的单机事务已经无法满足我们的业务的需求，这个时候我们就需要分布式事务来保证。

分布式事务

摘抄一段 wiki 上解释。

A distributed transaction is a database transaction in which two or more network hosts are involved.

我们先来讲下实现分布式事务一些理论基础。

分布式事务技术理论

CAP 定理。在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。

摘录极客时间从0开始学架构第22章解释

虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构

BASE 理论，分别是以下三个单词的缩写。

Basically Available（基本可用）：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。

Soft state（软状态）：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是CAP中的不一致。

Eventually consistent（最终一致性）：最终一致是指经过一段时间后，所有节点数据都将会达到一致。

BASE 是对CAP 中 AP 方案的一种补充。在 BASE 中用软状态和最终一致，保证了延迟后的一致性。BASE 和 ACID 是相反的，ACID 是一种强一致性模型，而 BASE 却是牺牲这种强一致性，允许数据短时间内不一致，最终一致性。

接下来我们看看分布式事务有哪几种实现方案。

分布式事务实现方案

1. 基于数据库资源层面

• 2PC 两阶段提交协议

• 3PC 三阶段提交协议

2. 基于业务层面

• TCC

基于数据库资源层面实现方案，由于存在多个事务，我们需要存在一个角色管理各个事务的状态。我们将这个角色称为协调者，事务参与者称为参与者。参与者与协调者一般会基于某种特定协议，目前比较有名的为 XA 接口协议。基于协调者与参与者的思想设定，分别提出了 2PC 与 3PC 实现XA 分布式事务。

2PC 两阶段提交协议

如名字所知，这个过程主要分为两步。

第一阶段，协调者(事务管理器)将涉及到事务的进行预提交，这个时候数据库资源开始被锁定。参与者将 undo 与 redo 写入事务日志。
第二阶段，参与者（资源管理器）行提交事务，或者利用 undo 日志回滚事务，释放资源。

整个过程如下图。

分布式事务提交成功场景：

看到这，我们我们可以看出 TCC Try 成功，confirm 必定要成功，try 失败，cancle 必定要成功。因为 confirm 是系统更新为终态的关键。但是现实这么无情，生产系统 confirm 或 cancle 肯定会有几率失败，这个时候就需要 TCC 框架记录调用 confirm 结果。如果 confirm 调用失败，TCC 框架需要记录下来，然后间隔一定时间再次去调用。

总结与思考

看完全文，基本上对分布式事务又一定了解了吧。

我们基于此对此总结下。使用分布式事务，我们需要结合我们实际场景应用。

如果业务还处于开始阶段，我们其实可以选择数据库事务来保证快速上线迭代。

等到业务一定阶段，系统开始拆分，数据库也拆分，这时如果业务需要保证一致性，这时必须使用分布式事务。这时候使用分布式事务，我们需要基于业务考虑使用哪种。

使用 2PC 或 3PC 实现的分布式框架，业务应用层无需改动，接入较简单。但是相对应能较低，数据资源锁定较长。不太适合互联网等高并发业务场景。

而使用基于 TCC 实现分布式框架，相对 2PC 性能较高，可以保证数据最终一致性。但是对于应用层来说，一个方法必须改造成三个方法，且业务中需引入一些中间状态，相对而言应用改造程度较大。

以上就是分布式事务的图文详解的详细内容，更多请关注 第一PHP社区 其它相关文章！