一种分布式事务处理方法及装置制造方法及图纸

本发明专利技术属于分布式计算技术领域，公开了一种分布式事务处理方法及装置。所述方法包括应用开发的步骤，事务管理属性定义的步骤，事件定义的步骤，流式计算的步骤，事务管理的步骤，通过流式计算实时获取并识别事件的信息，并实时获取事务管理属性，根据事件的信息和事务管理属性定期验证事务状态，根据事务状态发起查证请求和/或冲正请求，通过事务管理器发送事务状态查证指令和/或冲正指令。通过本方案，事务控制与应用开发完全解耦，应用开发无需开发事务控制逻辑，极大简化开发难度，实现异常场景下的事务快速回滚，容忍任意节点的故障，没有脑裂问题。

【技术实现步骤摘要】
一种分布式事务处理方法及装置
本专利技术属于分布式计算
，涉及一种分布式事务处理方法及装置，特别涉及一种基于流式计算的分布式事务处理方法及装置。
技术介绍
相关术语解释：事务(Transaction)：一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言(如SQL，C++或Java)书写的用户程序的执行所引起，并用形如begintransaction和endtransaction语句(或函数调用)来界定。事务由事务开始(begintransaction)和事务结束(endtransaction)之间执行的全体操作组成。事务处理(TransactionProcessing)：在许多大型、关键的应用程序中，计算机每秒钟都在执行大量的任务。更为经常的不是这些任务本身，而是将这些任务结合在一起完成一个业务要求，称为事务。如果能成功地执行一个任务，而在第二个或第三个相关的任务中出现错误，将会发生什么？这个错误很可能使系统处于不一致状态。这时事务变得非常重要，它能使系统摆脱这种不一致的状态。CICS、Tuxedo和TopEnd等产品都是事务处理系统的例子，它们为应用程序提供事务服务。流式计算(StreamComputing)：在传统的数据处理流程中，总是先收集数据，然后将数据放到数据库(DB)中。当人们需要的时候通过DB对数据做查询(query)，得到答案或进行相关的处理，这种方式称为批量计算。这样看起来虽然非常合理，但是结果却非常的凑和，尤其是在一些实时搜索应用环境中的某些具体问题，类似于MapReduce方式的离线处理并不能很好地解决问题。这就引出了一种新的数据计算结构——流计算方式，它可以很好地对大规模流动数据在不断变化的运动过程中实时地进行分析，捕捉到可能有用的信息，并把结果发送到下一计算节点。与批量计算那样慢慢积累数据不同，流式计算将大量数据平摊到每个时间点上，连续地进行小批量的传输，数据持续流动，计算完之后就丢弃。批量计算是维护一张数据表，对表进行实施各种计算逻辑。流式计算相反，是必须先定义好计算逻辑，提交到流式计算系统，这个计算作业逻辑在整个运行期间是不可更改的。计算结果上，批量计算对全部数据进行计算后传输结果，流式计算是每次小批量计算后，结果可以立刻投递到在线系统，做到实时化展现。事件驱动(EventDriven)：事件驱动是指在持续事务管理过程中，进行决策的一种策略，即跟随当前时间点上出现的事件，调动可用资源，执行相关任务，使不断出现的问题得以解决，防止事务堆积。在计算机编程、公共关系、经济活动等领域均有应用。ACID模型：强一致事务模型，包含原子性(Atomicity)，一致性(Consistency)，隔离性(Isolation)和持久性(Durability)。原子性指整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过一样。一致性指一个事务可以封装状态改变(除非它是一个只读的)。事务必须始终保持系统处于一致的状态，不管在任何给定的时间并发事务有多少。隔离性指隔离状态执行事务，使它们好像是系统在给定时间内执行的唯一操作，即多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。持久性指在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。BASE模型：最终一致事务模型，是BasicallyAvailable(基本可用)、Softstate(软状态)和Eventuallyconsistent(最终一致性)三个短语的简写。BASE的核心思想是：即使无法做到强一致性(Strongconsistency),但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务，这就是损失部分可用性的体现。软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。CAP理论：指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partitiontolerance(分区容错性)，三者不可得兼。其中分布式系统中的三个特性定义如下：一致性(C)：在分布式系统中的所有数据备份，在同一时刻是否同样的值；可用性(A)：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求；分区容错性(P)：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出权衡。二阶段提交(TwoPhaseCommit，2PC)：基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此，二阶段提交的算法思路可以概括为：参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。二阶段锁(TwoPhaseLock，2PL)：两阶段锁协议是指每个事务的执行可以分为两个阶段：生长阶段(加锁阶段)和衰退阶段(解锁阶段)。加锁阶段在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁，在进行写操作之前要申请并获得X锁。加锁不成功，则事务进入等待状态，直到加锁成功才继续执行。解锁阶段当事务释放了一个封锁以后，事务进入解锁阶段，在该阶段只能进行解锁操作不能再进行加锁操作。二阶段封锁法可以这样来实现：事务开始后就处于加锁阶段，一直到执行回滚(ROLLBACK)和提交(COMMIT)之前都是加锁阶段。回滚(ROLLBACK)和提交(COMMIT)使事务进入解锁阶段，即在回滚(ROLLBACK)和提交(COMMIT)模块中数据库管理系统(DBMS)释放所有封锁。事务处理(TP)的核心在于通过事务隔离，原子性提交或回滚，持久化处理等方式保证事务处理过程中的数据一致性。传统的集中式IT架构下，事务控制通常通过事务处理中间件来封装事务处理，其底层技术主要采用二阶段提交(2PC)和二阶段锁(2PL)来保证事务的ACID特性，数据强一致，即当更新操作完成之后，任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友本文档来自技高网...

【技术保护点】
1.一种分布式事务处理方法，其特征在于，包括：设置应用的步骤：在分布式系统中布置实现事务处理所需的若干应用，所述各应用在分布式系统中设有本地事务数据源；事务管理属性定义的步骤：根据事务处理的需求定义事务管理属性；事件定义的步骤：将事务处理中的若干特定状态变化定义为事件；流式计算的步骤：通过流式计算实时获取并识别事件的信息，并实时获取事务管理属性，根据事件的信息和事务管理属性定期验证事务状态并根据事务状态发起查证请求和/或冲正请求；事务管理的步骤：事务管理器根据查证请求向各应用发送事务状态查证指令，和/或根据冲正请求向各应用的事务数据源发送事务冲正指令。

【技术特征摘要】
1.一种分布式事务处理方法，其特征在于，包括：设置应用的步骤：在分布式系统中布置实现事务处理所需的若干应用，所述各应用在分布式系统中设有本地事务数据源；事务管理属性定义的步骤：根据事务处理的需求定义事务管理属性；事件定义的步骤：将事务处理中的若干特定状态变化定义为事件；流式计算的步骤：通过流式计算实时获取并识别事件的信息，并实时获取事务管理属性，根据事件的信息和事务管理属性定期验证事务状态并根据事务状态发起查证请求和/或冲正请求；事务管理的步骤：事务管理器根据查证请求向各应用发送事务状态查证指令，和/或根据冲正请求向各应用的事务数据源发送事务冲正指令。2.根据权利要求1所述的分布式事务处理方法，其特征在于：在所述设置应用的步骤中，所述应用包括一个分布式事务协调者和若干分布式事务参与者，所述分布式事务协调者是分布式事务的发起方和提交方，其通过事务API、注解或事务定义文件的方式开启分布式事务；所述分布式事务协调者和各分布式事务参与者通过事务ID实现对下游事务参与者的远程调用。3.根据权利要求2所述的分布式事务处理方法，其特征在于：所述事务ID包括全局事务ID(UOW_Global_ID)、本地事务ID(UOW_Local_ID)和分支号(Span_id)，所述各应用全局事务ID相同，分布式事务协调者的分支号默认为0，分支号按照应用间的上下游关系逐渐递增，所述分布式事务参与者基于全局事务ID(UOW_id)和分支号(Span_id)生成本地事务ID，并传递给下游分布式事务参与者。4.根据权利要求3所述的分布式事务处理方法，其特征在于：所述事务管理属性定义的步骤在所述各应用中和/或在所述事务管理器中进行，所述事务管理属性包括事务名称、事务传播属性、事务隔离属性、超时设置、回滚控制、提交控制、只读配置、未明状态策略中的一种或多种。5.根据权利要求4所述的分布式事务处理方法，其特征在于：在事件定义的步骤中，所述事件包括事务开始事件、事务结束事件、异常事件、应用调用事件、应用被调用事件、应用持久层事件、事务数据源持久化事件中的一种或多种；其中：所述事务开始事件的信息包括事务ID、应用信息、时间信息中的一种或多种；所述事务结束事件的信息包括事务ID、应用信息、时间信息、事务结果中的一种或多种；所述异常事件指未被应用捕获事务处理结果的事务运行状态；应用调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种；所述应用被调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种；所述应用持久层事件的信息包括事务ID、会话信息中的一种多或多种；所述事务数据源持久化事件的信息包括会话信息、持久化日志中的一种或多种。6.根据权利要求5所述的分布式事务处理方法，其特征在于：在事件定义的步骤中，通过应用埋点技术或通信旁路技术生成各事件对应的事务日志，供流式计算步骤实时获取并识别事件的信息。7.根据权利要求1所述的分布式事务处理方法，其特征在于：所述流式计算通过ApacheStorm，SparkStreaming，Flink，Flume，Kafka中的一种或多种流式计算平台实现。8.根据权利要求5所述的分布式事务处理方法，其特征在于：所述流式计算的步骤通过以下方式实现：实时采集事件的信息，识别事务开启事件，并从应用或者事务管理器中获取事务管理属性，缓存事务处理过程中的所有事务性持久化信息，并定期进行事务状态验证：1)如果分布式事务协调者提交事务，通过流式计算确认所有应用中的事务数据源的完成情况，以完成事务提交；如果确认结果为完成，清理缓存数据；否则发送查证请求给事务处理器；2)如果分布式事务协调者回滚事务，通过流式计算确认所有应用中事务数据源均完成回滚操作：如果确认，清理缓存数据；否则向事务管理器发送回滚请求，由事务管理器向对应事务数据源发起回滚指令；3)如果分布式事务协调者在事务超时周期内未发起提交或者回滚，事务进入未明状态，此时通过流式计算判断事务管理属性中的未明状态策略，如果策略为回滚，通过流式计算检查各应用中的事务源状态，对未回滚的事务数据源生成回...

【专利技术属性】
技术研发人员：周北春，朱清沂，周竣涛，孟德君，
申请(专利权)人：中信百信银行股份有限公司，
类型：发明
国别省市：北京,11