CN108459919A - 一种分布式事务处理方法及装置 - Google Patents
一种分布式事务处理方法及装置 Download PDFInfo
- Publication number
- CN108459919A CN108459919A CN201810273667.7A CN201810273667A CN108459919A CN 108459919 A CN108459919 A CN 108459919A CN 201810273667 A CN201810273667 A CN 201810273667A CN 108459919 A CN108459919 A CN 108459919A
- Authority
- CN
- China
- Prior art keywords
- transaction
- affairs
- event
- application
- information
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2372—Updates performed during offline database operations
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24568—Data stream processing; Continuous queries
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Computing Systems (AREA)
- Multimedia (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明属于分布式计算技术领域,公开了一种分布式事务处理方法及装置。所述方法包括应用开发的步骤,事务管理属性定义的步骤,事件定义的步骤,流式计算的步骤,事务管理的步骤,通过流式计算实时获取并识别事件的信息,并实时获取事务管理属性,根据事件的信息和事务管理属性定期验证事务状态,根据事务状态发起查证请求和/或冲正请求,通过事务管理器发送事务状态查证指令和/或冲正指令。通过本方案,事务控制与应用开发完全解耦,应用开发无需开发事务控制逻辑,极大简化开发难度,实现异常场景下的事务快速回滚,容忍任意节点的故障,没有脑裂问题。
Description
技术领域
本发明属于分布式计算技术领域,涉及一种分布式事务处理方法及装置,特别涉及一种基于流式计算的分布式事务处理方法及装置。
背景技术
相关术语解释:
事务(Transaction):一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务通常由高级数据库操纵语言或编程语言(如SQL,C++或Java)书写的用户程序的执行所引起,并用形如begintransaction和end transaction语句(或函数调用)来界定。事务由事务开始(begintransaction)和事务结束(end transaction)之间执行的全体操作组成。
事务处理(Transaction Processing):在许多大型、关键的应用程序中,计算机每秒钟都在执行大量的任务。更为经常的不是这些任务本身,而是将这些任务结合在一起完成一个业务要求,称为事务。如果能成功地执行一个任务,而在第二个或第三个相关的任务中出现错误,将会发生什么?这个错误很可能使***处于不一致状态。这时事务变得非常重要,它能使***摆脱这种不一致的状态。CICS、Tuxedo和TopEnd等产品都是事务处理***的例子,它们为应用程序提供事务服务。
流式计算(Stream Computing):在传统的数据处理流程中,总是先收集数据,然后将数据放到数据库(DB)中。当人们需要的时候通过DB对数据做查询(query),得到答案或进行相关的处理,这种方式称为批量计算。这样看起来虽然非常合理,但是结果却非常的凑和,尤其是在一些实时搜索应用环境中的某些具体问题,类似于MapReduce方式的离线处理并不能很好地解决问题。这就引出了一种新的数据计算结构——流计算方式,它可以很好地对大规模流动数据在不断变化的运动过程中实时地进行分析,捕捉到可能有用的信息,并把结果发送到下一计算节点。
与批量计算那样慢慢积累数据不同,流式计算将大量数据平摊到每个时间点上,连续地进行小批量的传输,数据持续流动,计算完之后就丢弃。批量计算是维护一张数据表,对表进行实施各种计算逻辑。流式计算相反,是必须先定义好计算逻辑,提交到流式计算***,这个计算作业逻辑在整个运行期间是不可更改的。计算结果上,批量计算对全部数据进行计算后传输结果,流式计算是每次小批量计算后,结果可以立刻投递到在线***,做到实时化展现。
事件驱动(Event Driven):事件驱动是指在持续事务管理过程中,进行决策的一种策略,即跟随当前时间点上出现的事件,调动可用资源,执行相关任务,使不断出现的问题得以解决,防止事务堆积。在计算机编程、公共关系、经济活动等领域均有应用。
ACID模型:强一致事务模型,包含原子性(Atomicity),一致性(Consistency),隔离性(Isolation)和持久性(Durability)。
原子性指整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
一致性指一个事务可以封装状态改变(除非它是一个只读的)。事务必须始终保持***处于一致的状态,不管在任何给定的时间并发事务有多少。
隔离性指隔离状态执行事务,使它们好像是***在给定时间内执行的唯一操作,即多个事务并发访问时,事务之间是隔离的,一个事务不应该影响其它事务运行效果。
持久性指在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。
BASE模型:最终一致事务模型,是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写。BASE的核心思想是:即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使***达到最终一致性。基本可用是指分布式***在出现故障的时候,允许损失部分可用性,即保证核心可用。电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务,这就是损失部分可用性的体现。软状态是指允许***存在中间状态,而该中间状态不会影响***整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。最终一致性是指***中的所有数据副本经过一定时间后,最终能够达到一致的状态。
CAP理论:指的是在一个分布式***中,Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性),三者不可得兼。其中分布式***中的三个特性定义如下:
一致性(C):在分布式***中的所有数据备份,在同一时刻是否同样的值;
可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求;
分区容错性(P):以实际效果而言,分区相当于对通信的时限要求。***如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出权衡。
二阶段提交(Two Phase Commit,2PC):基于分布式***架构下的所有节点在进行事务提交时保持一致性而设计的一种算法(Algorithm)。在分布式***中,每个节点虽然可以知晓自己的操作时成功或者失败,却无法知道其他节点操作的成功或失败。当一个事务跨越多个节点时,为了保持事务的ACID特性,需要引入一个作为协调者的组件来统一掌控所有节点(称作参与者)的操作结果并最终指示这些节点是否要把操作结果进行真正的提交(比如将更新后的数据写入磁盘等等)。因此,二阶段提交的算法思路可以概括为:参与者将操作成败通知协调者,再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
二阶段锁(Two Phase Lock,2PL):两阶段锁协议是指每个事务的执行可以分为两个阶段:生长阶段(加锁阶段)和衰退阶段(解锁阶段)。
加锁阶段在该阶段可以进行加锁操作。在对任何数据进行读操作之前要申请并获得S锁,在进行写操作之前要申请并获得X锁。加锁不成功,则事务进入等待状态,直到加锁成功才继续执行。
解锁阶段当事务释放了一个封锁以后,事务进入解锁阶段,在该阶段只能进行解锁操作不能再进行加锁操作。
二阶段封锁法可以这样来实现:事务开始后就处于加锁阶段,一直到执行回滚(ROLLBACK)和提交(COMMIT)之前都是加锁阶段。回滚(ROLLBACK)和提交(COMMIT)使事务进入解锁阶段,即在回滚(ROLLBACK)和提交(COMMIT)模块中数据库管理***(DBMS)释放所有封锁。
事务处理(TP)的核心在于通过事务隔离,原子性提交或回滚,持久化处理等方式保证事务处理过程中的数据一致性。传统的集中式IT架构下,事务控制通常通过事务处理中间件来封装事务处理,其底层技术主要采用二阶段提交(2PC)和二阶段锁(2PL)来保证事务的ACID特性,数据强一致,即当更新操作完成之后,任何多个后续进程或者线程的访问都会返回最新的更新过的值。这种是对用户最友好的,就是用户上一次写什么,下一次就保证能读到什么。但是这种实现对性能影响较大。
但是随着分布式技术的快速发展,基于X86的集群管理的云计算技术开始兴起并被广泛使用在互联网等行业。云计算具有成本低,技术开放,扩展能力强等诸多特性,也正因为这些特性,一些金融机构也开始了在云计算领域的探索,例如将非账务类或者查询类应用部署在云平台上。但是分布式也带来一些难题,例如如何在分布式的集群里进行分布式的事务控制。现阶段的主要技术方案有如下3种:
方案一:使用中间件沿用基于2PC事务控制机制
很多IT厂商针对分布式X86集群提供了较为轻量级的中间件***。该方案在传统的金融企业使用较多。
方案二:放弃中间件,由应用保证事务ACID
一些金融性质的互联网企业提出了替代中间件的应用级解决方案,由应用来保证事务的ACID,尤其是一致性保证。最为主流的应用开发模式是TCC模式。TCC模式是指由应用实现二阶段提交的开发模式,包括三部分实现逻辑:
TRYING阶段主要是对业务***做检测及资源预留;
CONFIRMING阶段是对业务***做确认提交,TRYING阶段执行成功并开始执行CONFIRMING阶段时,默认CONFIRMING阶段是不会出错的。即:只要TRYING成功,CONFIRMING一定成功;
CANCELING阶段主要是在业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放。
CONFIRMING阶段和CANCELING阶段是平行关系,TRYING阶段之后,要么进入CONFIRMING阶段,要么进入CANCELING阶段。TCC要求应用支持幂等性。幂等性是指业务方法调用一次与调用多次的执行返回结果是一样的。
方案三:补偿模式实现最终一致性(BASE)
BASE是Ebay在分布式实践中提出的新型一致性控制模型,是基于CAP理论适当牺牲一致性(C)换取可用性(A)。BASE在分布式领域被广泛使用,并成为云计算的普遍技术选择。BASE模型下2PC方案被彻底摒弃,为了实现事务中的最终一致性。最为典型的BASE解决方案就是补偿模式。
补偿模式要求应用提供正向交易和冲正交易,并且通过服务流模式定义交易流程,交易流的状态需要实时入库,一旦服务流出现异常,由总控程序发起逆向冲正。即将一笔错误的交易恢复,比如取款1000,但钱没取出来,余额却少了,那么这1000块会被自动冲正回来,将余额恢复。
然而,以上三种方案均存在自身技术缺陷,具体如下
方案一缺陷:2PC方案的主要缺陷在于一旦事务协调者(Coordinator)出现***异常,整个事务控制过程将出现脑裂问题。处于脑裂的事务必须等到事务协调者(Coordinator)恢复并发出提交(Commit)或者回滚(Rollback)指令来完成事务。但是由于事务处理过程采用二阶段锁,在没有提交或者回滚过程中,锁将长期处于加锁状态,进而造成其他并行事务被阻塞。如果脑裂事务刚好持有一张热表的锁,整个IT***将可能面临整体不可用。所以该方案只适用于要求数据强一致,但是可以容忍***不可用的场景。为了在***不可用和一致性方面进行权衡,2PC可以通过经验性异常处理(Heuristic action)来让事务参与者(Participant)在等待一段时间(Timeout)之后采用预先设定的事务操作(一般情况下是默认回滚),但是这将导致数据不一致,需要人工介入。所以在现实的市场竞争下,分布式技术通常会放弃2PC的方案。
方案二缺陷:TCC的主要问题是对应用***侵害过于严重,要求应用开发人员不仅要关注业务实现,也需要设计一致性控制和异常处理,而且TRYING阶段的资源预留在异常情况下对***的损耗相对较大,限制了总体吞吐量。TCC开发模式在技术水平较高的互联网企业有一定应用,但总体来说其应用侵害性造成无法广泛流行。
方案三缺陷:补偿模式是现阶段分布式架构的主流选择。该方案的主要问题是:
1.应用仍然设计并实现冲正类逻辑,实现异常场景的冲正
2.由于冲正发生时,正交易已经提交一段时间,较长的时间差造成冲正很可能失败,进而造成数据不一致。而且基于程序调用的冲正交易也可能异常,造成冲正失败
发明内容
为了克服现有技术中存在的问题,本发明提供了一种分布式事务处理方法及装置。
本发明具体公开了一种分布式事务处理方法,包括:
设置应用的步骤:在分布式***中布置实现事务处理所需的若干应用,所述各应用在分布式***中设有本地事务数据源,以实现本地化数据存储及更新;
事务管理属性定义的步骤:根据事务处理的需求定义事务管理属性;
事件定义的步骤:将事务处理过程中的若干特定状态变化定义为事件;
流式计算的步骤:通过流式计算实时获取并识别事件的信息,并实时获取事务管理属性,根据事件的信息和事务管理属性定期验证事务状态,根据事务状态发起查证请求和/或冲正请求;
在本发明所述方法使用于银行类业务的实施例中,所述冲正请求可为事务状态变更记录的回滚请求。
事务管理的步骤:事务管理器根据查证请求向各应用发送事务状态查证指令,和/或根据冲正请求向各应用的事务数据源发送事务冲正指令。
作为优选方式,在本发明所述分布式事务处理方法中,在所述设置应用的步骤中,所述应用包括一个分布式事务协调者和若干分布式事务参与者,所述分布式事务协调者是分布式事务的发起方和提交方,其通过事务API、注解或事务定义文件的方式开启分布式事务;所述分布式事务协调者和若干分布式事务参与者通过事务ID实现对下游事务参与者的远程调用。其中,事务API,如Begin Transaction;注解,如@Transacational;事务定义文件,如XML。
作为优选方式,在本发明所述分布式事务处理方法中,所述事务ID包括全局事务ID(UOW_Global_ID)、本地事务ID(UOW_Local_ID)和分支号(Span_id),所述各应用全局事务ID相同,分布式事务协调者的分支号默认为0,分支号按照应用间的上下游关系逐渐递增,所述分布式事务参与者基于全局事务ID(UOW_id)和分支号(Span_id)生成本地事务ID,并传递给下游分布式事务参与者。层次化的事务ID是全局事务的唯一标识,进而形成事务的原子性控制,同时记录事务更新顺序,为逆序冲正提供依据。
优选地,所述事务管理属性定义的步骤在所述应用中和/或在所述事务管理器中进行,所述事务管理属性包括事务名称、事务传播属性、事务隔离属性、超时设置、回滚控制、提交控制、只读配置、未明状态策略中的一种或多种。其中,提事务传播属性,如是否开启新事务还是继承原有事务上下文;事务隔离属性,如未提交读,提交读,可重复读和序列化;回滚控制,如在何种异常下回滚;提交控制,如可忽略何种异常而进行提交。
优选地,在事件定义的步骤中,所述事件包括事务开始事件、事务结束事件、异常事件、应用调用事件、应用被调用事件、应用持久层事件、事务数据源持久化事件中的一种或多种;其中:
所述事务开始事件的信息包括事务ID、应用信息、时间信息中的一种或多种;
所述事务结束事件的信息包括事务ID、应用信息、时间信息、事务结果中的一种或多种;
所述异常事件指未被应用捕获事务处理结果的事务运行状态;
应用调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用被调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用持久层事件的信息包括事务ID、会话信息中的一种多或多种;
所述事务数据源持久化事件的信息包括会话信息、持久化日志中的一种或多种。
优选地,在事件定义的步骤中,通过应用埋点技术或通信旁路技术生成各事件对应的事务日志,供流式计算步骤实时获取并识别事件的信息。其中,应用埋点技术,如使用面向切片编程技术,设计切片,应用切点与切片动作,形成业务逻辑无侵入的数据采集;通信旁路技术,如网卡捕获特征传输报文。
优选地,所述流式计算通过Apache Storm,Spark Streaming,Flink,Flume,Kafka中的一种或多种流式计算平台实现。其中,Apache Storm,Spark Streaming和Flink可用于实时计算,Flume可用于数据采集,Kafka可用于消息流转。特别是,Apache Storm,SparkStreaming和Flink是业界主流流式计算框架,Flume常用于日志采集,Kafka被作为数据管道广泛使用。流式计算实现对分布式环境下散列的事务信息进行秒级甚至毫秒级实时计算,满足OLTP对事务实时性的要求。
优选地,所述流式计算的步骤通过以下方式实现:
实时采集事件的信息,识别事务开启事件,并从应用或者事务管理器中获取事务管理属性,缓存事务处理过程中的所有事务性持久化信息,并定期进行事务状态验证,具体包括:
1)如果分布式事务协调者提交事务,通过流式计算确认所有应用中的事务数据源的完成情况,以完成事务提交;如果确认结果为完成,清理缓存数据;否则发送查证请求给事务处理器;
2)如果分布式事务协调者回滚事务,通过流式计算确认所有应用中事务数据源均完成回滚操作:如果确认,清理缓存数据;否则向事务管理器发送回滚请求,由事务管理器向对应事务数据源发起回滚指令;
3)如果分布式事务协调者在事务超时周期内未发起提交或者回滚,事务进入未明状态,此时通过流式计算判断事务管理属性中的未明状态策略,如果策略为回滚,通过流式计算检查各应用中的事务源状态,对未回滚的事务数据源生成回滚请求,发给事务管理器,由事务管理器向未回滚的事务数据源发起回滚;如果策略为提交,通过流式计算检查各应用的事务数据源提交状态,如果存在未提交事务,发送查证请求给事务管理器。
在本发明所述的分布式事务处理方法优选实施方式中,所述回滚指令的执行按照本地事务ID中的分支号(Span_id)逆序操作。根据事务更新顺序的逆序冲正保证冲正操作的正确性与成功率。
在本发明所述的分布式事务处理方法优选实施方式中,还包括报警的步骤:当流式计算反馈的事务状态为异常事件时,事务管理器向各应用发送事务状态查证指令,当流式计算结果反馈结果仍然为异常事件时,事务管理器发出运维报警指令。
本发明同时还提供了一种分布式事务处理装置,包括:
分布式应用模块:包括分布于分布式***中用于事务处理的若干应用,以及在分布式***中各应用对应的本地事务数据源,以实现各应用本地化数据存储及更新;
事件定义模块:用于生成各事件对应的事务日志,所述事件为事务处理过程中的特定状态变化;
事务管理模块:用于根据流式计算模块发送的查证请求向各应用发送事务状态查证指令,和/或根据流式计算模块发送的冲正请求向各应用的事务数据源发送事务冲正指令;
在所述各应用和/或事务管理模块中定义事务管理属性;
流式计算模块:用于实时获取并识别事件的信息,并实时获取事务管理属性,定期验证事务状态,根据事务状态向事务管理器反馈事务状态,并发起查证请求和/或冲正请求。
作为优选的实施方式,所述的分布式事务处理装置,还可包括报警模块,用于根据事务管理模块发出的报警指令,发送运维报警信息,当流式计算模块反馈的事务状态为异常事件时,事务管理器向各应用发送事务状态查证指令,当流式计算结果反馈结果仍然为异常事件时,事务管理器发出运维报警指令。
作为优选实施方式,在分布式应用模块中,所述应用包括一个分布式事务协调者和若干分布式事务参与者,所述分布式事务协调者是分布式事务的发起方和提交方,其通过事务API、注解或事务定义文件的方式开启分布式事务;所述分布式事务协调者和若干分布式事务参与者通过事务ID实现对下游事务参与者的远程调用。
优选地,所述事务ID包括全局事务ID(UOW_Global_ID)、本地事务ID(UOW_Local_ID)和分支号(Span_id),所述各应用全局事务ID相同,分布式事务协调者的分支号默认为0,分支号按照应用间的上下游关系逐渐递增,所述分布式事务参与者基于全局事务ID(UOW_id)和分支号(Span_id)生成本地事务ID,并传递给下游分布式事务参与者。
优选地,在所述事件定义模块中,所述事件包括事务开始事件、事务结束事件、异常事件、应用调用事件、应用被调用事件、应用持久层事件、事务数据源持久化事件中的一种或多种;其中:
所述事务开始事件的信息包括事务ID、应用信息、时间信息中的一种或多种;
所述事务结束事件的信息包括事务ID、应用信息、时间信息、事务结果中的一种或多种;
所述异常事件指未被应用捕获事务处理结果的事务运行状态;
应用调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用被调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用持久层事件的信息包括事务ID、会话信息中的一种多或多种;
所述事务数据源持久化事件的信息包括会话信息、持久化日志中的一种或多种。
作为优选实施方式,所述事件定义模块由切片程序组成,通过切片程序生成各事件对应的事务日志,并通过流式计算实时获取所述事务日志。
优选地,所述事务管理属性包括事务名称、事务传播属性、事务隔离属性、超时设置、回滚控制、提交控制、只读配置、未明状态策略中的一种或多种。
优选地,所述流式计算模块通过Apache Storm,Spark Streaming,Flink,Flume,Kafka中的一种或多种流式计算平台实现。
本发明所述技术方案采用流式计算技术及事件驱动理念,公开了一种对应用无侵害且数据准强一致的分布式事务的处理技术,通过本发明所述技术方案,应用开发者只需关心业务逻辑,无需设计任何分布式事务控制逻辑,例如冲正交易;且数据准强一致,一旦原子操作出现程序异常,迅速回滚数据更新,保证原子性;分布式节点的数据操作无需上时间持有锁,保证高并发高吞吐。本发明所述技术方案在实现应用的快速开发同时解决困扰分布式环境的事务一致性问题。
具体而言,与现有技术中常见的三种事务处理方法相比,本发明所述技术方案至少存在以下优点:
1、与现有技术方案二和方案三相比,本发明所述技术方案中事务控制与应用开发完全解耦,应用开发者只需关心业务逻辑,无需设计任何分布式事务控制逻辑,例如冲正交易极大简化开发难度,能够有效的提高开发效率,降低人力成本。
2、与现有技术方案二和方案三相比,本发明所述技术方案通过流式计算实现事务控制的实时计算,保证事务的整体提交,实现异常场景下的事务快速回滚,保证事务的原子性,数据准强一致,一旦原子操作出现程序异常,迅速回滚数据更新。
3、与现有技术方案一相比,本发明所述技术方案采用分布式设计,容忍任意节点的故障,没有脑裂问题,且分布式节点的数据操作无需上时间持有锁,保证高并发高吞吐。
4、应用级与事务管理器结合事务处理的需求定义事务管理属性,实现灵活热加载模式的事务控制。
附图说明
图1为原子事务场景示例图;
图2为原子事务持久化操作顺序图;
图3为因应用异常触发原子事务回滚的流程示意图;
图4为本发明所述分布式事务处理方法总体逻辑结构图;
图5为本发明所述分布式事务处理方实施例逻辑结构图;
图6为本发明实施例分布式事务协调者注解代码示例图;
图7为本发明实施例事务管理属性定义代码示例图;
图8为为本发明实施例事务ID调用树状图;
图9为本发明实施例数据源日志与事务ID关联关系图。
具体实施方式
为了使本发明技术方案更容易理解,现结合附图采用具体实施例的方式,对本发明的技术方案进行清晰、完整的描述。应当注意,在此所述的实施例仅为本发明的部分实施例,而非本发明的全部实现方式,所述实施例只有示例性,其作用只在于为审查员及公众提供理解本发明内容更为直观明了的方式,而不是对本发明所述技术方案的限制。在不脱离本发明构思的前提下,所有本领域普通技术人员没有做出创造性劳动就能想到的其它实施方式,及其它对本发明技术方案的简单替换和各种变化,都属于本发明的保护范围。
下文以银行事务处理为例,对本发明所述技术方案进行具体说明。
如图1中原子事务场景示例图所示,例如1家企业的IT***由4个应用模块组成,客户发来的请求通过渠道层(如API网关)进入生产***,A应用作为前置应用将对用户请求进行处理,操作关系型数据库,然后调用B应用;B应用运行处理逻辑后持久化处理数据入库,然后调用C应用;C应用进行数据库操作返回;B应用进一步调用应用D;D应用进行数据库操作返回;B应用返回A应用;A应用将客户信息记录在KV存储里,然后成功返回给客户。所以在这个原子请求中,4个应用组件分别对4个数据库和1个键值存储进行了修改,顺序如图2所示。这些修改就是原子事务提交的持久化结果(ACID中的D属性)。
如图3所示,事务的原子性要求一旦在事务运行中发生异常,触发事务回滚,那么事务过程中的所有状态性变更都需要回退到事务开始之前的状态。例如在上述示例中,如果D应用在被B应用调用过程中发生异常触发回滚,那么已经进行的属于本次事务的变更都需要回滚,包括A应用的数据库操作1,B应用的数据库操作2和C应用的数据库操作3。对于客户来说,一笔回滚的事务就像什么也没发生过,例如客户转1000到另一个账户,如果交易失败,那么客户自身账户的金额不能减少,同时转账账户的金额也不能增加。
现有技术中的几种事务处理方式中,方案一主要应用于集中式构架,在传统昂贵的集中式架构下,硬件的稳定性非常高,四个应用***运行于商业级成熟中间件里,事务控制通过方案一(两阶段)实现;但是对于分布式云平台,硬件个体的能力和稳定性较差,硬件故障和软件缺陷发生频度较高,方案一容易出现脑裂现象,例如A应用作为两阶段的调度者一旦出现问题,事务处理涉及的库表将长时间被锁住,造成***不可用;方案二的问题在于应用***需要提供T/C/C三种实现接口,替代中间件实现事务控制,开发难度高,周期长且质量无法保证;方案三仍然有应用控制事务,但是较方案二适当降低了事务控制难度,代价放弃了事务一致性,追求最终一致。
本发明具体公开了一种分布式事务处理方法,如图4和图5所示,包括:
设置应用的步骤:在分布式***中开发实现事务处理所需的若干应用,所述各应用在分布式***中设有本地事务数据源,以实现本地化数据存储及更新;
在本实施方式中,应用是分布式事务的发起方和提交方,应用可以进一步细化分布式事务协调者(如图4中的应用A)和分布式事务参与者(图4示例中的应用B,C,D)。分布式事务协调者可以通过事务API、注解或事务定义文件的方式开启分布式事务,以Java代码编写的注解方式为例,(本发明并不仅限于Java实现),所述分布式事务协调者的注解方式如图6所示。
应用A是分布式事务的入口和协调者,@Transactional是Java通用的事务声明方式,用来开发事务。分布式事物协调者也可以通过程序定义事务管理属性,例如超时信息,回滚信息,事务标识,未明状态策略等,具体实施方式可按照如图7所示方法实现。
所述事务管理属性还可以在事务管理器中定义,实现更加灵活的事务管理。
如图5所示,开启事务之后,在应用A的应用上下文(Appplication Context)中形成事务上下文(Transaction Context),为了保证全局性,事务上下文中将包含全局事务ID(UOW_Global_ID)。UOW_id将作为分布式事务的全局性标识,并被传播到下游事务参与者。同时事务协调者还具备一个本地事务ID(UOW_Local_ID),本地事务ID基于全局事务ID(UOW_id)和分支号(Span_id,默认递增)。事务协调者的Span_id默认为0。每一次远程调用,事务参与者将基于全局事务ID(UOW_id)和分支号(Span_id)生成本地的事务ID,并传递给下游事务参与者,具体调用方式如图8所示。通过这种机制,事务ID在应用调用链路的上下游轮转,并可以通过Span_ID标识调用顺序。
如图9所示,原子事务产生的持久化更新,可通过各应用本地事务数据源来实现,例如关系型数据库的CRUD操作,键值存储的更新等。对于应用本地事务数据源来说,每次更新都会生成日志文件,记录更新的数据变化,例如MySQL数据库的Binlog数据。本方法通过数据访问层(DAO)将事务ID与数据源层的日志进行关联,标识分布式事务的各应用本地数据源更新日志。本方案中所有的本地数据操作都将本地提交,释放数据资源。
事务管理属性定义的步骤:根据事务处理的需求定义事务管理属性;事务管理属性定义可在应用层或事务管理器中进行。所述事务管理属性包括事务名称、事务传播属性、事务隔离属性、超时设置、回滚控制、提交控制、只读配置、未明状态策略中的一种或多种。
事件定义的步骤:将事务处理过程中的若干特定状态变化定义为事件;如表1所示:
表1:(发明实施例事件类型和采集信息示例表)
所述事件包括事务开始事件、事务结束事件、异常事件、应用调用事件、应用被调用事件、应用持久层事件、事务数据源持久化事件中的一种或多种;其中:
所述事务开始事件的信息包括事务ID、应用信息、时间信息中的一种或多种;
所述事务结束事件的信息包括事务ID、应用信息、时间信息、事务结果中的一种或多种;
所述异常事件指未被应用捕获事务处理结果的事务运行状态;
应用调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用被调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用持久层事件的信息包括事务ID、会话信息中的一种多或多种;
所述事务数据源持久化事件的信息包括会话信息、持久化日志中的一种或多种。
所述各事件的信息可通过应用埋点技术或通信旁路技术生成各事件对应的事务日志的方式,供流式计算步骤实时获取并识别事件的信息。
事件通过应用切片埋点方式形成应用日志,数据源产生更新日志,然后通过流式技术采集,实现事务信息采集对应用开发的零侵害。
流式计算的步骤:通过流式计算实时获取并识别事件的信息,并实时获取事务管理属性,根据事件的信息和事务管理属性定期验证事务状态,根据事务状态向事务管理器反馈事务状态,并发起查证请求和/或冲正请求。在本发明所述方法使用于银行类业务的实施例中,所述冲正请求可为事务状态变更记录的回滚请求。
所述流式计算通过Apache Storm,Spark Streaming,Flink,Flume,Kafka中的一种或多种流式计算平台实现。其中,Apache Storm,Spark Streaming和Flink可用于实时计算,Flume可用于数据采集,Kafka可用于消息流转。
如图4和图5所示,所述流式计算的步骤通过以下方式实现:
流式计算组建实时采集事件的信息,识别事务开启事件,并从应用或者事务管理器中获取事务管理属性,缓存事务处理过程中的所有事务性持久化信息,并根据事件的信息和事务管理属性定期进行事务状态验证,具体包括:
1)如果分布式事务协调者提交事务,通过流式计算确认所有应用中的事务数据源的完成情况,以完成事务提交;如果确认结果为完成,清理缓存数据;否则发送查证请求给事务处理器;
2)如果分布式事务协调者回滚事务,通过流式计算确认所有应用中事务数据源均完成回滚操作:如果确认,清理缓存数据;否则向事务管理器发送回滚请求,由事务管理器向对应事务数据源发起回滚指令;
3)如果分布式事务协调者在事务超时周期内未发起提交或者回滚,事务进入未明状态,此时通过流式计算判断事务管理属性中的未明状态策略,如果策略为回滚,通过流式计算检查各应用中的事务源状态,对未回滚的事务数据源生成回滚请求,发给事务管理器,由事务管理器向未回滚的事务数据源发起回滚;如果策略为提交,通过流式计算检查各应用的事务数据源提交状态,如果存在未提交事务,发送查证请求给事务管理器。
在本发明所述的分布式事务处理方法优选实施方式中,所述回滚指令的执行按照本地事务ID中的分支号(Span_id)逆序操作。
事务管理的步骤:事务管理器根据查证请求向各应用发送事务状态查证指令,和/或根据冲正请求向各应用的事务数据源发送事务冲正指令。
事务管理器的另外一个作用就是根据流式计算捕捉到的回滚指令与回滚内容,向事务数据源发起直接回滚指令,例如如果流式通过解析MySQL的Binlog识别正向更新是INSERT指令,那么回滚指令是***记录进行DELETE操作。也就是说事务管理器完成原来在冲正应用中的反向操作。回滚指令的执行按照本地事务ID中的Span_id逆序操作。
在本发明所述的分布式事务处理方法优选实施方式中,还包括报警的步骤:当流式计算反馈的事务状态为异常事件时,事务管理器向各应用发送事务状态查证指令,当流式计算结果反馈结果仍然为异常事件时,事务管理器发出运维报警指令。如果流式提交检查异常,事务管理器将进行二次查证并根据情况出发运维报警。
本发明同时还提供了一种分布式事务处理装置,包括:
分布式应用模块:包括分布于分布式***中用于事务处理的若干应用,以及在分布式***中各应用对应的本地事务数据源,以实现各应用本地化数据存储及更新;
事件定义模块:用于生成各事件对应的事务日志,所述事件为事务处理过程中的特定状态变化;
事务管理模块:用于根据流式计算模块发送的查证请求向各应用发送事务状态查证指令,和/或根据流式计算模块发送的冲正请求向各应用发送事务冲正指令;
在所述各应用和/或事务管理模块中定义事务管理属性;
流式计算模块:用于实时获取并识别事件的信息,并实时获取事务管理属性,定期验证事务状态,根据事务状态向事务管理器反馈事务状态,并发起查证请求和/或冲正请求。
作为优选的实施方式,所述的分布式事务处理装置,还可包括报警模块,用于根据事务管理模块发出的报警指令,发送运维报警信息,当流式计算模块反馈的事务状态为异常事件时,事务管理器向各应用发送事务状态查证指令,当流式计算结果反馈结果仍然为异常事件时,事务管理器发出运维报警指令。
作为优选实施方式,在分布式应用模块中,所述应用包括一个分布式事务协调者和若干分布式事务参与者,所述分布式事务协调者是分布式事务的发起方和提交方,其通过事务API、注解或事务定义文件的方式开启分布式事务;所述分布式事务协调者和若干分布式事务参与者通过事务ID实现对下游事务参与者的远程调用。
优选地,所述事务ID包括全局事务ID(UOW_Global_ID)、本地事务ID(UOW_Local_ID)和分支号(Span_id),所述各应用全局事务ID相同,分布式事务协调者的分支号默认为0,分支号按照应用间的上下游关系逐渐递增,所述分布式事务参与者基于全局事务ID(UOW_id)和分支号(Span_id)生成本地事务ID,并传递给下游分布式事务参与者。
优选地,在所述事件定义模块中,所述事件包括事务开始事件、事务结束事件、异常事件、应用调用事件、应用被调用事件、应用持久层事件、事务数据源持久化事件中的一种或多种;其中:
所述事务开始事件的信息包括事务ID、应用信息、时间信息中的一种或多种;
所述事务结束事件的信息包括事务ID、应用信息、时间信息、事务结果中的一种或多种;
所述异常事件指未被应用捕获事务处理结果的事务运行状态;
应用调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用被调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用持久层事件的信息包括事务ID、会话信息中的一种多或多种;
所述事务数据源持久化事件的信息包括会话信息、持久化日志中的一种或多种。
作为优选实施方式,所述事件定义模块由切片程序组成,通过切片程序生成各事件对应的事务日志,并通过流式计算实时获取所述事务日志。
优选地,所述事务管理属性包括事务名称、事务传播属性、事务隔离属性、超时设置、回滚控制、提交控制、只读配置、未明状态策略中的一种或多种。
优选地,所述流式计算模块通过Apache Storm,Spark Streaming,Flink,Flume,Kafka中的一种或多种流式计算平台实现。
Claims (18)
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,Spark Streaming,Flink,Flume,Kafka中的一种或多种流式计算平台实现。
8.根据权利要求5所述的分布式事务处理方法,其特征在于:所述流式计算的步骤通过以下方式实现:
实时采集事件的信息,识别事务开启事件,并从应用或者事务管理器中获取事务管理属性,缓存事务处理过程中的所有事务性持久化信息,并定期进行事务状态验证:
1)如果分布式事务协调者提交事务,通过流式计算确认所有应用中的事务数据源的完成情况,以完成事务提交;如果确认结果为完成,清理缓存数据;否则发送查证请求给事务处理器;
2)如果分布式事务协调者回滚事务,通过流式计算确认所有应用中事务数据源均完成回滚操作:如果确认,清理缓存数据;否则向事务管理器发送回滚请求,由事务管理器向对应事务数据源发起回滚指令;
3)如果分布式事务协调者在事务超时周期内未发起提交或者回滚,事务进入未明状态,此时通过流式计算判断事务管理属性中的未明状态策略,如果策略为回滚,通过流式计算检查各应用中的事务源状态,对未回滚的事务数据源生成回滚请求,发给事务管理器,由事务管理器向未回滚的事务数据源发起回滚;如果策略为提交,通过流式计算检查各应用的事务数据源提交状态,如果存在未提交事务,发送查证请求给事务管理器。
9.根据权利要求8所述的分布式事务处理方法,其特征在于:所述回滚指令的执行按照本地事务ID中的分支号(Span_id)逆序操作。
10.根据权利要求1-9中任一项所述的分布式事务处理方法,其特征在于,还包括报警的步骤:当流式计算反馈的事务状态为异常事件时,事务管理器向各应用发送事务状态查证指令,当流式计算结果反馈结果仍然为异常事件时,事务管理器发出运维报警指令。
11.一种分布式事务处理装置,其特征在于,包括:
分布式应用模块:包括分布于分布式***中用于事务处理的若干应用,以及在分布式***中各应用对应的本地事务数据源;
事件定义模块:用于生成各事件对应的事务日志,所述事件为事务处理过程中的特定状态变化;
事务管理模块:用于根据流式计算模块发送的查证请求向各应用发送事务状态查证指令,和/或根据流式计算模块发送的冲正请求向各应用的事务数据源发送事务冲正指令;
在所述各应用和/或事务管理模块中定义事务管理属性;
流式计算模块:用于实时获取并识别事件的信息,并实时获取事务管理属性,定期验证事务状态,根据事务状态向事务管理器反馈事务状态,并发起查证请求和/或冲正请求。
12.根据权利要求11所述的分布式事务处理装置,其特征在于:
还包括报警模块,用于根据事务管理模块发出的报警指令,发送运维报警信息,当流式计算模块反馈的事务状态为异常事件时,事务管理器向各应用发送事务状态查证指令,当流式计算结果反馈结果仍然为异常事件时,事务管理器发出运维报警指令。
13.根据权利要求11所述的分布式事务处理装置,其特征在于:分布式应用模块中,所述应用包括一个分布式事务协调者和若干分布式事务参与者,所述分布式事务协调者是分布式事务的发起方和提交方,其通过事务API、注解或事务定义文件的方式开启分布式事务;所述分布式事务协调者和若干分布式事务参与者通过事务ID实现对下游事务参与者的远程调用。
14.根据权利要求13所述的分布式事务处理装置,其特征在于:所述事务ID包括全局事务ID(UOW_Global_ID)、本地事务ID(UOW_Local_ID)和分支号(Span_id),所述各应用全局事务ID相同,分布式事务协调者的分支号默认为0,分支号按照应用间的上下游关系逐渐递增,所述分布式事务参与者基于全局事务ID(UOW_id)和分支号(Span_id)生成本地事务ID,并传递给下游分布式事务参与者。
15.根据权利要求14所述的分布式事务处理装置,其特征在于:在所述事件定义模块中,所述事件包括事务开始事件、事务结束事件、异常事件、应用调用事件、应用被调用事件、应用持久层事件、事务数据源持久化事件中的一种或多种;其中:
所述事务开始事件的信息包括事务ID、应用信息、时间信息中的一种或多种;
所述事务结束事件的信息包括事务ID、应用信息、时间信息、事务结果中的一种或多种;
所述异常事件指未被应用捕获事务处理结果的事务运行状态;
应用调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用被调用事件的信息包括事务ID、调用方应用信息、被调用方应用信息、时间信息中的一种或多种;
所述应用持久层事件的信息包括事务ID、会话信息中的一种多或多种;
所述事务数据源持久化事件的信息包括会话信息、持久化日志中的一种或多种。
16.根据权利要求15所述的分布式事务处理装置,其特征在于:所述事件定义模块由切片程序组成,通过切片程序生成各事件对应的事务日志,并通过流式计算实时获取所述事务日志。
17.根据权利要求11所述的分布式事务处理装置,其特征在于:所述事务管理属性包括事务名称、事务传播属性、事务隔离属性、超时设置、回滚控制、提交控制、只读配置、未明状态策略中的一种或多种。
18.根据权利要求11所述的分布式事务处理方法,其特征在于:所述流式计算通过Apache Storm,Spark Streaming,Flink,Flume,Kafka中的一种或多种流式计算平台实现。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810273667.7A CN108459919B (zh) | 2018-03-29 | 2018-03-29 | 一种分布式事务处理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810273667.7A CN108459919B (zh) | 2018-03-29 | 2018-03-29 | 一种分布式事务处理方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN108459919A true CN108459919A (zh) | 2018-08-28 |
CN108459919B CN108459919B (zh) | 2022-04-15 |
Family
ID=63238199
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810273667.7A Active CN108459919B (zh) | 2018-03-29 | 2018-03-29 | 一种分布式事务处理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN108459919B (zh) |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109408203A (zh) * | 2018-11-01 | 2019-03-01 | 无锡华云数据技术服务有限公司 | 一种队列消息一致性的实现方法、装置、计算*** |
CN109451078A (zh) * | 2019-01-10 | 2019-03-08 | 网易(杭州)网络有限公司 | 一种分布式架构下的事务处理方法和装置 |
CN109656740A (zh) * | 2018-12-11 | 2019-04-19 | 国云科技股份有限公司 | 一种支持超时处理任务流的方法 |
CN109669809A (zh) * | 2018-09-11 | 2019-04-23 | 深圳平安财富宝投资咨询有限公司 | 分布式事务处理方法、分布式***及计算机可读存储介质 |
CN109783205A (zh) * | 2019-01-03 | 2019-05-21 | 山东浪潮通软信息科技有限公司 | 一种基于事件补偿机制的数据最终一致性办法 |
CN109918216A (zh) * | 2019-03-07 | 2019-06-21 | 山东浪潮通软信息科技有限公司 | 一种基于管道的数据处理方法和*** |
CN109933412A (zh) * | 2019-01-28 | 2019-06-25 | 武汉慧联无限科技有限公司 | 基于分布式消息中间件的分布式事务处理方法 |
CN110162532A (zh) * | 2019-05-09 | 2019-08-23 | 中国银行股份有限公司 | 交易数据处理方法和设备 |
CN110288255A (zh) * | 2019-06-28 | 2019-09-27 | 深圳前海微众银行股份有限公司 | 一种分布式事务的流程保障方法及装置 |
CN110347482A (zh) * | 2019-07-18 | 2019-10-18 | 哈尔滨汇拓投资中心(有限合伙) | 基于OLTPShare的OLTP事务结合规则与队列模型改进方法 |
CN110704206A (zh) * | 2019-09-09 | 2020-01-17 | 上海凯京信达科技集团有限公司 | 一种实时计算方法、计算机存储介质及电子设备 |
CN111078451A (zh) * | 2019-08-05 | 2020-04-28 | 腾讯科技(深圳)有限公司 | 分布式事务处理方法、装置、计算机设备及存储介质 |
CN111161059A (zh) * | 2019-11-29 | 2020-05-15 | 合肥学院 | 一种将事务处理泛化成交易的方法 |
CN111813791A (zh) * | 2020-06-17 | 2020-10-23 | 上海悦易网络信息技术有限公司 | 一种分布式补偿事务的方法及设备 |
CN111813583A (zh) * | 2020-07-28 | 2020-10-23 | 厦门市易联众易惠科技有限公司 | 微服务架构下的事务管理方法、装置、设备及存储介质 |
CN112597176A (zh) * | 2020-12-25 | 2021-04-02 | 中国农业银行股份有限公司 | 一种分布式数据库的事务保存点的处理方法及*** |
CN112732414A (zh) * | 2020-12-29 | 2021-04-30 | 北京浪潮数据技术有限公司 | 一种oltp模式的分布式事务处理方法、***及相关组件 |
CN112995306A (zh) * | 2021-02-05 | 2021-06-18 | 建信金融科技有限责任公司 | 一种基于storm的实时账务信息处理方法及*** |
CN113032176A (zh) * | 2021-03-23 | 2021-06-25 | 中国邮政储蓄银行股份有限公司 | 基于日终对账的分布式事务双补偿方法与装置 |
CN113051044A (zh) * | 2021-04-20 | 2021-06-29 | 中国工商银行股份有限公司 | 一种基于无服务架构的分布式事务处理方法及装置 |
US20210240516A1 (en) * | 2020-02-05 | 2021-08-05 | International Business Machines Corporation | Distributed transaction management |
CN113742034A (zh) * | 2020-05-29 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 事件处理方法与装置、计算机可读存储介质、电子设备 |
CN114066476A (zh) * | 2021-11-30 | 2022-02-18 | 武汉众邦银行股份有限公司 | 一种解决分布式应用交易后发先至的方法、装置及存储介质 |
CN116303517A (zh) * | 2023-05-12 | 2023-06-23 | 无锡锡商银行股份有限公司 | 一种分布式事务调度管理***及方法 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2014175924A (ja) * | 2013-03-11 | 2014-09-22 | Hitachi Ltd | 伝送システム、伝送装置、及び伝送方法 |
CN105574205A (zh) * | 2016-01-18 | 2016-05-11 | 国家电网公司 | 分布式计算环境的日志动态分析*** |
CN106250444A (zh) * | 2016-07-27 | 2016-12-21 | 北京集奥聚合科技有限公司 | 一种异构数据源的实时入库***及方法 |
US9596641B2 (en) * | 2012-01-04 | 2017-03-14 | Ofinno Technologies, Llc | Packet forwarding in wireless networks |
-
2018
- 2018-03-29 CN CN201810273667.7A patent/CN108459919B/zh active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9596641B2 (en) * | 2012-01-04 | 2017-03-14 | Ofinno Technologies, Llc | Packet forwarding in wireless networks |
JP2014175924A (ja) * | 2013-03-11 | 2014-09-22 | Hitachi Ltd | 伝送システム、伝送装置、及び伝送方法 |
CN105574205A (zh) * | 2016-01-18 | 2016-05-11 | 国家电网公司 | 分布式计算环境的日志动态分析*** |
CN106250444A (zh) * | 2016-07-27 | 2016-12-21 | 北京集奥聚合科技有限公司 | 一种异构数据源的实时入库***及方法 |
Cited By (34)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN109669809A (zh) * | 2018-09-11 | 2019-04-23 | 深圳平安财富宝投资咨询有限公司 | 分布式事务处理方法、分布式***及计算机可读存储介质 |
CN109408203A (zh) * | 2018-11-01 | 2019-03-01 | 无锡华云数据技术服务有限公司 | 一种队列消息一致性的实现方法、装置、计算*** |
CN109656740A (zh) * | 2018-12-11 | 2019-04-19 | 国云科技股份有限公司 | 一种支持超时处理任务流的方法 |
CN109783205A (zh) * | 2019-01-03 | 2019-05-21 | 山东浪潮通软信息科技有限公司 | 一种基于事件补偿机制的数据最终一致性办法 |
CN109451078A (zh) * | 2019-01-10 | 2019-03-08 | 网易(杭州)网络有限公司 | 一种分布式架构下的事务处理方法和装置 |
CN109451078B (zh) * | 2019-01-10 | 2022-05-03 | 网易(杭州)网络有限公司 | 一种分布式架构下的事务处理方法和装置 |
CN109933412A (zh) * | 2019-01-28 | 2019-06-25 | 武汉慧联无限科技有限公司 | 基于分布式消息中间件的分布式事务处理方法 |
CN109918216A (zh) * | 2019-03-07 | 2019-06-21 | 山东浪潮通软信息科技有限公司 | 一种基于管道的数据处理方法和*** |
CN110162532A (zh) * | 2019-05-09 | 2019-08-23 | 中国银行股份有限公司 | 交易数据处理方法和设备 |
CN110288255A (zh) * | 2019-06-28 | 2019-09-27 | 深圳前海微众银行股份有限公司 | 一种分布式事务的流程保障方法及装置 |
CN110347482A (zh) * | 2019-07-18 | 2019-10-18 | 哈尔滨汇拓投资中心(有限合伙) | 基于OLTPShare的OLTP事务结合规则与队列模型改进方法 |
CN110347482B (zh) * | 2019-07-18 | 2021-07-23 | 哈尔滨汇拓投资中心(有限合伙) | 基于OLTPShare的OLTP事务结合规则与队列模型改进方法 |
CN111078451A (zh) * | 2019-08-05 | 2020-04-28 | 腾讯科技(深圳)有限公司 | 分布式事务处理方法、装置、计算机设备及存储介质 |
CN111078451B (zh) * | 2019-08-05 | 2021-05-11 | 腾讯科技(深圳)有限公司 | 分布式事务处理方法、装置、计算机设备及存储介质 |
CN110704206A (zh) * | 2019-09-09 | 2020-01-17 | 上海凯京信达科技集团有限公司 | 一种实时计算方法、计算机存储介质及电子设备 |
CN111161059A (zh) * | 2019-11-29 | 2020-05-15 | 合肥学院 | 一种将事务处理泛化成交易的方法 |
CN111161059B (zh) * | 2019-11-29 | 2023-10-31 | 合肥学院 | 一种将事务处理泛化成交易的方法 |
US20210240516A1 (en) * | 2020-02-05 | 2021-08-05 | International Business Machines Corporation | Distributed transaction management |
CN113742034A (zh) * | 2020-05-29 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 事件处理方法与装置、计算机可读存储介质、电子设备 |
CN111813791B (zh) * | 2020-06-17 | 2024-05-21 | 上海万物新生环保科技集团有限公司 | 一种分布式补偿事务的方法及设备 |
CN111813791A (zh) * | 2020-06-17 | 2020-10-23 | 上海悦易网络信息技术有限公司 | 一种分布式补偿事务的方法及设备 |
CN111813583A (zh) * | 2020-07-28 | 2020-10-23 | 厦门市易联众易惠科技有限公司 | 微服务架构下的事务管理方法、装置、设备及存储介质 |
CN111813583B (zh) * | 2020-07-28 | 2023-06-20 | 厦门市易联众易惠科技有限公司 | 微服务架构下的事务管理方法、装置、设备及存储介质 |
CN112597176A (zh) * | 2020-12-25 | 2021-04-02 | 中国农业银行股份有限公司 | 一种分布式数据库的事务保存点的处理方法及*** |
CN112597176B (zh) * | 2020-12-25 | 2024-06-11 | 中国农业银行股份有限公司 | 一种分布式数据库的事务保存点的处理方法及*** |
CN112732414A (zh) * | 2020-12-29 | 2021-04-30 | 北京浪潮数据技术有限公司 | 一种oltp模式的分布式事务处理方法、***及相关组件 |
CN112732414B (zh) * | 2020-12-29 | 2023-12-08 | 北京浪潮数据技术有限公司 | 一种oltp模式的分布式事务处理方法、***及相关组件 |
CN112995306B (zh) * | 2021-02-05 | 2023-10-20 | 建信金融科技有限责任公司 | 一种基于storm的实时账务信息处理方法及*** |
CN112995306A (zh) * | 2021-02-05 | 2021-06-18 | 建信金融科技有限责任公司 | 一种基于storm的实时账务信息处理方法及*** |
CN113032176A (zh) * | 2021-03-23 | 2021-06-25 | 中国邮政储蓄银行股份有限公司 | 基于日终对账的分布式事务双补偿方法与装置 |
CN113051044A (zh) * | 2021-04-20 | 2021-06-29 | 中国工商银行股份有限公司 | 一种基于无服务架构的分布式事务处理方法及装置 |
CN114066476A (zh) * | 2021-11-30 | 2022-02-18 | 武汉众邦银行股份有限公司 | 一种解决分布式应用交易后发先至的方法、装置及存储介质 |
CN116303517A (zh) * | 2023-05-12 | 2023-06-23 | 无锡锡商银行股份有限公司 | 一种分布式事务调度管理***及方法 |
CN116303517B (zh) * | 2023-05-12 | 2023-08-22 | 无锡锡商银行股份有限公司 | 一种分布式事务调度管理***及方法 |
Also Published As
Publication number | Publication date |
---|---|
CN108459919B (zh) | 2022-04-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108459919A (zh) | 一种分布式事务处理方法及装置 | |
CN104793988B (zh) | 跨数据库分布式事务的实现方法和装置 | |
JP7389793B2 (ja) | 分散型異種ストレージシステムにおけるデータ一貫性のリアルタイムチェックのための方法、デバイス、およびシステム | |
CN103782574B (zh) | 用于数据库事务的幂等性 | |
US8924346B2 (en) | Idempotence for database transactions | |
US9747356B2 (en) | Eager replication of uncommitted transactions | |
Samaras et al. | Two-phase commit optimizations and tradeoffs in the commercial environment | |
US9904721B1 (en) | Source-side merging of distributed transactions prior to replication | |
US20180173745A1 (en) | Systems and methods to achieve sequential consistency in replicated states without compromising performance in geo-distributed, replicated services | |
US20070083569A1 (en) | Commit-time ordered message queue supporting arbitrary read and dequeue patterns from multiple subscribers | |
US11947524B2 (en) | Transaction processing method and apparatus, computer device, and storage medium | |
JPH1069418A (ja) | 階層化トランザクション処理方法 | |
CN108596768A (zh) | 一种分布式事务处理方法、装置及*** | |
CN110413687A (zh) | 基于节点互证校验的分布式事务故障处理方法及相关设备 | |
CN109408201A (zh) | 基于分布式数据库的事务管理方法 | |
US7406486B1 (en) | Transforming transactions to increase parallelism when replicating | |
Masud et al. | Transaction processing in a peer to peer database network | |
Busetta et al. | A reliable computational model for BDI agents | |
Burger et al. | Performance of multiversion and distributed two-phase locking concurrency control mechanisms in distributed database | |
Padhye | Transaction and data consistency models for cloud applications | |
Rossi et al. | Data Resilience in the dCache Storage System | |
Grov et al. | Scalable and fully consistent transactions in the cloud through hierarchical validation | |
Shastry et al. | Transaction support for HBase | |
Zhou et al. | A system for managing remote procedure call transactions | |
Jenq | Performance measurement, modelling, and evaluation of integrated concurrency control and recovery algorithms in distributed database systems |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |