【《分布式事务处理模型详细设计及实现案例分析》4600字（论文）】

分布式事务处理模型详细设计及实现案例分析目录TOC\o"1-3"\h\u25616分布式事务处理模型详细设计及实现案例分析 1217771.1概述 1312121.2事务管理器TM设计及实现 257481.2.1事务管理器TM的设计 219211.2.2事务管理器TM的实现 3267821.3事务控制器TC设计及实现 7204611.3.1事务控制器TC的设计 7173401.3.2事务控制器TC的实现 8199781.4资源管理器RM设计及实现 1054041.1.1资源管理器RM的设计 1121481.1.2资源管理器RM的实现 1196691.5事务恢复器TR的设计及实现 12137951.5.1事务恢复器TR的设计 1289531.5.2事务恢复器TR的实现 14165961.6运维平台的设计及实现 16162811.6.1运维平台的设计 16254011.6.2运维平台的实现 18239951.6.3运维平台的功能页面 191.1概述经过对系统的概要设计后，将系统主要划分七个模块：事务管理器、资源管理器、事务控制器、事务恢复器、事务存储器、序列器和运维平台。其中事务存储器只提供物理储存介质，在系统架构设计中即可一目了然知道其所包含内容，而序列器用于提供全局唯一ID，为了保证ID生成的稳定性故作为单独模块解耦出来，此两个模块逻辑比较简单，故不再详细描述实现。因此本章主要对事务管理器、资源管理器、事务控制器、事务恢复器和运维平台五个模块的详细设计与实现进行深入探讨与描述。最后依据一个场景对本系统设计进行数据一致性和事务吞吐量的测试。1.2事务管理器TM设计及实现1.2.1事务管理器TM的设计事务管理器TransactionManager作为整个分布式事务框架的核心模块之一，包括可补偿事务拦截器、资源协调拦截器和定义全局事务切面。如图1.1事务管理器模块类图所示，事务管理器中定义了一个分布式事务切面类即CommonServiceAspect，通过注解@SagaTransCode对系统中请求的交易码进行映射，确认当前交易是否属于分布式事务，随后进入请求分发处理类RequestDispatcher，首先根据当前交易码对应继承的基类可判断当前交易请求是否涉及分布式事务，确定是否可以开启分布式事务。资源协调拦截器在此时根据输入参数可判断是否需要生成根事务的全局事务ID，或者添加分支事务参与者。当前设计的基类中可以支持分布式交易的三种情况，即分布式事务基类DistributedTransService，普通事务基类NoramlTransService，无事务基类NoTransService。每个基类会进行定义一些基础的方法及参数，不同的交易服务继承不同的基类复写其中的方法完成对应的操作。在调用下一层从业务方交易时，将当前的事务上下文进行传播。在请求分发处理类RequestDispatcher中还需生成事务上下文信息通过资源协调拦截器在资源管理器SagaResourceManager中进行持久化，同时需将此信息保存在本地缓存ThreadLocal及SagaRedisManager中，并在资源协调拦截器中的JnSagaInterceptor等自定义拦截器中进行日志或监控等其他操作。事务管理器的可补偿事务拦截器在补偿阶段只对本地事务进行回滚或提交，而对于日志或监控等信息的持久化基类则不会做回滚。对于远程调用的分布式交易，则交由消息队列MQ进行异步回滚处理。图1.SEQ图4.\*ARABIC1事务管理器模块类图1.2.2事务管理器TM的实现如图1.2事务管理器主处理类图1和图1.3事务管理器主处理类图2描述的是RequestDispatcher事务管理器主处理类的处理过程。图1.SEQ图4.\*ARABIC2事务管理器主处理类图1图1.SEQ图4.\*ARABIC3事务管理器主处理类图2如图1.4分布式事务处理类图1和图1.5分布式事务处理类图2描述的是DistributedTransService分布式事务处理类的处理过程。图1.SEQ图4.\*ARABIC4分布式事务处理类图1图1.SEQ图4.\*ARABIC5分布式事务处理类图21.3事务控制器TC设计及实现1.3.1事务控制器TC的设计事务控制器TransactionCoordinator作为整个分布式事务框架的核心模块之一，包括生成TxcID、驱动全局/分支事务管理和跟踪事务状态。如图1.6事务控制器模块类图所示，SagaTransactionController作为事务控制器的主类提供以上核心功能，此类通过实现多线程ExecutorService支持大数据量高并发的调用操作，为事务控制器的高性能提供基础。其中生成TxcID功能是通过调用SagaTransactionController中的generateTxcId()方法来调用序列器中的ApplySequenceService获取全局唯一ID的。驱动全局/分支事务管理体现在补偿阶段通过继承RocketMQ消息监听基类的SagaMQManager类中messageListern（）方法监听消息队列MQ中特定Topic消息时，通过调用SagaTransactionController类中的transTreeAnalysis()方法对消息中相关事务的解析，此时解析包含获取当时分布式交易的输入输出参数及处理BeanName，然后通过BeanName反射调用处理Bean类的cancel()方法进行回滚操作。同时transTreeAnalysis()方法通过对分布式事务顺序分析确定是否可以同时对多个分布式交易进行回滚操作。根据分布式交易最先设置的层级关系，回滚操作是自下而上的，而顺序的判断是自上而下的。如果分布式交易是无顺序的则可从最上层开始释放，驱动分布式交易中不同的从业务服务同时开始回滚操作。跟踪事务状态是在分布式交易事务过程中从申请生成TxcID，然后添加事务参与者申请分支事务BranchId都需要在资源管理器中明确记录相关事务状态，并提供给事务恢复器获取相关事务状态的接口方法getTransStatus()，用于事务的恢复及事务状态的跟踪。图1.SEQ图4.\*ARABIC6事务控制器模块类图1.3.2事务控制器TC的实现如图图1.7事务控制器处理类图1、图1.8事务控制器处理类图2和图1.9事务控制器处理类图3描述的是SagaTransactionController事务控制器处理类的处理过程。图1.SEQ图4.\*ARABIC7事务控制器处理类图1图1.SEQ图4.\*ARABIC8事务控制器处理类图2图1.SEQ图4.\*ARABIC9事务控制器处理类图31.4资源管理器RM设计及实现1.1.1资源管理器RM的设计资源管理器ResourceManager作为整个分布式事务框架的核心模块之一，包括管理分支事务、注册分支事务和标识资源三个模块。如图1.10资源管理器模块类图所示，SagaResourceManager作为资源管理器的主类提供以上核心功能。简单来看，此类主要通过TransactionRepository对Saga链路调用表和事务信息表等分布式事务相关的表进行持久化完成以上功能。事务控制器与事务管理器在生成分布式事务上下文信息后需将此信息保存在资源管理器中，同时资源管理器提供分布式事务相关信息的查询接口，便于其他管理器进行查询。图1.SEQ图4.\*ARABIC10资源管理器模块类图1.1.2资源管理器RM的实现如图1.11事务资源管理器处理类图描述的是SagaResourceManager资源管理器主处理类处理过程。图1.SEQ图4.\*ARABIC11事务资源管理器处理类图1.5事务恢复器TR的设计及实现1.5.1事务恢复器TR的设计事务恢复器主要功能是对流程中异常节点判断并将原流程异常节点恢复起来。故在设计事务恢复器之前需要考虑分布式事务的异常发生点，分析当前可能会发生事务异常的点：一是业务原因：整个分布式事务正常，但是分支事务失败的情况；整个分布式事务失败，但是分支事务成功的情况。二是技术原因：因为特殊原因没有发送MQ；MQ发送之后正确读取返回，但未成功处理；MQ异常导致数据没有被消费，流程无法进行下去。综合以上可知事务恢复器用于对中断的事务进行恢复操作，通过查询没有完成的事务信息，并对其做对应的事务恢复处理，保证分布式事务交易中的数据一致性。事务恢复器提供两种事务恢复模式，即定时和手工方式。除此之外，还需要满足重置事务恢复次数、配置事务恢复策略等个性化功能。为了更好的满足以上恢复器的需求，采用开源项目分布式任务调度平台xxl-job方案。xxl-job项目提供简单动态的配置方式，通过中心式的调度中心以及分布式的执行器，配合触发策略、调度过期策略、柱塞处理策略等多样性的策略，同时可满足重置事务恢复次数、配置事务恢复策略等个性化功能需求，同时可使用定时和手工的方式实现一致性的分布式调度服务。图1.SEQ图4.\*ARABIC12xxl-job架构图v2.1.0结合以上xxl-job的特性，分析当前事务恢复器的配置:1.查询所有超过一定时间（默认设置2个小时）的数据，如果异常则需要自动发起做事务回滚。2.对自动发起的数据进行记录，以便之后做查询，人工介入之后的处理。3.对于超过重试次数的数据，配置预警，人工介入处理。根据以上分析来设计事务恢复器，如图1.13事务恢复器模块类图所示：图1.SEQ图4.\*ARABIC13事务恢复器模块类图从事务恢复器的类图中可知，所有事务恢复的处理在定时器中完成。平台xxl-job作为该模块的核心部分，做事务恢复器的统一调拨，所有相关使用都需遵循xxl-job提供的规范。按类图中所示xxl-job平台配置定时器，其中SagaTransRecoverJobHandler类作为继承xxl-job基类IJobHandler的实现类，用于xxl-job平台进行特定需求的定时器的调用。而这些定时器需要调用SagaTransRecoverService服务基类完成具体的处理工作。SagaTransRecoverService服务基类中提供事务流程信息查询方法getSagaInvokeJnList()，事务信息查询方法getSagaTransInfo()以及MQ数据信息的处理方法dealMQ()，用于各个继承了此基类的服务去实现不同的功能处理。1.5.2事务恢复器TR的实现如图1.14事务恢复器的初始化及处理流程图所示，在xxl-job平台上首先需要配置执行器，选择执行器模块进行新增执行器操作，随后新建任务，并进行任务编辑，通配置完成符合条件的JobHandler实现类和其他定时器相关参数设置，之后启动定时器任务，定时器自动触发任务，进入执行的JobHandler实现类完成任务处理逻辑，如此过程没有任何异常则执行器可直接结束，如出现异常则需进行重试，直到超过最大失败重试次数或任务执行成功，如在此过程中超过最大失败重试次数，则需人工介入处理，查看执行日志，进行判断并进行相应处理操作。图1.SEQ图4.\*ARABIC14事务恢复器的初始化及处理流程图如图1.15事务恢复器xxl-job处理类图和图1.16事务恢复器主处理类图描述的是xxl-job的IJobHanlder的实现类和SagaTransRecoverService资源管理器主处理类处理过程。图1.SEQ图4.\*ARABIC15事务恢复器xxl-job处理类图图1.SEQ图4.\*ARABIC16事务恢复器主处理类图1.6运维平台的设计及实现1.6.1运维平台的设计运维平台主要是提供可视化平台提供给运维开发人员可以随时查询分布式事务处理进展状态，并进行人工介入干预处理。运维平台在整个架构定义上需要提供可靠的信息用于运维开发人员对事务真实状态的判断，这些信息主要包含两部分，即MQ的数据和数据库中事务数据。当前对运维平台的设计，考虑数据信息的来源渠道以及运维平台的设计要求，采用xxl-job平台和RocketMQ-Console平台两个开源项目的方式进行管理。采用xxl-job的运维平台来进行自动任务多次失败的人工排错及手动重试。其中xxl-job平台主要提供两方面功能，一是重置事务恢复次数、配置事务恢复策略等，二是查询数据库中事务信息相关数据状态。在批量处理异常时通过查看处理日志，判断是否需要在xxl-job上手工执行批量任务处理。即首先通过xxl-job定时查询发送MQ超过一定时间仍未处理的数据，在日志中展示。然后进行分析，并在RocketMQ-Console逐笔查询MQ异常数据，进行手动重发。具体xxl-job的介绍可以参考上一章节中关于此开源项目的介绍。如图1.17运维平台操作流程图表现的是整个运维平台操作的流程图。此操作流程图包含xxl-job与RocketMQ-Console两个开源项目的操作。首先运维开发人员可以在xxl-job平台上查看任务执行的错误日志，人工判断异常类型，然后判断是否需要手动重新执行任务，如果需要则可人工触发重新执行定时器任务；如果不需要再次执行定时器任务，则考虑是否需要手动执行MQ重发，如果需要则可在RocketMQ-Console平台上通过messageId找到对应数据进行手工重发，如不需要此时需手工删除异常事务的日志数据。图1.SEQ图4.\*ARABIC17运维平台操作流程图采用RocketMQ-Console来进行mq数据发送失败或其他mq相关异常失败后的重试。同时选用RocketMQ-Console开源项目的原因是可以通过可视化页面随时随地对RocketMQ的数据进行监控，（可监控数据包括生产者Producer状态、消费者Consumer状态、Broker集群状态，Topic数据管理等），还能否准确的把握RocketMQ数据接收发送的状态。图1.SEQ图4.\*ARABIC18运维平台模块类图如图1.18运维平台模块类图所示，RocketMQ-Console平台通过与RocketMQ解耦的方式提供对MQ数据发送接收处理的状态轮转记录。其中MQ数据的监听通过继承RocketMQ消息数据消费监听的基类RocketMQMessageConsumer的实现类MessageQueueListern类来完成，此类会首先通过MQ数据消费流水表判断消费MQ数据的幂等性，然后调用事务控制器中的SagaTransactionController类中的transTreeAnalysis()方法对消息