【《分布式事务处理模型需求及概要设计案例分析》10000字】

分布式事务处理模型需求及概要设计案例分析目录TOC\o"1-3"\h\u27207分布式事务处理模型需求分析及概要设计案例分析 1195801.1系统概述 2310561.2系统需求分析 371491.3系统设计目标 937051.4系统设计的关键点及权衡点 10262671.4.1服务接口的暴露问题 10210081.4.2Saga面临的隔离性问题 10272821.4.3事务上下文传播 11115501.4.4事务处理切面 11110611.4.5事务故障恢复 12250701.4.6网络超时问题 13256531.4.7性能优化 13321881.5系统概要设计 13217611.5.1系统架构设计 1353311.5.2事务数据结构设计 15125241.5.3事务处理流程设计 191.1系统概述该分布式事务处理模型被设计出用于解决大型电商平台中的分布式事务问题。如图1.1某大型电商平台订单服务分布式事务模型所示，该订单服务请求及响应中涉及多个数据库的修改，首先从网关请求订单服务开始，新增订单记录，并对库存进行扣减，随后调用支付路由服务进行支付结算，此时记录支付信息，调用会计记账服务进行会计分录信息记账，然后调用积分服务积累用户的积分，最后更新订单完成状态，返回请求。整个过程至少涉及到四个数据库的操作，为了保证整个交易的数据一致性，就必须解决分布式事务问题。图1.SEQ图3.\*ARABIC1某大型电商平台订单服务分布式事务模型为了解决分布式事务问题，该系统采用了基于消息队列的Saga分布式事务模型的解决方案，通过对整个事务的层层分割将其变为一个可控的长事务最终保证了系统整体数据的一致性。系统最终被设置成为一个通用框架，当业务方需要使用分布式事务时，只需引用该框架的Jar包，按照接口规范及框架要求进行配置，框架就会自动使用基于消息队列的Saga分布式事务模型的解决方案，无需人工干预。1.2系统需求分析从基于消息队列的Saga分布式事务模型的使用者出发进行分析，当前的分布式事务模型面向以下三种用户：主事务方（最初交易的事务发起方），从事务方（交易被调用方），运维开发人员。主事务方和从事务方都是交易的参与者，主事务方发起交易并产生根节点事务，在调用其他服务时添加事务的参与者，并传播事务上下文，通过最终结果，对根事务进行提交及回滚，如遇事务中断，则可根据事务日志进行中断事务恢复。根据以上主事务方系统对事务处理的描述，得出图1.2主事务方系统用例图如下：图1.SEQ图3.\*ARABIC2主事务方系统用例图如上述用例图描述可知，主事务方系统用例图主要包含五个部分：根事务管理、添加事务参与者、传播事务上下文、恢复中断事务、事务日志管理。其中根事务管理包含三个子系统，即发起根事务，提交根事务，回滚根事务。以下是对用户图包含的几个部分的关键进行用例描述。发起根事务的用例描述如表1.1所示：表1.SEQ表3.\*ARABIC1发起根事务用例描述表提交根事务的用例描述如表1.2所示：表1.SEQ表3.\*ARABIC2提交根事务用例描述表回滚根事务的用例描述如表1.3所示：表1.SEQ表3.\*ARABIC3回滚根事务用例描述表添加事务参与者的用例描述如表1.4所示：表1.SEQ表3.\*ARABIC4添加事务参与者用例描述表传播事务上下文的用例描述如表1.5所示：表1.SEQ表3.\*ARABIC5传播事务上下文用例描述表恢复中断事务的用例描述如表1.6所示：表1.SEQ表3.\*ARABIC6恢复中断事务用例描述表在主事务方调用第一个从事务方后，从事务方通过主事务方传递的分布式事务上下文信息，进行分支事务的创建，根据当前交易场景调用下一级从事务方，并进行分布式事务信息传递，直至最后一级的从事务方。根据当前从事务方处理的最终结果进行分支事务的提交与回滚。根据以上从事务方系统对事务处理的描述，得出图1.3从事务方系统用例图如下：图1.SEQ图3.\*ARABIC3从事务方系统用例图如上述用例图描述可知，从事务方系统用例图主要包含两个部分：分支事务管理、事务日志管理。其中分支事务管理包含三个子系统，即发起分支事务，提交分支事务，回滚分支事务。以下是对用户图包含的几个部分的关键进行用例描述。发起分支事务的用例描述如表1.7所示：表1.SEQ表3.\*ARABIC7发起分支事务用例描述表提交分支事务的用例描述如表1.8所示：表1.SEQ表3.\*ARABIC8提交分支事务用例描述表回滚分支事务的用例描述如表1.9所示：表1.SEQ表3.\*ARABIC9回滚分支事务用例描述表分布式事务在整个分布式系统中处理难免会出现异常，故提供一个分布式事务运维平台对于开发运维人员是十分必要的。本系统提供分布式事务运维平台对中断的事务进行查询及处理，并可对中断的分布式事务恢复设置重试次数，配置事务恢复策略等。根据以上描述，得出图1.4分布式事务运维系统用例图如下：图1.SEQ图3.\*ARABIC4分布式事务运维系统用例图如上述用例图描述可知，分布式事务运维系统用例图主要包含三个部分：查看中断事务、重置事务恢复次数、配置事务恢复策略。以下是对用例图包含的几个部分的关键进行用例描述。查询中断事务的用例描述如表1.10所示：表1.SEQ表3.\*ARABIC10查询中断事务用例描述表重置事务恢复次数的用例描述如表1.11所示：表1.SEQ表3.\*ARABIC11重置事务恢复次数用例描述表配置事务恢复策略的用例描述如表1.12所示：表1.SEQ表3.\*ARABIC12配置事务恢复策略用例描述表1.3系统设计目标通过对系统进行需求分析，同时结合系统的应用场景，最终确定了系统设计要完成以下目标：数据最终一致性：该分布式事务系统的设计必须满足数据一致性，这是分布式系统的最基本要求。对于分布式系统中的数据分布在各个子系统及数据库中，强一致性的数据要求势必会造成分布式系统性能的严重下降，数据的最终一致性的设计在满足分布式系统性能的基础上又可提升用户体验，是建设分布式系统不错的选择。故本系统建设采用数据最终一致性的策略。满足ACID要求：一个逻辑单元必须满足ACID才能称得上事务。对于分布式事务系统的设计，只有满足ACID的要求，才能使得设计没有缺陷。当前设计中采用BASE理论，即BasicallyAvailable(基本可用)、Softstate(软状态)和Eventuallyconsistent(最终一致性)。高吞吐性：结合当前大型商城订单服务的场景，此场景具有用户多，数据量大，并发高的特点，故要求系统具备高吞吐性。对于主流传统的几种事务模型不能在满足高吞吐量的同时又符合ACID要求中做好平衡。大多数事务模型都是根据使用场景进行取舍，例如主流的TCC模型，在交易遇到异常进行cancel操作时需要确认所有回滚操作完成后才能正常退出算完成交易，此过程中易于出现问题导致回滚事务中断，且此过程时间较长，进一步影响吞吐量。采用基于消息队列的Saga分布式事务模型，可以将事务分割成各个小事务，根事务只需确保自己完成回滚后即可释放占用的交易连接，通过中间件确保每个小事务正常完成回滚，进而提高吞吐量。降低代码侵入量：该分布式事务系统的设计必须简单易用，在完成分布式事务处理的基础上必须考虑尽可能的减少对业务代码的侵入量。使开发人员可以直接引用，不用在业务代码中耦合分布式事务相关的细节处理。让开发人员可以更多的关注业务代码的逻辑，降低使用分布式事务框架的错误率，提高开发效率。不依赖已有的分布式框架：当前主流的分布式框架提供的功能十分丰富，使用起来十分方便，但在不同的场景下分布式框架提供的功能并不一定都能适用，势必会要求开发人员根据场景进行框架的改造。众所周知，越成熟的框架改造的难度越大。故本分布式事务框架设计基于最基本的开源SpringBoot框架，提供基本的分布式事务解决方案，后期根据场景进行优化更加方便。提供基于注解的配置：注解是JDK首创，用于替代繁琐的配置文件解读。采用注解的方式，通过切面的拦截来完成特定操作。本系统设计中也使用自定义注解，通过注解中约定的一些属性，对业务代码使用注解的特定位置进行分析执行特定操作。1.4系统设计的关键点及权衡点本系统选择基于消息队列的Saga分布式事务解决方案。通过消息队列将事务进行分割，实现Saga分布式事务模型，通过选用消息队列至少推送一次消息的模式，保障事务处理的准确完成。同时消息队列在其中也扮演着解耦的角色，提高整体系统的吞吐量及性能。理论设计如此，但在具体设计时需具体进行系统设计分析，分析其中的关键点，并进行必要的设计权衡考虑。1.4.1服务接口的暴露问题在基于消息队列的Saga事务模型中，事务框架提供出三个基类，所有分布式交易类必须继承。事务框架会自动进行根事务的创建，根据需求调用分支事务方并可逐层调用分支事务方系统，在下一级分支事务完成返回后，本级的事务方才能够提交事务再返回上一层事务调用方，直至主事务方的根事务提交事务完成交易。在出现异常时，可立即逐层对直接调用方回滚事务，但对于其他非直接调用方可依托消息队列进行异步回滚事务。根据以上模型设计，引用分布式事务Jar后，在业务系统需要分布式事务的交易中继承分布式事务基类，重写逻辑交易方法即可，其他事务处理逻辑交由分布式Saga模型完成。无需暴露事务框架接口给业务方系统。此种设计减少因为接口暴露导致的安全隐患，提高系统的可扩展性。1.4.2Saga面临的隔离性问题Saga事务模型采用幂等的方式解决在分布式系统中由于网络请求可能的延时带来的问题。在服务请求的过程中可能会出现超时重试的情况，此时采用幂等方案来避免多次相同请求带来的问题。当Saga事务模型发生并行处理时，如果交易在发生超时重试后进行了回滚取消操作（又叫补偿操作），那么该取消回退操作是直接生效的，这就是补偿可交换原则。为了满足补偿可交换原则，我们在设计系统之处就应该考虑如何保留分布式交易中的所有事务数据。通过以上分析，可知Saga事务模型只支持ACD，不保证交易的隔离性。那么缺乏隔离性会带来哪些问题？基本上是并发交易带来的数据的脏读、幻读，进而导致数据覆盖更新而出现的不准确。在基于消息队列的Saga事务模型中，采用以下几种方式解决隔离性问题：对多次请求调用采用幂等校验的方式；应用层面采用分布式逻辑锁保证交易的串行化；资金扣减采用冻结金额的方式保证资金占用；如果发生超时重试事件后需进行补偿操作等等。1.4.3事务上下文传播当前基于消息队列的Saga事务模型中，事务上下文的传播主要分为以下两个部分：一是主事务方系统调用从事务方系统，根事务信息与分支事务信息逐层向下传播。正常分布式交易情况下，主业务方的角色为事务发起者，从业务方为事务参与者，在分布式事务流程中，事务发起方会先创建根事务，同时也需要将事务上下文传播给事务参与者，事务参与者会根据事务上下文创建分支事务并做相应的处理，所以在整个分布式事务流程中，事务上下文的传播是非常重要的环节。在不依赖特定的分布式服务框架情况下，可以基于方法参数的形式进行事务上下文的传递。二是回滚事务时，从最后被调用的事务方开始，逐层向上将分支事务信息传播。对于分布式交易的异常情况，最后被调用的从事务方系统作为分布式事务回滚的起点，在完成正常回滚后通过消息队列异步逐层向上将分支事务的信息传递下去，直至整个分布式事务完成回滚。同样在不依赖特定的分布式服务框架情况下，可以基于方法参数的形式进行事务上下文的传递。1.4.4事务处理切面在基于消息队列的Saga事务模型中，不同的节点扮演着不同角色，主业务方作为事务发起者的角色，其在分布式事务处理过程中，控制着整个事务处理流程，在事务发起之初，首先会创建并存储根事务，然后执行Try操作，接着将事务传播到从业务方。从业务方作为事务参与者的角色，在获取到事务上下文后，会创建并保存分支事务，如需可调用下一级的从事务方系统，当所有的从事务方系统完成交易后，主业务方会根据从业务方完成结果来进行全局事务的提交或者回滚。随着调用顺序的不同，业务节点的角色也会随之切换，同一个业务节点在一个事务处理中为事务发起者，在另一个事务处理中可能为事务参与者。从上面的描述中可以看到，不管是主业务方还是从业务方，其对应的事务处理操作都在业务服务处理前后进行，所以可以利用AOP(面向切面编程)思想，设置事务处理切面，对业务服务处理接口进行拦截，将事务处理相关操作提取到事务拦截器中，本系统就是利用Spring提供的AOP功能，建立事务拦截器，对事务处理操作进行抽取，避免了开发人员进行重复的事务处理工作。当业务服务需要进行分布式事务处理时，开发人员只需要继承分布式事务框架中的相关基类，同时配置事务注解，事务系统就会自动对分布式事务进行处理，不需要开发人员做任何事务相关的接口调用工作。1.4.5事务故障恢复在一切都正常的情况下，事务发起者发起根事务，并将事务上下文传播到事务参与者，事务参与者发起分支事务，并根据需要逐层调用下一级从事务方，在最后一级从事务方完成处理后，再逐层向上返回事务处理结果，收到返回结果的上一级调用事务方根据执行情况来进行事务的提交或者回滚，当所有节点都执行成功，则发起Confirm操作，如任意节点的操作失败，则发起Cancel操作，然后整个分布式事务结束，数据的最终一致性得到了保证但是系统在实际运行过程中可能出现各种故障。当事务处理系统进行事务补偿时，业务系统出现了网络问题或者硬件故障，没有成功执行Confirm操作或者Cancel操作，导致事务补偿失败，此时系统中就会出现中断事务，导致系统中的数据处于不一致的状态因此该系统应该具各相应的故障恢复机制。事务故障恢复的基础是做好事务日志的记录，事务处理系统需要记录主业务方的根事务完成情况，同时也要记录从业务的分支事务完成情况，当系统发生故障导致事务中断时，就可以根据事务日志获取该事务的完成情况，对其进行恢复操作，保证全局事务顺利完成。本系统提供了定时恢复任务，定期查询未完成的事务，并对其进行恢复处理。1.4.6网络超时问题网络超时问题会导致从业务方事务处理的最终结果调用方无法得知，故会造成交易无法满足预期，数据不一致等问题。网络超时问题也可分为两种情况：一是正常交易处理过程中出现上级事务调用方与下级事务被调用方超时。此时调用方可直接认为交易处理失败，然后进行事务回滚，逐层向上事务回滚。被调用方在处理完成后可校验根事务状态，如确认根事务状态为回滚状态则需发起事务回滚。二是回滚交易时当前事务回滚操作出现超时。此时当前事务正常做回滚，并记录当前回滚交易回滚状态，当事务恢复器会再次发起事务回滚，回滚事务交易需做幂等校验，如成功则继续下一层级的事务回滚，如失败可继续当前事务的回滚。直至所有分布式事务完成回滚操作。1.4.7性能优化该系统的性能影响着事务处理速度，进而影响着系统的事务吞吐量。同时，系统的性能也影响着业务系统的响应时间，进而影响着用户的体验虽然基于消息队列的Saga事务模型的事务处理方案性能较好，不存在务操作阻塞情况，但是还是需要在设计中进一步进行性能优化，以适应高并发场景的需要，同时也可以提高用户的体检。通过对本系统设计的分析，当事务处理过程中出现异常时，事务的回滚是通过消息队列进行异步操作，异步操作的时间可能在一定程度上影响整体分布式事务回滚的时间，在一定程度上可能会影响正交易，可采用两种办法进行优化：一是根据RocketMQ特性，可以对每个被调用的从事务方设置一个对应的topic，增加多个消息监听，进而加快事务回滚的速度。二是分析被调用交易是否有顺序关系，如有则需严格按照顺序进行事务回滚，如无则可将所有没有顺序的被调用方进行同时事务回滚，在一定程度上提供回滚效率和速度，进而提升了其性能。1.5系统概要设计1.5.1系统架构设计通过当前的设计目标以及Saga模型的优缺点等，进行关键点与权衡点的阐述。图1.SEQ图3.\*ARABIC5分布式事务Saga模型系统架构图如图1.5所示，该系统主要分为七个组件：事务管理器、资源管理器、事务控制器、事务恢复器、事务存储器、序列器和运维平台。下面对各个模块的功能进行说明。事务管理器负责在准备阶段进行事务的发起和传播，在补偿阶段，对事务进行提交或回滚。事务管理器包括可补偿事务拦截器、资源协调拦截器和定义全局事务切面。可补偿事务拦截器负责控制TCC业务活动的流程，对请求交易进行拦截，通过全局事务切面判断不同的事务服务类型，对于分布式事务服务，采用不同的处理，最后在补偿阶段对当前事务进行提交或回滚。资源协调拦截器负责进行事务上下文的传播，以及添加事务参者的功能。可补偿事务拦截器会先对业务服务进行拦截然后资源协调拦截器才会对其进行拦截。判断是否需生成全局事务TxcId，并在后续按需调用下一层级分支事务，添加事务参与者，传播事务上下文。事务控制器主要是在准备阶段生成根事务TxcId，并通过当前事务处理的结果控制调用下一个事务，在补偿阶段根据资源管理器中相关事务信息及事务链路信息进行事务回滚。同时对分布式交易中跟踪事务状态，将所有事务链路信息进行登记，便于对分布式事务的恢复及管理。资源管理器主要负责注册分支事务，标识事务资源，对分布式事务所有资源信息包含事务信息及事务链路调用信息进行管理。当事务管理器根据事务切面等判断为分布式事务时，生成的根事务、事务传播的信息和分支事务相关的信息都会保存在资源管理器中。同时提供接口将所有事务链路信息进行登记，便于对分布式事务的恢复及管理。事务恢复器用于对中断的事务进行恢复操作，保证分布式事务交易中的数据一致性。事务恢复器提供两种事务恢复模式，即定时和手工方式。在整个分布式事务交易阶段，各个阶段都难免出现异常，异常就会造成数据的不一致，事务恢复器一般采用定时查询资源管理器中事务状态等进行判断出中断事务，然后根据策略触发恢复机制。特殊条件下，人工也可在运维平台上查询中断事务进行手工发起事务恢复操作。事务存储器主要是提供所有事务相关信息存储的物理介质，对事务信息进行持久化。包含MySQL数据库，Redis存储器，RockeMQ存储器。其中MySQL数据库用于记录所有分布式事务相关的资源信息；Redis存储器用于在交易中存储当前事务相关的信息，分布式事务结束后会被消除；RockeMQ存储器用于在事务补偿阶段存储事务上下文信息，便于事务的回滚处理等。序列器主要负责整个分布式框架序列ID的生成，用于保证全局序列ID的唯一性。运维平台提供可视化平台提供给运维开发人员可以随时查询分布式事务处理进展状态，包括对RocketMQ中断信息的查询等，通过判断中断事务，进行人工干预，直至达到系统要求的数据一致性。且在此运维平台提供事务恢复很好的灵活性，即可重置事务恢复次数、配置事务恢复策略，便于事务恢复器的操作。1.5.2事务数据结构设计事务作为分布式Saga事务模型的核心类，在整个分布式事务处理中发挥着重要作用。事务对象不仅记录着事务的类型，状态和标识，还保存着事务上下文信息。在事务补偿阶段，会按照当前事务保存的信息进行本地事务的补偿操作，并根据保存的事务上下文交由下一层级进行操作，直至完成整个分布式事务的补偿。在事务恢复阶段，通过保存的事务类型、状态以及链路信息进行分布式事务的恢复。图1.SEQ图3.\*ARABIC6分布式事务Saga模型系统相关类如图1.6分布式事务Saga模型系统相关类所示，包含分布式事务切面处理类、分布式事务处理类及其他相关的状态类。从图中可以看出xid是分布式事务TransactionXid中的全局唯一id。分布式事务状态包含三种事务状态：即TRYING，CONFIRMING，CANCEL。对于分支事务，通过registerBranchId（）方法来注册分支事务，同时对应有分支事务全局唯一id，即BranchId。分布式事务类型TransactionType中包含三种事务类型：即普通事务NORMAL_TRANS，无事务NONE_TRANS，分布式事务DISTRIBUTE_TRANS。另从图1.6的设计可以知道，对于正向交易，请求通过分布式事务切面后，通过交易处理的基类可知当前事务属于分布式事务类型TransactionType中哪一类，如为分布式事务DISTRIBUTE_TRANS，则向事务控制器申请分布式事务TxcId，此时作为根事务，会将事务相关信息保存到事务信息表及Saga链路调用表中，随后根据服务映射关系调用DistributedTransService进行相关交易处理，根据交易场景需要远程调用下一层级交易，此时将事务上下文信息传播到下一级，下一级从事务方生成分支事务ID及相关事务信息保存到事务信息表及Saga链路调用表中，以此按照需要层层调用直至交易完成，分布式事务也据此完成。对于回滚交易，如果交易出现异常，会直接调用当前服务的cancel()方法将本地事务进行回滚，最后判断当前交易是否存在远程调用成功的服务，如有调用成功则调用当前服务的finally()方法发送相关信息给MQ，异步对远程调用成功的服务进行回滚。事务控制器中有专门接收MQ消息的监听器，监听MQ中特定Topic中的消息，然后进行幂等性校验完成后，根据记录的事务信息表及Saga链路跟踪表分析分布式事务回滚的顺序，逐层调用远程服务进行回滚。直至完成所有分布式事务的回滚。事务信息必须要做持久化操作，所有的交易节点必须将自己的事务信息保存起来。如果不做持久化，在系统异常时事务数据的丢失将会事务无法被恢复，造成交易的最终失败无踪可寻。故对事务信息的保存定义了一下两张表：如表1.13事务信息表作为事务的基础信息表记录事务id、事务分组、事务分支等相关信息。表1.SEQ表3.\*ARABIC13事务信息表如表1.14Saga链路调用表作为交易中事务轮转的跟踪表记录全局事务id、是否顺序交易及上下级的顺序编号、当前调用交易的服务bean信息等相关信息。表1.SEQ表3.\*ARABIC14Saga链路调用表图1.SEQ图3.\*ARABIC7分布式事务Saga模型系统事务状态轮转图在分布式交易的处理中事务状态是不断变化的，所以要对整个分布式事务的状态轮转边界设定清楚。如图1.7分布式事务Saga模型系统事务状态轮转图，在分布式交易始阶段，创建事务，并设定事务状态为TRYING，随着交易的进行，如果所有分布式交易都成功，则会更新事务状态为CONFIRMING，如果分布式交易中有一个交易出现异常，则会更新事务状态为CANCELLING。异常状态下会进入事务补偿阶段，在事务补偿阶段，会对分布式交易下的所有交易进行事务回滚操作，直至所有相关交易回滚成功。另在事务恢复阶段，事务恢复器会查询当前交易的事务状态，如果为CANCELLING则会回滚所有相关交易，如为CONFIRMING则会确认当前交易是否完成，确保当前交易最终完成。1.5.3事务处理流程设计通过当前的设计目标以及Saga模型的优缺点等，进行关键点与权衡点的阐述。分布式交易才会有分布式事务，故在处理分布式事务之前，首先要对分布式交易的调用有个清晰的认识。了解分布式交易调用的过程，如图1.8分布式交易服务调用模型图，外部请求到达主业务服务器后，调用主业务服务A进行处理，主业务服务A需调用从业务服务B和从业务服务C来完成交易，在本地的主业务服务中可直接调用从业务服务B代理和从业务服务C代理，其中的从业务服务B代理和从业务服务C代理可理解为从业务服务B和从业务服务C暴露在外的接口，通过此接口可以通过远程服务调用到从业务服务器B和从业务服务器C，最终完成整个分布式交易。图1.SEQ图3.\*ARABIC8分布式交易服务调用模型图对于整个分布式事务交易中各个模块是如何调用以及调用关系，如图1.9分布式事务系统处理模块交互图所示，客户请求进入主业务服务器后，此时分布式事务管理器中的分布式事务切面对交易进行事务的判断拦截，接着向事务控制器申请事务资源信息并将事务信息保存在资源管理器，开始通过主业务服务进行交易处理，按交易需求通过从业务服务代理调用从业务服务，直至所有分布式交易全部完成，分布式事务最终完成更新资源管理器中的事务信息，提交分布式事务完成。如有异常则需回滚分布式事务，主业务服务直接回滚本地事务，并通过判断是否有远程调用的从业务服务，推送消息给消息队列MQ，事务管理器通过对特定Topic监听消息，对需回滚的分布式事务信息进行顺序分析及管理，逐层对从业务系统中的事务进行回滚，直至所有分布式交易中涉及的事务全部回滚完毕。对于中断的事务，可以通过运维平台对事务日志信息及消息队列中信息进行查询及分析，通过事务恢复器进行当前事务操