分布式事务的解决思路与方案

- 日理万妓 2022-08-28 08:53 188阅读 0赞

### 导航 ###

*  一、事务的种类与场景
 *  二、分布式事务解决方案
 *   *  2.1 全局事务
     *  2.2 可靠消息事务
     *  2.3 最大努力通知
     *  2.4 TCC 事务

# 一、事务的种类与场景 #

本地事务实际上就是指数据库的事务，参考《[MySQL —— 事务与隔离级别总结][MySQL _]》

分布式事务指的是在分布式环境下，由多个本地事务组成，多个系统之间如何保证事务之间的原子性、一致性等问题。例如多个系统访问同一个数据库，多个系统访问多个数据库，等等这些场景，都数据分布式事务的讨论范围。

# 二、分布式事务解决方案 #

介绍四个业界应用比较广泛的分布式解决方案：全局事务、可靠消息服务、最大努力通知、TCC事务（补偿型事务）。

## 2.1 全局事务 ##

全局事务基于DTP 模型实现，这是由X/Open 组织提出的一种分布式事务模型，全称为“**分布式事务处理参考模型**”。

DTP规定要实现分布式事务，需要三种角色：

> AP：Application 应用系统  
> TM：Transaction Manager 事务管理器  
> RM：Resource Manager 资源管理器

在 DTP 模型中，整个系统的事务分为两个阶段，即 2PC（2 Phrase Commit）：

> 1、准备阶段：也可以叫表决阶段或投票阶段。TM 向 各个 AP 发送准备命令，并告诉各本地事务即将提交事务。TM同步等待参与者的响应。此阶段各本地事务已经完成了事务逻辑，就差一步提交操作。  
> 2、提交阶段：TM 根据响应结果，决定发送提交或回滚命令。若都准备成功，则提交事务；但只要有一个返回失败，就全部回滚。

![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16]  
全局事务的优缺点：

> **优点**：由于是同步阻塞协议，因此可以保证数据的强一致性。资源管理器本身就是数据库，实现不需要增加太多的代码逻辑，实现成本低。流程简单。  
> **缺点**：  
> 1、单点故障问题：TM 是全局事务的协调者、管理者，绝不能出现单点故障问题。  
> 2、同步阻塞：增加了资源阻塞时间，可能存在死锁的风险，需要增加超时机制。  
> 3、一致性问题：二阶段提交可能存在失败的情况，导致数据不一致。
> 
> 总之，该模型是旨在保证强一致性的全局事务模型，但由于其模型仍然简单粗糙，在实际生产中，还需要进一步扩展和细化。

## 2.2 可靠消息事务 ##

基于可靠消息服务的方案是通过消息中间件保证上、下游应用数据操作的一致性。基本可以理解为就是 RocketMQ提供的事务消息，参考《[Spring Cloud —— RocketMQ 的消息类型][Spring Cloud _ RocketMQ]》

假设有A和B两个系统，分别可以处理任务A和任务B。此时存在一个业务流程，需要将任务A和任务B在同一个事务中处理，就可以使用消息中间件来实现这种分布式事务。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 1]

## 2.3 最大努力通知 ##

最大努力通知也被称为定期校对，其实是对可靠消息事务方案的进一步优化。它引入了本地消息表来记录错误消息，然后加入失败消息的定期校对功能，来进一步保证消息会被下游系统消费。

这种方案由于本身需要引入许多额外的补偿结构，如本地消息表、失败消息表、定期校对者等等，增加了业务耦合度，提高了实现复杂度，因此在业界并不是特别流行，但不得不说的确是增加了系统事务的安全性降低了事故风险。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 2]  
第一步：消息由A系统投递到中间件

> 1、处理业务的同一事务中，向本地消息表中写入一条记录  
> 2、准备专门的消息发送者，轮询本地消息表，将需要发送的（未发送的或失败的）事务消息发送到中间件

第二步：消息由中间件投递到B系统

> 1、消息中间件收到消息后负责将该消息同步投递到下游系统，并触发下游系统的任务执行  
> 2、当下游系统处理成功后，向消息中间件反馈确认应答，消息中间件便可以将该消息删除，表示该事务完成  
> 3、如果投递失败，增加重试机制，对重试失败的，写入错误消息表  
> 4、消息中间件需要提供失败消息的回查接口，下游系统会定期查询失败消息，自行消费。

优点：一种非常经典的分布式事务解决方案，最大限度保证最终一致性。  
缺点：消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。

## 2.4 TCC 事务 ##

TCC 即为 Try Confirm Cancel，它属于补偿型分布式事务，业务层面的分布式事务。其中：

> **Try**：指的是预留，即资源的预留和锁定。  
> **Confirm**：确认，其实就是真正的执行提交。  
> **Cancel**：撤销，就是回滚、撤销锁定动作。

同样，TCC模型也有一个全局的管理者或协调者角色，用来记录TCC全局事务状态，并提交或回滚事务。

TCC模型的难点在于业务上的定义，对每一个操作都需要定义三个动作分别对应 try-confirm-cancel例如，预留操作，需要明确预留或锁定的业务资源。因此TCC是业务耦合型分布式事务，需要根据特定的场景和业务逻辑来设计相应的操作。另外，确认或撤销操作可能需要重试，因此需要保证操作的幂等。

TCC相较于2PC、3PC，其优点在于可以**跨数据库**，**跨业务**来实现事务，但缺点也显而易见，就是开发量大，业务耦合度高。

TCC 两阶段提交与 XA 两阶段提交的区别：

> XA 是资源层面的分布式事务，强一致性，在两阶段提交的整个过程中，会一直持有资源的锁。  
> TCC 是业务层面的分布式事务，最终一致性，不会一直持有资源的锁。

[MySQL _]: https://blog.csdn.net/u014745069/article/details/103420050
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/a783885acce44f1eb3fdcf1e15134008.png
[Spring Cloud _ RocketMQ]: https://blog.csdn.net/u014745069/article/details/120606895?spm=1001.2014.3001.5501
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/ea65f38fd9e74fc6925e2f59353e073b.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/b52297c4e2504fc4b562e38f0f47ee16.png