【《国内外分布式事务研究现状综述》7600字】

国内外分布式事务研究现状综述目录TOC\o"1-3"\h\u16752国内外分布式事务研究现状综述 1130091.1概述 1190951.2分布式事务概要理论 110811.1.1分布式事务 1180231.1.2数据一致性模型 273751.1.3CAP理论 3174591.1.4BASE理论 425331.3分布式事务模型及国内外研究现状 446421.3.1两阶段提交协议 416921.3.2TCC事务模型 6302161.3.3FMT事务模型 891941.3.4Saga事务模型 1015814参考文献 111.1概述本章首先介绍了分布式事务的概要理论，从分布式事务的概念开始，根据生产上对分布式事务需求的不断变化，介绍其在不断演进版本中背后的理论支持。最后引出基于这些理论的分布式事务模型及国内外关于此模型的研究现状，为本文后续的需求分析、设计实现做理论及模型上的支持。1.2分布式事务概要理论1.1.1分布式事务事务（Transaction）一般被定义为指所做的或者即将要做的事情。但是在计算机领域中是指一个程序执行单元(unit)，此执行单元发生在可能出现更删改查的各种数据项上。通常编程语言或者高级数据库操纵语言编写的程序执行会伴随事务的出现，并用形如开始事务begintransaction和结束事务endtransaction的语句或函数来作为边界界定。同时事务的组成也是由这些可以在数据库执行的一个个语句或函数全体执行操作组成。从事件操作执行的回滚以及并发角度来分析，事务也可以作为它们发生处理的基本单位。[摘自百度百科]深入分析事务的属性，可以概括为原子性A、一致性C、隔离性I、持久性D这四个方面。原子性（atomicity）：每个事务的操作执行都是一个整体。一个事务执行中的所有操作一起都做或者一起不做。一致性（consistency）：与原子性紧密相关。即事务执行操作完成后，相关数据项的状态改变是一个整体，不会存中间状态。隔离性（isolation）：不同事务在同一时间发生操作执行，他们对数据的改变是没有任何关联的。即每一个事务自身的操作执行及数据都是相互隔离的。持久性（durability）：持久性又被称作为永久性（permanence），它是指一个事务执行操作中的相关数据项一旦被提交，那么在此数据项在数据库中的改变就是永久性的。任何操作即使是出现故障也不会对持久后的数据有任何影响。图1.SEQ图2.\*ARABIC1分布式事务模型图如图1.1分布式事务模型图所示，描述的是一个最基本的分布式系统中事务在系统各节点中传播的模型。由此分布式事务模型可以看出，在分布式系统中所有参与事务的服务器、资源服务器以及事务管理器等处理事务的节点分布系统中的不同节点上，一般情况下一个分布式事务会对多个业务系统的进行操作，其中就会包含多个数据源。对于一个分布式事务中涉及的在各个业务系统中的事务操作，可以看做成子事务。由此可知在整个分布式事务处理中，每个子事务的操作执行发生在不同的业务系统节点上，因此设计分布式事务处理系统显的十分复杂。1.1.2数据一致性模型分布式系统通常采用数据副本的方式来提高整个分布式系统的容错性和可靠性。对于数据副本的方式，就是将数据拷贝后形成不同的副本保存在不同的分布式系统节点机器中，由于在维护数据副本一致性上代价过高且影响整体系统性能，许多分布式系统采用弱一致性的方案来提高性能。随着业务场景的对于数据一致性的要求不断升级，数据一致性模型方案也随之不断适应和演进。通过对数据一致性模型的研究了解，可以大致分为以下三类：强一致性：当更新操作发生后，数据在数据库中被变更，此时不论何时读取都能获取到最新数据。弱一致性：更新操作在一个副本中执行，但是用户不会在第一时间读取到已经更新的数据，而是在一定时间后才能读取到最新数据，我们称这段时间为“不一致性窗口”。最终一致性：当发生数据更新操作时，虽不能确保用户能够立即读取到最新数据，但可以保证用户在最终能够读取到更新的数据。1.1.3CAP理论解决分布式事务问题，还需要了解分布式系统中的CAP理论。CAP原理是由EricBrewer在1999年他的论文《Harvest,yield,andscalabletolerantsystems》中提出。该论文的核心思想是在建设分布式系统时需要考虑CAP这三大指标：图1.SEQ图2.\*ARABIC2CAP理论模型图一致性（Consistency）：一个事务执行完数据库任何操作后，操作完成且状态成功，在此之后其他任何事务读取此数据的结果是完全一致的，不存在中间状态。可用性（Availability）：对于系统服务而言必须时刻处于可用状态，在收到用户的请求后，系统服务器必须在一定的时间内给出回应，不论处理结果的成功与否。分区容错（Partitiontolerance）：一般情况下在一个分布式系统里，其中一个流程可能会无法避免的存在某个服务操作失败处理情况，对于这种情况需要在设计之初考虑如何容忍此种问题的发生。根据CAP理论分布式系统中是无法同时满足这三个属性的，一般会根据设计目标及使用场景特点选择其中的两个特性。在大多数的系统架构设计中，P分区容错作为架构模式下的基本原则，都会选择CP或者AP模式。所以C一致性和A可用性的解决方案就成了分布式系统建设中最需要权衡的痛点。那么为何不能够同时满足A可用性和C一致性的特性，下面基于分布式架构特点来分析，不同服务之间的调用是不能保证通信是100%成功，一旦出现通信失败情况，C一致性和A可用性就无法被满足。既然强一致性始终无法保证，那么以时间换空间，如果能够在最后结果保证一致性，系统也可以接收，此时就演进出了BASE理论。1.1.4BASE理论基于以上CAP理论，并对CAP理论中的一致性和可用性进行深入分析，eBay公司的架构师最终提出了BASE理论。其理论主要表述的是：如果无法在系统中做到数据强一致性，那么每个应用可以根据自身业务场景的特点，采用合适的策略来实现分布式系统中数据的最终一致性。BASE理论是以下特性的缩写，即基本可用、软状态、最终一致。基本可用（BasicallyAvailable）：在分布式系统不论发生任何系统问题时，都要保证整个分布式系统仍然可用。软状态（SoftState）：指分布式系统中允许部分数据在处理中存在中间状态，但是这些中间状态不会影响到整个分布式系统的可用性。而硬状态要求分布式系统中多个节点对应的数据副本都必须保持数据一致性。最终一致（EventualConsistency）：就是在执行完数据库操作后，分布式系统中所有节点对应的数据副本在过了数据同步的一段时间后，所有分布式系统节点都能够查询到最新的数据，即最终整个分布式系统达到了数据一致性。而在最终同步的这段时间长短取决于业务场景要求及硬件上的延时、负载等各种因素。BASE理论的提出是源于大规模分布式系统架构需求，与传统的关系型数据库的数据强一致性模型不同，通过允许数据在一段时间内是不一致的状态来换取系统的高可用性。所以在做系统架构设计时，还是需要根据实际业务场景对事务处理做权衡考虑。基于BASE理论，为了能够满足本文系统设计的大数据量高并发要求，在本文的分布式事务模型设计方案中，采用节点内部服务TCC事务模型与节点之间服务处理Saga事务模型的方式处理分布式事务，为了获得更好的系统性能，选择放弃强一致性，采用最终一致性方式。1.3分布式事务模型及国内外研究现状1.3.1两阶段提交协议在\t"/item/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/_blank"计算机和\t"/item/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/_blank"数据库领域内，二阶段提交（Two-phaseCommit）是指在\t"/item/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/_blank"分布式系统下所有节点在进行分布式交易时对应事务提交时为了保证数据一致性而设计出的\t"/item/%E4%BA%8C%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/_blank"算法。一般情况下，也可被称为是一种协议(Protocol)。简单说二阶段提交算法思路可描述为：参与者将操作结果（成功或者失败）通知协调者，此时协调者收到所有参与者的通知反馈后，会决定所有参与者接下来提交还是中止操作。[摘自百度百科]使用二阶段提交算法需满足以下条件：1.通常在分布式系统设计中，事务采用集中管理方式，即设置系统中的一个节点作为分布式事务处理的协调者，其他所有节点就可认为是分布式事务处理的参与者。1.所有节点在事务操作中都需采用预写式日志，当日志被写入完成后即落盘到当前节点上的可靠存储设备上，即使当前节点损坏也不会造成存储设备上的日志数据丢失。3.各个节点网络通信正常，所有节点即使损坏仍可及时恢复。图1.SEQ图2.\*ARABIC3二阶段提交算法图如图1.3二阶段提交算法图所示，以下对此进行说明。第一阶段（提交请求）：协调者节点如果想要执行提交操作，必须等待所有的参与者节点的响应反馈。各参与者节点在收到协调者请求后会将需要提交的操作信息和回滚操作信息写入到日志中，同时响应协调者。当前参与者节点根据当前事务实际操作执行成功与否，返回给协调者一个"commit"或"abort"的消息。第二阶段（提交执行）：当协调者节点收到所有参与者响应消息都为"commit"时，会通知所有参与者节点可以发起"正式提交"，此时各个参与者节点可以执行提交操作，同时释放掉当前仍在占用的资源，最后反馈给协调者节点"完成"消息。当协调者节点收到所有参与者的"完成"消息后，整个分布式事务最终完成；如果任一参与者节点的响应超时或者异常，协调者节点就会向所有参与者都发出"回滚操作"的请求，此时参与者节点必须执行回滚操作，同时也需要释放掉仍在占用的资源，最后通知协调者节点已经"回滚完成"消息，协调者节点在收到所有参与者反馈的"回滚完成"消息后，会确认整个分布式事务已经取消。二阶段提交协议的缺点：在于整个事务执行的过程中，所有节点都处于阻塞状态。这势必会造成很大的资源占用损耗。另外协调者节点在第二阶段没有收到各参与节点执行正式提交的反馈时会再次指示所有参与者进行回滚操作。这样的策略虽然保全了数据一致性但是使用起来不够灵活。很显然在当前大规模线上分布式系统，两阶段提交协议的缺点远大于优点，故开源及商业化软件市场，基本上没有提供基于此理论模型的产品。1.3.2TCC事务模型关于TCC事务模型，其中TCC是Try-Confirm-Cancel的缩写。相关概念最早是在2007年由PatHelland发表的一篇名为《LifebeyondDistributedTransactions:anApostate’sOpinion》的论文中提出，最初在该论文中，TCC的名称是Tentative-Confirmation-Cancellation。正式以Try-Confirm-Cancel作为名称的，是在GregorHohpe所著书籍《EnterpriseIntegrationPatterns》中。相比于传统事务机制（如X/Open组织定义的XA规范及Two-Phase-Commit），TCC事务处理机制的特点是不用依靠新建的资源管理器(RM)对XA协议的支持，而是通过设计业务系统中有关事务处理的业务逻辑来最终实现分布式事务。为了满足TCC事务处理机制，业务系统中特定的业务逻辑A在对外提供的服务包括正交易操作以及取消正交易操作的反交易操作，那么调用它的消费方服务M既可以调用正交易操作又能够调用反交易进行回滚取消。当M认为全局的事务应该被回滚，它会再次调用反交易操作，要求回滚之前发生的正交易操作；当M认为全局事务应该提交时，它就不会再次调用反交易操作，此时对应A的正交易就是确认操作。对于每一个操作，最终都会被提交或回滚。因此，针对具体的业务逻辑服务，TCC事务机制需要业务方系统配合提供Try-Confirm-Cancel三段业务逻辑：即尝试操作Try、确认操作Confirm、取消操作Cancel。图1.SEQ图2.\*ARABIC4TCC事务模型如图1.4TCC事务模型所示，TCC事务模型三个操作阶段的操作执行要点。以下将分阶段进行阐述。1)尝试操作（Try）阶段：即是尝试执行任务。业务逻辑的设计一般为完成所有业务检查确保整体数据一致性，并预留相关的业务资源，此过程要保证隔离性；最后会执行当前调用的正交易服务。2)确认操作（Confirm）阶段：确认操作（Confirm）是对尝试操作（Try）的执行确认。业务逻辑的设计上通常是当事务管理器决定提交全局事务时，首先就会逐个对尝试操作（Try）进行确认操作（Confirm），整个过程只会用尝试操作（Try）阶段中所预留的业务资源，在做提交操作时也会需考虑满足其幂等性，是真正的将执行的业务提交。3)取消操作（Cancel）阶段：取消操作（Cancel）是取消执行的业务。简单来说此阶段是调用业务系统中的反交易操作，释放尝试操作（Try）中预留的业务资源，在回滚Cancel操作是也需要考虑可能从出现的幂等性问题。在传统的事务机制中，事务管理器中的事务处理逻辑仅关注业务处理提交commit或回滚rollback阶段，而不会关注业务尝试执行阶段。相比传统事务机制，TCC事务模型中对于业务逻辑操作和对事务的处理，需关注这三个不同阶段的不同业务处理逻辑，其关系本身就十分复杂：即业务逻辑在TCC所有阶段都会涉及所有参与者中资源事务的提交commit/回滚rollback；而相对于全局事务提交commit/回滚rollback时又会影响到业务逻辑TCC所有阶段的执行。由此可以看出TCC事务模型在整个使用过程中对业务更具有高度侵入性。TCC事务模型国内外研究现状国内对于TCC的最早布道，应该是InfoQ平台早期对阿里巴巴CTO程立博士的一篇采访录。现在历经多年的生产及演进，TCC事务模型的产品也逐渐成熟并可以提供出商业化版本供大规模分布式系统使用。国内比较出名的商业化产品如阿里云的全局事务服务GTS，提供手动与自动两种事务处理模式。此产品对应的开源版本即是Seata，也在不断的完善中。开源的TCC事务模型产品最早被大家最熟悉的莫过于是TX-LCN，其现在发展到已经可以在多种流行业务开发框架直接进行引入，提供分布式事务服务处理。TCC事务模型除了会对业务具有侵入性外，其良好的分布式事务处理表现让基于TCC事务模型的产品也有更好的发展空间。1.3.3FMT事务模型FMT事务模型全名是：Framework-managedTransaction，通常情况下该模式是通过数据库锁策略来完成分布式事务的管理。对比来看，FMT事务模型与TCC事务模型的事务协调器TC并无差异，仅在资源管理器RM操作层面与TCC产生差异。以下通过FMT事务模型产品来了解FMT事务模型中的处理机制。FMT事务模型国内外研究现状国内外有很多产品已经实现了基于FMT事务模式的分布式事务产品，如蚂蚁金融云SOFA框架与腾讯云DTF框架都提供了FMT事务模型的分布式事务处理能力。下面以腾讯云的DTF框架为例介绍FMT事务模型。FMT事务模式下，DTF通过框架解析当前交易的SQL语句，免去了编写Confirm/Cancel方法的烦恼，接入使用便捷，对代码无侵入，助您高效完成业务分布式事务的开发。对于FMT执行流程，如图1.5腾讯云DTF事务框架事务处理流程图所示，DTF框架会代理数据驱动层，执行流程如下：图1.SEQ图2.\*ARABIC5腾讯云DTF事务框架事务处理流程图执行正常逻辑时，可以理解为Try阶段。框架解析SQL语句，生成SELECT语句和UNDO语句模板，等待全局锁，然后在同一个本地事务中：注册分支事务、查询前象、执行SQL、查询后象、记录UNDOLOG。如果过程中出现异常，则会释放全局锁，否则会等待分支事务提交/回滚时再释放全局锁。Confirm过程相对简单，删除UNDOLOG并释放全局锁即可。Cancel过程稍微复杂，先要检查当前数据是否符合Try中查询的后象，然后执行UNDO语句，再检查数据是否符合Try中查询的前象，最后删除UNDOLOG并释放全局锁。

如果出现前象或者后象不一致时，回滚本地事务，不释放全局锁，等待人工介入异常事务。DTF框架的FMT模式支持可重入锁，可以处理更复杂的应用场景。举例如下：在一条主事务中，多个分支事务对数据表中某一行数据进行了多次操作：增（create）、改（update可能多次）、删（delete），此时会涉及到可重入锁的问题。实际场景：在一次交易中，新增了一条订单数据，而本次交易又涉及到其他操作（其他分支事务），需要修改本条订单数据。这种场景下，如果需要回主事务，会涉及到按倒序回滚改操作、增操作，即反向执行可重入锁。为了保证事务一致性，FMT会在业务操作某一行数据时进行锁行，在重入锁的场景下，会涉及到生成多次行锁。虽然FMT事务模型采用数据库行锁策略的方式解决了分布式事务问题，但是其缺点也很明显，即需要多次访问数据库生成、查询、执行SELECT和UNDOLOG等其他事务处理语句增加数据库的链接及查询耗时。同时通过行级锁的策略势必会造成并发执行的强制等待，整个分布式事务处理性能会受到影响。1.3.4Saga事务模型早在1987年的普林斯顿大学，事务研究员HectorGarcia-Molina和KennethSalem发表了一篇名为《Sagas》的论文，该论文讲述的是如何处理long-lived-transaction（长活事务），并首次将此命名为Saga事务模型。从此Saga被定义为一个长活事务，同时也是一个可以被分解成多个可以穿插运行的子事务集合，对于集合中的每个子事务，都是能够保证数据库相关数据一致性的一个真实事务。一般来说，子事务其实是本地事务，子事务集合其实也就是由多个本地事务组成，而相对应的每个本地事务都有属于自己业务的执行模块及补偿模块。而当任意一个子事务（本地事务）报错时，都可以通过调用此子事务对应的补偿方法进行事务恢复，由此而达到Saga分布式事务的数据最终一致性。对于通过补偿方法恢复事务状态，Saga事务模型定义了两种恢复策略：向后恢复（backwardrecovery）：补偿Saga事务中所有的已经完成的子事务。如果子事务集合中任意子事务发生报错异常，将会从调用此子事务的服务开始调用自身补偿方法进行事务撤销，直至所有成功调用的子事务都被撤销，进而保证整个Saga事务最终完全被撤销。向前恢复（forwardrecovery）：通过重试的方式反复处理发生失败的事务直至处理成功。适用于业务上要求必须成功的场景。假设每个子事务最终都会成功。如果任意一个子事务发生失败，调用此子事务的服务将会再次调用此子事务直至最终此子事务成功，进而保证整个Saga事务正交易上最终成功。显然，如果你的业务场景中，要求子事务必须成功，向前恢复的策略更符合业务需求。或者出现补偿事务无法定义，那么向前恢复的策略可能就没有必要提供对应的补偿处理。而对于向后恢复策略，虽然理论上补偿事务不会出现失败，但却在实际场景中，分布式系统的多节点可能会出现任何不可预期的问题都可能会导致补偿事务中断，此时我们需要采用备用的方案进行人工干预，如如人工回退方案等。从整个Saga事务模型来看，其设计原理基于BASE理论，满足基本需求，且对比TCC事务模型，业务侵入性小；Saga事务模型没有预留资源不用担心资源释放的问题；子事务都是真实执行，不需要再次提交commit或者回滚callback，异常处理也比较简单；反过来看Saga事务模型还有一些缺点：由于缺少预留动作，每次操作都是真实执行，会导致数据在一定时间内不一致，补偿动作的实现需要考虑业务场景特点比较麻烦；另从数据隔离性上看，Saga不保证整体事务的ACID，只保证服务的基本可用和数据处理的最终一致性，事务隔离性相对较差，如果要保证数据不被脏读脏写等脏化操作需要在业务逻辑上进行相应的处理（如进行幂等操作）。Saga事务模型国内外研究现状Saga事务模型是商业产品及开源市场比较受欢迎的分布式事务解决方案之一，目前开源市场上比较出色的框架有华为的ApacheServiceCombSaga。对比TCC等其他事务模型，Saga事务模型的低侵入性在集成其他业务框架使用性上显得更加灵活，但考虑到此模型的隔离性差、没有预留动作等缺点，基于Saga事务模型的产品还需要逐步完善优化。参考文献[1]\t"/en/Detail/index/WWMERGEJ01/_blank"PatHelland,LifebeyondDistributedTransactions:anApostate’sOpinionPositionPaper.[J]\t"/en/Detail/index/WWMERGEJ01/_blank"COMMUNICATIONSOFTHEACMVolume60,Issue2.2017.PP46-54[2]GregoryChockler; AlexeyGotsman,Multi-shotdistributedtransactioncommit.[J]DistributedComputing2021.PP1-18[3]LifebeyondDistributedTransactions:anApostate’sOpinionPositionPaperPatHellandAmazon.Com705FifthAveSouthSeattle,WA98104USA[4]HectorGarcia-Molina,KennethSalem,Sagas.DepartmentofComputerScience,PrincetonUniversity,Princeton,NJ.08544,CS-TR-070-87,January1987[5]AFox，EABrewer,Harvest,yield,andscalabletolerantsystems.WorkshoponHotTopicsinOperatingSystems.06August2002[6]P.Sauter,I.Melzer,Acomparisonofws-businessactivityandbpel4wslong-runningtransaction,InProceedingsofKommunikationinVerteiltenSystemen,pages115-125,2005.[7]GrahamChen,DistributedtransactionprocessingStandardsandtheirapplications,ComputerStandards&Interfaces,1995,pp.363-373[8]CMohan，RayHStrong，SJF