布式事务和解决方案理论

原文作者：VectorJin https://juejin.im/post/5e066c9ff265da33b0718f89

1. 本地事务

　　事务Transaction由一组SQL组成，具有四个ACID特性

1.1 ACID

Atomicity 原子性 构成事务的一组SQL，要么全部生效，要么全不生效，不会出现部分生效的情况
Consistency 一致性 数据库经过事务操作后从一种状态转变为另一个状态。可以说原子性是从行为上描述，而一致性是从结果上描述
isolation 隔离性 事务操作的数据对象相对于其他事务操作的数据对象相互隔离，互不影响
durability 持久性 事务提交后，其结果就是永久性的，即使发生宕机（非磁盘损坏）

1.2 事务实现

　　对于MySQL数据库（InnoDB存储引擎）而言，隔离性是通过不同粒度的锁机制来实现事务间的隔离；原子性、一致性和持久性通过redo log 重做日志和undo log回滚日志来保证的。

　　redo log：当数据库对数据做修改的时候，需要把数据页从磁盘读到buffer pool中，然后在buffer pool中进行修改，那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致，称buffer pool的数据页为dirty page 脏数据，如果这个时候发生非正常的DB服务重启，那么这些数据还没在内存，并没有同步到磁盘文件中（注意，同步到磁盘文件是个随机IO），也就是会发生数据丢失，如果这个时候，能够在有一个文件，当buffer pool 中的data page变更结束后，把相应修改记录记录到这个文件（注意，记录日志是顺序IO），那么当DB服务发生crash的情况，恢复DB的时候，也可以根据这个文件的记录内容，重新应用到磁盘文件，数据保持一致。

　　undo log：undo日志用于存放数据被修改前的值，如果修改出现异常，可以使用undo日志来实现回滚操作，保证事务的一致性。另外InnoDB MVCC事务特性也是基于undo日志实现的。undo日志分为insert undo log （insert语句产生的日志，事务提交后直接删除）和 update undo log（delete和update语句产生的日志，由于该undo log可能提供MVVC机制使用，所以不能再事务提交时删除）。

1.3 问题引入

1.3.1 CAP理论

　　CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。但由于在分布式系统中，分区容错性必然存在，所以只能在一致性和可用性妥协。

　　传统的DBMS，如MySQL其实CA组合，在主从架构下，读写分离的情况下，是牺牲一定的一致性的（主从延迟）。

1.3.2 Base理论

base available 基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用
soft state 软状态：允许系统中存在中间状态，这个状态不影响系统可用性
eventually consistent 最终一致性：系统的中间状态经过短暂的时间后到达一致状态

2. 如何解决

2.1 场景举例

　　考虑这样一种业务场景，系统A调用系统B的退款服务进行退款，系统A更改内部退款状态，接着调用系统C的短信服务通知用户。

　　在这样的一个场景下，由于网络不可靠的必然存在，存在A、B、C三个系统之间一致性的问题。

2.2 本地表

　　针对上述场景，设计两张表 退款记录表 和 短信发送记录表 以及相应的补偿Job

　　具体实现过程：

新增退款记录表，状态为处理中
调用系统B的退款服务进行退款
更新退款记录状态为对应的状态（成功/失败）
如果退款成功，则新增短信发送记录，记录状态为待发送
调用系统C的短信服务，发送短信
更新短信发送记录为已发送

　　退款补偿Job 查询退款记录表中处理中的记录，调用系统B的退款服务退款成功处理：

新增短信发送记录，记录状态为待发送
调用系统C的短信服务，发送短信
更新短信发送记录为已发送

　　短信通知补偿Job 查询短信发送记录中待发送的记录，调用系统C的短信服务

调用系统C的短信服务，发送短信
更新短信发送记录为已发送

　　注意：　

系统B和系统C需要根据调用方传的uuid支持幂等
系统A、B、C会出现短暂的不一致，但最终一致

2.3 事务消息

　　可以将其视为两阶段提交消息实现，以确保分布式系统中的最终一致性。事务性消息可确保本地事务的执行和消息的发送可以原子方式执行。

　　但是由于事务消息异步的特性，调用方拿不到消费方的处理结果，适用于不关心对方的返回结果/对方负责保证处理成功。

　　针对上述场景，增加两个事务消息的方式解决一致性问题，系统A通过发送事务消息的方式与系统B和系统C进行交互。

　　具体实现过程：

发送退款的事务消息
新增退款记录，状态为：处理中
Commit退款事务消息

　　提供MQ事务callback

　　退款callback查询：

有退款记录且为处理中则Commit
其他则Rollback

　　发送短信callback查询：

有退款记录且成功则Commit
其他则Rollback

　　退款同步Job

　　查询退款记录表中处理中的记录，调用系统B的退款查询接口同步状态其中退款成功处理：

发送短信的事务消息
更新退款记录为成功
Commit短信事务消息

2.4 相关理论

2.4.1 二阶段提交

　　二阶段提交是解决分布式事务问题的重要理论基础，但也存在着明显的问题：

阻塞问题，参与者将协议消息发送给协调器后，它将阻塞直到收到提交或回滚，只能依赖协调者的超时机制
协调者单点问题，如果协调者出现故障，则某些参与者将一直无法收到提交或回滚的消息。

　　为了解决二阶段提交出现的问题，又有了三阶段提交（Three-phase commit）：

解决阻塞问题：将2PC中的第一阶段一分为二，提供了一个CanCommit阶段，此阶段并不锁定资源，这样可以大幅降低了阻塞概率
解决单点问题：在参与者这边也引入了超时机制

2.4.2 DTP Model

　　X / Open分布式事务处理DTP（Distributed Transaction Processing）模型是一种软件体系架构，已经成为事实上的事务模型组件的行为标准。它允许多个应用程序共享由多个资源管理器提供的资源，并允许其工作被协调为全局事务。

ApplicationProgram(AP) 应用程序定义了事务边界并指定构成事务的操作
ResourceManager(RM) 资源管理器用来管理我们需要访问的共享资源，我们可以将它理解为关系数据库、文件存储系统、消息队列、打印机等
TransactionManagger(TM) 事务管理器是一个独立的组件，他为事务分配标识符并监视事务的执行情况，负责事务完成和故障恢复
CommunicationResourceManager(CRM) 通信资源管理器控制一个或多个 TM domain 之间分布式应用的通信。

2.4.3 XA Specification

　　XA规范是X/Open关于分布式事务处理 (DTP)的规范。规范描述了全局的事务管理器与局部的资源管理器之间的接口。XA规范的目的是允许多个资源（如数据库，应用服务器，消息队列，等等）在同一事务中访问，这样可以使ACID属性跨越应用程序而保持有效。XA使用两阶段提交来保证所有资源同时提交或回滚任何特定的事务。

　　XA规范描述了资源管理器要支持事务性访问所必需做的事情。

2.4.5 TCC

2.4.6 saga

　　在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。
　　分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会去退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

　　Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

　　Saga模式的优势是：

一阶段提交本地数据库事务，无锁，高性能；
参与者可以采用事务驱动异步执行，高吞吐；
补偿服务即正向服务的“反向”，易于理解，易于实现；

　　缺点：

Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。

3. 开源项目

3.1 seata

　　Seata 是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。支持AT、TCC、SAGA、XA四种模式，对微服务框架支持友好。

　　如下图所示，Seata 中有三大模块，分别是 TM、RM 和 TC。其中 TM 和 RM 是作为 Seata 的客户端与业务系统集成在一起，TC 作为 Seata 的服务端独立部署。

TC - 事务协调者维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM - 事务管理器定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM - 资源管理器管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

　　在 Seata 中，分布式事务的执行流程：

TM 开启分布式事务（TM 向 TC 注册全局事务记录）；
按业务场景，编排数据库、服务等事务内资源（RM 向 TC 汇报资源准备状态）；
TM 结束分布式事务，事务一阶段结束（TM 通知 TC 提交/回滚分布式事务）；
TC 汇总事务信息，决定分布式事务是提交还是回滚；
TC 通知所有 RM 提交/回滚资源，事务二阶段结束；

3.2.1 AT模式

　　AT 模式是一种无侵入的分布式事务解决方案。在 AT 模式下，用户只需关注自己的“业务 SQL”，用户的 “业务 SQL” 作为一阶段，Seata 框架会自动生成事务的二阶段提交和回滚操作。

　　一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

　　二阶段：提交异步化，非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。

　　在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。