Transaction - 事务分类总结

阅读目录(Content)

一、总结

1.本地事务 - “单个服务使用单个数据源”

实现原子性和永久性
实现隔离性

2.全局事务 - “单个服务使用多个数据源”（刚性分布式事务）

“两段式提交”（2 Phase Commit，XA 模式 2PC）协议
“三段式提交”（3 Phase Commit，XA 模式 3PC）协议

3.共享事务 - “多个服务使用单个数据源”
4.分布式事务 - “多个服务使用多个数据源” （柔性分布式事务）

可靠事件队列
TCC（Try-Confirm-Cancel）事务
SAGA事务

二、原文阅读
三、相关文章链接

回到顶部(go to top)

一、总结

把使用 ACID 的事务称为“刚性事务”

而把笔者下面将要介绍几种分布式事务的常见做法统称为“柔性事务”

1.本地事务 - “单个服务使用单个数据源”

实现原子性和永久性

提交日志 Commit Logging -- 对提升数据库的性能十分不利
提前写入 Write-Ahead Logging -- 进化方法

实现隔离性

Database - 数据库隔离级别

2.全局事务 - “单个服务使用多个数据源”（刚性分布式事务）

在本节里，全局事务被限定为一种适用于单个服务使用多个数据源场景的事务解决方案。请注意，理论上真正的全局事务并没有“单个服务”的约束，它本来就是 DTP（Distributed Transaction Processing）模型中的概念，但本节所讨论的内容是一种在分布式环境中仍追求强一致性的事务处理方案，对于多节点而且互相调用彼此服务的场合（典型的就是现在的微服务系统）是极不合适的，今天它几乎只实际应用于单服务多数据源的场合中，为了避免与后续介绍的放弃了 ACID 的弱一致性事务处理方式相互混淆，所以这里的全局事务所指范围有所缩减，后续涉及多服务多数据源的事务，笔者将称其为“分布式事务”。

XA 模式（XA 是 eXtended Architecture 的缩写）

“两段式提交”（2 Phase Commit，XA 模式 2PC）协议

“三段式提交”（3 Phase Commit，XA 模式 3PC）协议

为了缓解2PC的协调者的单点问题和准备阶段的性能问题

3.共享事务 - “多个服务使用单个数据源”

（该种情况极可能是伪需求）一种理论可行的方案是直接让各个服务共享数据库连接

4.分布式事务 - “多个服务使用多个数据源” （柔性分布式事务）

可靠事件队列

实现最终一致性。这种靠着持续重试来保证可靠性的解决方案，专业名词叫“最大努力交付”（Best-Effort Delivery）

优点：

能保证最终的结果是相对可靠的，过程也足够简单（相对于 TCC 来说）

缺点：

但整个过程完全没有任何隔离性可言。
如果业务需要隔离，那架构师通常就应该重点考虑 TCC 方案，该方案天生适合用于需要强隔离性的分布式事务中。

TCC（Try-Confirm-Cancel）事务

缺点：

TCC 是一种业务侵入式较强的事务方案
- 侵入性体现一：有更高的开发成本和更换事务实现方案的替换成本
- 侵入性体现二：所要求的技术可控性上的约束，（cuixunxu注：所有涉及的第三方模块必须完全配合你）
通常我们并不会完全靠裸编码来实现 TCC，而是基于某些分布式事务中间件（譬如阿里开源的Seata）去完成，尽量减轻一些编码工作量。

优点：

解决可靠事件队列无法提供隔离性的痛点
性能是本篇提及的几种柔性事务模式中最高的
灵活性更高。TCC位于用户代码层面，而不是在基础设施层面，可以根据需要设计资源锁定的粒度。

SAGA事务

SAGA 事务，是基于数据补偿来代替回滚的思路。

原本 SAGA 的目的是避免大事务长时间锁定数据库的资源，后来才发展成将一个分布式环境中的大事务分解为一系列本地事务的设计模式。

优点：

为了解决 TCC 侵入性体现二这个缺点。基于数据补偿来代替回滚。与 TCC 相比，SAGA 不需要为资源设计冻结状态和撤销冻结的操作，补偿操作往往要比冻结操作容易实现得多。
SAGA 事务通常也不会直接靠裸编码来实现，一般也是在事务中间件的基础上完成，前面提到的阿里开源的Seata 就同样支持 SAGA 事务模式。

回到顶部(go to top)