分布式事务最经典的七种解决方案
Posted xhmj12
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式事务最经典的七种解决方案相关的知识，希望对你有一定的参考价值。
相关阅读：杭州程序员从互联网跳央企，晒一天工作和收入，网友：待一年就废
作者：叶东富
来源：segmentfault.com/a/1190000040321750
随着业务的快速发展、业务复杂度越来越高，几乎每个公司的系统都会从单体走向分布式，特别是转向微服务架构。随之而来就必然遇到分布式事务这个难题，这篇文章总结了分布式事务最经典的解决方案，分享给大家。
◆ 基础理论在讲解具体方案之前，我们先了解一下分布式事务所涉及到的基础理论知识。
我们拿转账作为例子，A需要转100元给B，那么需要给A的余额-100元，给B的余额+100元，整个转账要保证，A-100和B+100同时成功，或者同时失败。看看在各种场景下，是如何解决这个问题的。
◆ 事务把多条语句作为一个整体进行操作的功能，被称为数据库事务。数据库事务可以确保该事务范围内的所有操作都可以全部成功或者全部失败。
事务具有 4 个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID 特性。Atomicity（原子性）：一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被恢复到事务开始前的状态，就像这个事务从来没有执行过一样。
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。完整性包括外键约束、应用定义的等约束不会被破坏。
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。
◆ 分布式事务
银行跨行转账业务是一个典型分布式事务场景，假设A需要跨行转账给B，那么就涉及两个银行的数据，无法通过一个数据库的本地事务保证转账的ACID，只能够通过分布式事务来解决。
分布式事务就是指事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同节点之上。在上述转账的业务中，用户A-100操作和用户B+100操作不是位于同一个节点上。本质上来说，分布式事务就是为了保证在分布式场景下，数据操作的正确执行。搜索公众号互联网架构师回复“2T”，送你一份惊喜礼包。
分布式事务在分布式环境下，为了满足可用性、性能与降级服务的需要，降低一致性与隔离性的要求，一方面遵循 BASE 理论（BASE相关理论，涉及内容非常多，感兴趣的同学，可以参考BASE理论）：
基本业务可用性（Basic Availability）
柔性状态（Soft state）
最终一致性（Eventual consistency）
同样的，分布式事务也部分遵循 ACID 规范：
原子性：严格遵循
一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽
隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽
持久性：严格遵循
◆ 分布式事务的解决方案
◆ 两阶段提交/XA
XA是由X/Open组织提出的分布式事务的规范，XA规范主要定义了(全局)事务管理器(TM)和(局部)资源管理器(RM)之间的接口。本地的数据库如mysql在XA中扮演的是RM角色
第一阶段（prepare）：即所有的参与者RM准备执行事务并锁住需要的资源。参与者ready时，向TM报告已准备就绪。
第二阶段 (commit/rollback)：当事务管理者(TM)确认所有参与者(RM)都ready后，向所有参与者发送commit命令。搜索公众号互联网架构师回复“2T”，送你一份惊喜礼包。
目前主流的数据库基本都支持XA事务，包括mysql、oracle、sqlserver、postgre
XA 事务由一个或多个资源管理器（RM）、一个事务管理器（TM）和一个应用程序（ApplicationProgram）组成。
把上面的转账作为例子，一个成功完成的XA事务时序图如下：
如果有任何一个参与者prepare失败，那么TM会通知所有完成prepare的参与者进行回滚。
如果读者想要进一步研究XA，go语言可参考DTM，java语言可参考seata
◆ SAGA
Saga是这一篇数据库论文saga提到的一个方案。其核心思想是将长事务拆分为多个本地短事务，由Saga事务协调器协调，如果正常结束那就正常完成，如果某个步骤失败，则根据相反顺序一次调用补偿操作。
把上面的转账作为例子，一个成功完成的SAGA事务时序图如下：
SAGA事务的特点：
论文里面的SAGA内容较多，包括两种恢复策略，包括分支事务并发执行，我们这里的讨论，仅包括最简单的SAGA
SAGA适用的场景较多，长事务适用，对中间结果不敏感的业务场景适用
如果读者想要进一步研究SAGA，go语言可参考DTM，java语言可参考seata
◆ TCC
关于 TCC（Try-Confirm-Cancel）的概念，最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
Confirm 阶段：确认执行真正执行业务，不作任何业务检查，只使用 Try 阶段预留的业务资源，Confirm 操作要求具备幂等设计，Confirm 失败后需要进行重试。
Cancel 阶段：取消执行，释放 Try 阶段预留的业务资源。Cancel 阶段的异常和 Confirm 阶段异常处理方案基本上一致，要求满足幂等设计。
把上面的转账作为例子，通常会在Try里面冻结金额，但不扣款，Confirm里面扣款，Cancel里面解冻金额，一个成功完成的TCC事务时序图如下：
TCC的Confirm/Cancel阶段在业务逻辑上是不允许返回失败的，如果因为网络或者其他临时故障，导致不能返回成功，TM会不断的重试，直Confirm/Cancel返回成功。
TCC特点如下：
如果读者想要进一步研究TCC，go语言可参考DTM，java语言可参考seata
◆ 本地消息表
本地消息表这个方案最初是 ebay 架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章。设计核心是将需要分布式处理的任务通过消息的方式来异步确保执行。
大致流程如下：
写本地消息和业务操作放在一个事务里，保证了业务和发消息的原子性，要么他们全都成功，要么全都失败。
搜索公众号互联网架构师后台回复“2T”，获取一份惊喜礼包。
容错机制：
本地消息表的特点：
适用于可异步执行的业务，且后续操作无需回滚的业务
◆ 事务消息
正常发送的流程图如下：
补偿流程：
事务消息特点如下：
适用于可异步执行的业务，且后续操作无需回滚的业务
如果读者想要进一步研究事务消息，可参考rocketmq，为了方便大家学习事务消息，DTM也提供了简单实现
◆ 最大努力通知
发起通知方通过一定的机制最大努力将业务处理结果通知到接收方。具体包括：
可靠消息一致性，发起通知方需要保证将消息发出去，并且将消息发到接收通知方，消息的可靠性关键由发起通知方来保证。
最大努力通知，发起通知方尽最大的努力将业务处理结果通知为接收通知方，但是可能消息接收不到，此时需要接收通知方主动调用发起通知方的接口查询业务处理结果，通知的可靠性关键在接收通知方。
解决方案上，最大努力通知需要：
最大努力通知适用于业务通知类型，例如微信交易的结果，就是通过最大努力通知方式通知各个商户，既有回调通知，也有交易查询接口
◆ AT事务模式
这是阿里开源项目seata中的一种事务模式，在蚂蚁金服也被称为FMT。优点是该事务模式使用方式，类似XA模式，业务无需编写各类补偿操作，回滚由框架自动完成，缺点也类似AT，存在较长时间的锁，不满足高并发的场景。有兴趣的同学可以参考seata-AT
◆ 分布式事务中的网络异常
在分布式事务的各个环节都有可能出现网络以及业务故障等问题，这些问题需要分布式事务的业务方做到防空回滚，幂等，防悬挂三个特性，下面以TCC事务说明这些异常情况：
空回滚：
在没有调用 TCC 资源 Try 方法的情况下，调用了二阶段的 Cancel 方法，Cancel 方法需要识别出这是一个空回滚，然后直接返回成功。
出现原因是当一个分支事务所在服务宕机或网络异常，分支事务调用记录为失败，这个时候其实是没有执行Try阶段，当故障恢复后，分布式事务进行回滚则会调用二阶段的Cancel方法，从而形成空回滚。
幂等：
由于任何一个请求都可能出现网络异常，出现重复请求，所以所有的分布式事务分支，都需要保证幂等性
悬挂：
悬挂就是对于一个分布式事务，其二阶段 Cancel 接口比 Try 接口先执行。
业务处理请求4的时候，Cancel在Try之前执行，需要处理空回滚
业务处理请求6的时候，Cancel重复执行，需要幂等
业务处理请求8的时候，Try在Cancel后执行，需要处理悬挂
面对上述复杂的网络异常情况，目前看到各家建议的方案都是业务方通过唯一键，去查询相关联的操作是否已完成，如果已完成则直接返回成功。相关的判断逻辑较复杂，易出错，业务负担重。
在项目DTM中，出现了一种子事务屏障技术，使用该技术，能够达到这个效果，看示意图：
func ThroughBarrierCall(db *sql.DB, transInfo *TransInfo, busiCall BusiFunc)业务开发人员，在busiCall里面编写自己的相关逻辑，调用该函数。ThroughBarrierCall保证，在空回滚、悬挂等场景下，busiCall不会被调用；在业务被重复调用时，有幂等控制，保证只被提交一次。
子事务屏障会管理TCC、SAGA、XA、事务消息等，也可以扩展到其他领域
子事务屏障技术的原理是，在本地数据库，建立分支事务状态表sub_trans_barrier，唯一键为全局事务id-子事务id-子事务分支名称（try|confirm|cancel）
如果是Confirm分支，那么insert ignore插入gid-branchid-confirm，如果成功插入，则调用屏障内逻辑
如果是Cancel分支，那么insert ignore插入gid-branchid-try，再插入gid-branchid-cancel，如果try未插入并且cancel插入成功，则调用屏障内逻辑
在此机制下，解决了网络异常相关的问题
空补偿控制--如果Try没有执行，直接执行了Cancel，那么Cancel插入gid-branchid-try会成功，不走屏障内的逻辑，保证了空补偿控制
防悬挂控制--Try在Cancel之后执行，那么插入的gid-branchid-try不成功，就不执行，保证了防悬挂控制
对于SAGA事务，也是类似的机制。
该技术目前需要搭配DTM事务管理器，目前SDK已经提供给go语言的开发者。其他语言的sdk正在规划中。对于其他的分布式事务框架，只要提供了合适的分布式事务信息，能够按照上述原理，快速实现该技术。
◆ 总结
本文介绍了分布式事务的一些基础理论，并对常用的分布式事务方案进行了讲解，在文章的后半部分还给出了事务异常的原因、分类以及优雅的解决方案。
1、985副教授工资曝光
2、心态崩了！税前2万4，到手1万4，年终奖扣税方式1月1日起施行~
3、雷军做程序员时写的博客，很强大！
4、人脸识别的时候，一定要穿上衣服啊！
5、清华大学：2021 元宇宙研究报告！
6、绩效被打3.25B，员工将支付宝告上了法院，判了以上是关于分布式事务最经典的七种解决方案的主要内容，如果未能解决你的问题，请参考以下文章