CN111158933A - 一种基于消息队列的分布式事务处理方法及*** - Google Patents
一种基于消息队列的分布式事务处理方法及*** Download PDFInfo
- Publication number
- CN111158933A CN111158933A CN201911404579.7A CN201911404579A CN111158933A CN 111158933 A CN111158933 A CN 111158933A CN 201911404579 A CN201911404579 A CN 201911404579A CN 111158933 A CN111158933 A CN 111158933A
- Authority
- CN
- China
- Prior art keywords
- message
- sending
- sequence number
- missing
- database
- 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.)
- Pending
Links
Images
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/546—Message passing systems or structures, e.g. queues
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
Abstract
本发明公开了一种基于消息队列的分布式事务处理方法及***,方法包括:对发送的消息进行顺序编号;将发送的消息及其顺序编号写入发送日志;发送消息给服务端,使服务端获取消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将消息发送给消息队列;根据起始顺序编号和结束顺序编号从发送日志中获取缺漏数据,并将缺漏数据发送给服务端。本发明利用了发送日志和在第一数据库这一非关系型数据库中存储的顺序编号来保证消息发送成功,从而确保了消息队列与业务***的数据一致性,也简化了业务***的开发过程。本发明可广泛应用于计算机技术领域。
Description
技术领域
本发明涉及计算机技术领域,尤其是一种基于消息队列的分布式事务处理方法及***。
背景技术
随着互联网及计算机技术的不断发展,分布式***以其高扩展性、高可用性、高可靠性及高效性等特点被广泛应用。随着IT(Information Technology,信息技术)***的复杂度越来越高,为解决分布式***的性能和数据问题,通过事件源构建业务***越来越重要,MQ(messagequeue,消息队列)因具有解耦、异步等优点在事件源中也被大规模使用。
然而,传统的MQ不支持基于关系型数据库的事务,导致MQ与业务***数据存在一致性的问题,也增加业务***开发的复杂性。
发明内容
本发明旨在至少解决现有技术中存在的技术问题之一。为此,本发明提出了一种基于消息队列的分布式事务处理方法及***,能保证消息发送成功以及数据的一致性。
根据本发明的第一方面实施例的一种基于消息队列的分布式事务处理方法,用于发送端,包括以下步骤:
对发送的消息进行顺序编号;
将发送的消息及其顺序编号写入发送日志;
发送消息给服务端,使所述服务端获取所述消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将所述消息发送给消息队列;
根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端;
其中,所述第一数据库为非关系型数据库。
进一步,所述将发送的消息及其顺序编号写入发送日志这一步骤,具体为:
在发送日志中写入发送时间、顺序编号、发送端标识、消息的散列值和消息内容。
进一步,所述根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端这一步骤,具体包括:
将所述起始顺序编号和所述结束顺序编号加入数据缺漏任务处理列表并发送给数据修复线程;
通过所述数据修复线程根据所述起始顺序编号和所述结束顺序编号解析所述发送日志,获取缺漏数据;
将所述缺漏数据重新发送给所述服务端。
根据本发明的第二方面实施例的一种基于消息队列的分布式事务处理方法,用于服务端,包括以下步骤:
接收发送端发送的消息;
获取所述消息的顺序编号作为当前编号;
从第一数据库中获取存储的所述发送端的顺序编号作为上一次编号;
确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端;
确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列;
其中,所述第一数据库为非关系型数据库。
进一步,所述确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端这一步骤,具体包括:
确定所述当前编号与所述上一次编号为不连续的编号,获取缺漏的起始顺序编号和结束顺序编号,并生成数据填补任务登记在第一数据库中;
将发送端发送不成功的消息、所述起始顺序编号和所述结束顺序编号返回给发送端。
进一步,所述确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端这一步骤,还具体包括:
将所述当前编号赋值給所述上一次编号并更新所述第一数据库;
接收发送端重新发送的携带有所述起始顺序编号和所述结束顺序编号的缺漏数据;
清除所述第一数据库的所述数据填补任务记录。
进一步,所述确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列这一步骤,具体包括:
确定所述当前编号与所述上一次编号为连续的编号,通过调用封装好的公共代码调用发送服务和写监控日志;
所述发送服务写入第二数据库,所述第二数据库为用于记录发送状态和发送次数的关系型数据库;
所述发送服务调用消息队列发送所述消息;
确定所述消息队列发送所述消息成功,更新所述第二数据库中所述发送状态为发送成功;
确定所述消息队列发送所述消息失败,更新所述第二数据库中所述发送状态为发送失败,将所述消息加入所述第一数据库的发送失败队列中等待重新发送,并将失败原因写入所述监控日志得到失败原因日志。
进一步,所述将所述消息加入所述第一数据库的发送失败队列中等待重新发送这一步骤,具体包括:
从所述发送失败队列中定时获取数据给所述发送服务,以调用所述消息队列来重新发送定时获取的数据。
进一步,所述将所述消息加入所述第一数据库的发送失败队列中等待重新发送这一步骤,还具体包括:
若重新发送的次数大于预设的最大发送次数,则将失败结果写入所述监控日志得到失败日志,并触发失败告警。
根据本发明的第三方面实施例的一种基于消息队列的分布式事务处理***,包括发送端和服务端,其中,所述发送端包括:
编号模块,用于对发送的消息进行顺序编号;
发送日志写入模块,用于将发送的消息及其顺序编号写入发送日志;
第一发送模块,用于发送消息给服务端,使所述服务端获取所述消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将所述消息发送给消息队列;
缺漏数据获取与重发送模块,用于根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端;
所述服务端包括:
接收模块,用于接收发送端发送的消息;
当前编号获取模块,用于获取所述消息的顺序编号作为当前编号;
上一次编号获取模块,用于从第一数据库中获取存储的所述发送端的顺序编号作为上一次编号;
缺漏数据修复模块,用于确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端;
第二发送模块,用于确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列;
其中,所述第一数据库为非关系型数据库。
本发明的有益效果是:当服务端接收的发送端的当前顺序编号与第一数据库中存储的发送端上一次的顺序编号不连续,通过服务端返回缺漏的起始顺序编号和结束顺序编号给发送端的方式,使发送端从发送日志中获取缺漏数据后重新发送给服务端,利用了发送日志和在第一数据库这一非关系型数据库中存储的顺序编号来保证消息发送成功,从而确保了消息队列与业务***的数据一致性,也简化了业务***的开发过程。
附图说明
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解,其中:
图1为本发明实施例一种基于消息队列的分布式事务处理方法用于发送端时的流程图;
图2为本发明实施例一种基于消息队列的分布式事务处理方法用于服务端时的流程图;
图3为本发明具体实施例发送端发送消息给服务端并进行数据修复的过程示意图;
图4为本发明具体实施例确认发送端发送成功后将消息发送到消息队列的流程图。
具体实施方式
下面详细描述本发明的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本发明,而不能理解为对本发明的限制。
在本发明的描述中,若干的含义是一个或者多个,多个的含义是两个以上,大于、小于、超过等理解为不包括本数。如果有描述到第一、第二、第三等只是用于区分技术特征为目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。
本发明的描述中,除非另有明确的限定,设置、安装、连接等词语应做广义理解,所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本发明中的具体含义。
如图1所示,本发明实施例提供了一种基于消息队列的分布式事务处理方法,用于发送端,包括以下步骤:
S101、对发送的消息进行顺序编号;
具体地,顺序编号是为了便于后续通过比较相邻两次的顺序编号是否连续来判定消息是否发送成功,其以进程为维度进行唯一控制。可选地,java中使用AtomLong计数来表示顺序编号。
S102、将发送的消息及其顺序编号写入发送日志;
具体地,写入发送日志是为了便于后续在服务端收到的数据缺漏时提供缺漏的数据以进行数据重新发送。可选地,发送日志内容包含但不限于:发送时间、顺序编号(如java的AtomLong计数这一唯一计数)、消息的hash(散列)值(用于校验消息的完整性,可使用MD5校验)、发送端标识(可用IP地址或主机名称)、消息内容(可以根据消息中信息的敏感度决定是否需要加密,如果加密,加密算法是可逆的,如可以使用RSA算法加密;如果加密,在从写入日志中恢复缺漏的数据时,需要解密)。
S103、发送消息给服务端,使所述服务端获取所述消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将所述消息发送给消息队列;
具体地,发送消息给服务端时可以通过消息报文的形式发送。第一数据库可以是K-V数据库NoSQL这一非关系型数据库,其主要存数结构是key(键)-value(值),其中value可采用Json串结构。服务端是事件源服务端,用于响应与处理业务***的事件或事务。事件(也可以称为事务)可以是一个业务流程的一部分,例如,一个交易订单已经发出;或者,事件也可能关于IT基础设施、中间件、应用程序和业务流程的监控信息。
服务端收到发送的消息报文后,可从消息报文中解析出本次(当前)接收的顺序编号,可记为编号(A),同时从第一数据库中通过查询等方式提取该发送端对应顺序编号(可选地,该发送端对应顺序编号可以是上一次成功接收到发送端消息的顺序编号),可记为编号(B)。然后将比较编号(A)和编号(B)是否为连续的编号。可选地,若编号(A)=编号(B)+1,则判定这两个编号为连续编号,表示当前发送端消息发送成功(即发送端没有丢失信息),反之,则判定这两个编号为不连续编号,表示当前发送端消息发送失败。
当判定这两个编号为连续编号,则认为发送端没有丢失信息,服务端返回发送成功的标识给发送端,并将接收的消息发送给消息队列,这样可以保证消息队列中的消息没有丢失。
当判定这两个编号为不连续编号,则认为发送端丢失了信息,此时需要确定缺漏的起始顺序编号和结束顺序编号并将缺漏的起始顺序编号和结束顺序编号返回给发送端。可选地,可以将本次(当前)接收的顺序编号作为缺漏的结束(最大)顺序编号,将上一次成功接收到发送端消息的顺序编号作为缺漏的起始(最小)顺序编号。
而发送端是事件源发送端,即事件创建者,其可以是应用程序、数据存储、服务、业务流程、发送器、传感器或者协作工具,比如即时消息传递或电子邮件应用程序等。
S104、根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端。
具体地,步骤S104可进一步细分为:
S1041、将所述起始顺序编号和所述结束顺序编号加入数据缺漏任务处理列表并发送给数据修复线程;
具体地,发送端可以通过数据缺漏任务处理列表来跟踪缺漏数据的获取处理。而数据修复线程则负责从发送日志中解析出需要补发的消息(即缺漏数据)并完成补发。
S1042、通过所述数据修复线程根据所述起始顺序编号和所述结束顺序编号解析所述发送日志,获取缺漏数据;
S1043、将所述缺漏数据重新发送给所述服务端。
具体地,可通过数据修复线程将缺漏数据重新发送给服务端,发送时可携带起始顺序编号和结束顺序编号一起发送,便于服务端进行接收与识别。服务端收到缺漏数据后即可补全缺漏数据。
综上所述,本发明发送端方法实施例将消息发送给服务端,使服务端当接收的发送端的当前顺序编号与第一数据库中存储的发送端上一次的顺序编号不连续,通过服务端返回缺漏的起始顺序编号和结束顺序编号给发送端的方式,使发送端从发送日志中获取缺漏数据后重新发送给服务端,利用了发送日志和在第一数据库这一非关系型数据库中存储的顺序编号来保证消息发送成功,从而确保了消息队列与业务***的数据一致性,也简化了业务***的开发过程。
如图2所示,本发明实施例提供了一种基于消息队列的分布式事务处理方法,用于服务端,包括以下步骤:
S201、接收发送端发送的消息;
具体地,发送端是事件源发送端,即事件创建者,其可以是应用程序、数据存储、服务、业务流程、发送器、传感器或者协作工具,比如即时消息传递或电子邮件应用程序等。发送端可通过消息报文的形式发送消息。事件(也可以称为事务)可以是一个业务流程的一部分,例如,一个交易订单已经发出;或者,事件也可能关于IT基础设施、中间件、应用程序和业务流程的监控信息。
S202、获取所述消息的顺序编号作为当前编号;
具体地,服务端接收到消息后,可从消息报文中解析出本次(当前)接收的顺序编号作为当前编号,可记为编号(A)。服务端是事件源服务端,用于响应与处理业务***的事件或事务。
S203、从第一数据库中获取存储的所述发送端的顺序编号作为上一次编号;
具体地,第一数据库可以是K-V数据库NoSQL这一非关系型数据库,其主要存数结构是key(键)-value(值),其中value可采用Json串结构。为了确认发送端消息是否发送成功,本实施例还需要在第一数据库中通过查询等方式提取该发送端对应顺序编号作为上一次编号,可记为编号(A)。可选地,该发送端对应顺序编号可以是上一次成功接收到发送端消息的顺序编号。
S204、确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端;
具体地,可通过比较编号(A)和编号(B)是否为连续的编号来确定当前发送端消息是否发送成功(即发送端有没有丢失信息)。可选地,若编号(A)=编号(B)+1,则判定这两个编号为连续编号,表示当前发送端消息发送成功(即发送端没有丢失信息),反之,则判定这两个编号为不连续编号,表示当前发送端消息发送失败。
当判定这两个编号为不连续编号,则认为发送端丢失了信息,此时需要确定缺漏的起始顺序编号和结束顺序编号并将缺漏的起始顺序编号和结束顺序编号返回给发送端。
而步骤S204又可进一步细分为以下步骤S2041-S2045:
S2041、确定所述当前编号与所述上一次编号为不连续的编号,获取缺漏的起始顺序编号和结束顺序编号,并生成数据填补任务登记在第一数据库中;
可选地,可以将当前编号作为缺漏的结束(最大)顺序编号,将上一次编号作为缺漏的起始(最小)顺序编号。数据填补任务是服务端端登记需要补发消息的任务,包含有缺漏数据的顺序编号。
S2042、将发送端发送不成功的消息、所述起始顺序编号和所述结束顺序编号返回给发送端;
具体地,为了使得发送端重新获取并发送缺漏数据,服务端还会将发送端发送不成功的消息、缺漏的起始顺序编号和结束顺序编号返回给发送端。
S2043、将所述当前编号赋值給所述上一次编号并更新所述第一数据库;
具体地,在服务端向发送端通知需要获取缺漏数据后,服务端可以将第一数据库的上一次编号更新为当前编号,这样服务端在收到重新发送的缺漏数据后即可清除数据填补任务并结束服务端对发送端发送消息的验证过程。下一次收到新的消息时,服务端即可将当前编号与下一次的顺序编号进行比较来达到判定发送端发送是否成功的目的。
S2044、接收发送端重新发送的携带有所述起始顺序编号和所述结束顺序编号的缺漏数据;
具体地,发送端重新发送的缺漏数据可以携带起始顺序编号和结束顺序编号这两个数据填补任务号来发送,便于服务端接收与识别。
S2045、清除所述第一数据库的所述数据填补任务记录。
S205、确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列。
具体地,当判定当前编号与上一次编号这两个编号为连续编号,则认为发送端没有丢失信息,服务端返回发送成功的标识给发送端,并将接收的消息发送给消息队列,这样可以保证消息队列中的消息没有丢失。
进一步,步骤S205中确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列,可具体包括:
S20511、确定所述当前编号与所述上一次编号为连续的编号,通过调用封装好的公共代码调用发送服务和写监控日志;
具体地,封装好的公共代码可以是在common中封装好的公共消息队列(如Kafka)发送代码。监控日志是为了对消息队列的发送状态进行监控。
S20512、所述发送服务写入第二数据库,所述第二数据库为用于记录发送状态和发送次数的关系型数据库;
可选地,第二数据库可以是RDBMS(Relational Database Management System,关系型数据库管理***)数据库。
S20513、所述发送服务调用消息队列发送所述消息;
S20514、确定所述消息队列发送所述消息成功,更新所述第二数据库中所述发送状态为发送成功;
S20515、确定所述消息队列发送所述消息失败,更新所述第二数据库中所述发送状态为发送失败,将所述消息加入所述第一数据库的发送失败队列中等待重新发送,并将失败原因写入所述监控日志得到失败原因日志。
而步骤S20515中将所述消息加入所述第一数据库的发送失败队列中等待重新发送这一步骤,具体包括:
从所述发送失败队列中定时获取数据给所述发送服务,以调用所述消息队列来重新发送定时获取的数据。
可选地,在失败队列的数据被消息队列重新发送后,若重新发送的次数大于预设的最大发送次数(即多次发送仍失败),则将失败结果写入所述监控日志得到失败日志,并触发失败告警来通知用户对消息队列进行检查。
综上所述,本发明服务端方法实施例当服务端接收的发送端的当前顺序编号与第一数据库中存储的发送端上一次的顺序编号不连续,通过服务端返回缺漏的起始顺序编号和结束顺序编号给发送端的方式,使发送端从发送日志中获取缺漏数据后重新发送给服务端,利用了发送日志和在第一数据库这一非关系型数据库中存储的顺序编号来保证消息发送成功,从而确保了消息队列与业务***的数据一致性,也简化了业务***的开发过程。
基于上述图1和图2的方法实施例描述,可以得知,本发明具体实施例基于消息队列的分布式事务处理方法主要包括以下两个过程:
一)消息发送和对缺漏的发送消息进行数据恢复
如图3所示,该过程的具体实现过程为:
Step1、可靠事件源发送端(即发送端)直接调用封装好的公共Kafka发送代码(后文简称公共代码);
Step2、发送端通过公共代码完成发送服务调用;
Step3、发送端对发送的消息进行顺序编号,以进程为维度进行唯一控制;在java中使用AtomLong计数来进行顺序编号;
Step4、发送端将所发送的所有内容写入发送日志,发送日志内容包含:发送时间、唯一计数(即Step3的顺序编号)、消息hash(校验消息的完整性用途,使用MD5即可)、发送端标识(可用IP地址或主机名称)、消息内容(可以根据消息中信息的敏感度决定是否需要加密,如果加密,加密算法则是可逆的,如可以使用RSA算法加密;如果加密,在从发送日志中恢复信息时,需要解密);
Step5、可靠事件源服务端(后简称服务端)收到发送端信息后,解析出消息报文中的顺序编号,并从K-V数据库中提取该发送端对应顺序编号,并作比较,如果本次收到的消息的顺序编号与接收端K-V数据库中的顺序编号连续,则认为发送端没有丢失信息,此时返回SUCCESS,标识本次发送消息成功;如果不连续则返回SUCCESS_BUT_LEAK这一不成功标识和缺漏的起止顺序编号(本次接收到的是最大顺序号,上次接收并存储到K-V数据库的是起始顺序号),并产生一个数据填补任务(属于服务端登记需要补发消息的任务,包含缺漏数据的顺序编号,后文简称填补任务)登记在K-V数据库中;
Step6、更新接收端的当前发送端对应的顺序编号为该消息的顺序编号;
Step7、发送端收到SUCCESS_BUT_LEAK消息后,解析出缺漏的起止顺序号,并发送给发送端数据修复工人(即数据修复线程,负责从日志中解析出需要补发的消息并完成补发);
Step8、发送端数据修复工人解析发送日志,携带数据填补任务重发数据给服务端;
Step9、服务端受理消息并清除填补任务记录。
二)服务端在确认消息发送成功后将消息发送到消息队列MQ中
如图4所示,该过程可以进一步细分为以下步骤:
Step 1、发送服务写入RDBMS数据库,置发送状态为待发送,发送次数为0;
Step 2、发送服务调用MQ(MQ要求设置为手动提交)发送消息;
Step 3、如果MQ发送成功,则手动提交,并更新数据记录状态为“发送成功”,发送次数+1;
Step 4、如果MQ发送失败,更新状态为失败,发送次数+1,并加入发送失败队列,写失败原因日志;
Step 5、如果发送次数大于约定最大发送次数,写发送失败日志,触发告警;
Step 6、定时任务从“发送失败队列”中获取数据,并继续发送。
由上可得,本发明具体实施例通过结合RDBMS和K-V数据库协助解决直连MQ的业务***事务问题,确保MQ与业务事务的数据一致,通过监控日志等手段确保消息发送成功,解决了消息发送失败的问题,通过从RDBMS和发送日志中恢复数据,确保了数据的一致。整个实现过程简单、复用性好,简化了开发过程并且解决了分布式环境下的数据一致性问题。
基于图1和图2的方法实施例,本发明实施例还提供了一种基于消息队列的分布式事务处理***,包括发送端和服务端,其中,所述发送端包括:
编号模块,用于对发送的消息进行顺序编号;
发送日志写入模块,用于将发送的消息及其顺序编号写入发送日志;
第一发送模块,用于发送消息给服务端,使所述服务端获取所述消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将所述消息发送给消息队列;
缺漏数据获取与重发送模块,用于根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端;
所述服务端包括:
接收模块,用于接收发送端发送的消息;
当前编号获取模块,用于获取所述消息的顺序编号作为当前编号;
上一次编号获取模块,用于从第一数据库中获取存储的所述发送端的顺序编号作为上一次编号;
缺漏数据修复模块,用于确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端;
第二发送模块,用于确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列;
其中,所述第一数据库为非关系型数据库。
上述图1和图2的方法实施例中的内容均适用于本***实施例中,本***实施例所具体实现的功能与上述图1和图方法实施例相同,并且达到的有益效果与上述图1和图方法实施例所达到的有益效果也相同。
可以理解的是,上文中所公开方法中的全部或某些步骤、***可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器,如中央处理器、数字信号处理器或微处理器执行的软件,或者被实施为硬件,或者被实施为集成电路,如专用集成电路。这样的软件可以分布在计算机可读介质上,计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的,术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外,本领域普通技术人员公知的是,通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据,并且可包括任何信息递送介质。
上面结合附图对本发明实施例作了详细说明,但是本发明不限于上述实施例,在技术领域普通技术人员所具备的知识范围内,还可以在不脱离本发明宗旨的前提下作出各种变化。
Claims (10)
1.一种基于消息队列的分布式事务处理方法,其特征在于:包括以下步骤:
对发送的消息进行顺序编号;
将发送的消息及其顺序编号写入发送日志;
发送消息给服务端,使所述服务端获取所述消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将所述消息发送给消息队列;
根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端;
其中,所述第一数据库为非关系型数据库。
2.根据权利要求1所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述将发送的消息及其顺序编号写入发送日志这一步骤,具体为:
在发送日志中写入发送时间、顺序编号、发送端标识、消息的散列值和消息内容。
3.根据权利要求1所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端这一步骤,具体包括:
将所述起始顺序编号和所述结束顺序编号加入数据缺漏任务处理列表并发送给数据修复线程;
通过所述数据修复线程根据所述起始顺序编号和所述结束顺序编号解析所述发送日志,获取缺漏数据;
将所述缺漏数据重新发送给所述服务端。
4.一种基于消息队列的分布式事务处理方法,其特征在于:包括以下步骤:
接收发送端发送的消息;
获取所述消息的顺序编号作为当前编号;
从第一数据库中获取存储的所述发送端的顺序编号作为上一次编号;
确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端;
确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列;
其中,所述第一数据库为非关系型数据库。
5.根据权利要求4所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端这一步骤,具体包括:
确定所述当前编号与所述上一次编号为不连续的编号,获取缺漏的起始顺序编号和结束顺序编号,并生成数据填补任务登记在第一数据库中;
将发送端发送不成功的消息、所述起始顺序编号和所述结束顺序编号返回给发送端。
6.根据权利要求5所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端这一步骤,还具体包括:
将所述当前编号赋值給所述上一次编号并更新所述第一数据库;
接收发送端重新发送的携带有所述起始顺序编号和所述结束顺序编号的缺漏数据;
清除所述第一数据库的所述数据填补任务记录。
7.根据权利要求4所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列这一步骤,具体包括:
确定所述当前编号与所述上一次编号为连续的编号,通过调用封装好的公共代码调用发送服务和写监控日志;
所述发送服务写入第二数据库,所述第二数据库为用于记录发送状态和发送次数的关系型数据库;
所述发送服务调用消息队列发送所述消息;
确定所述消息队列发送所述消息成功,更新所述第二数据库中所述发送状态为发送成功;
确定所述消息队列发送所述消息失败,更新所述第二数据库中所述发送状态为发送失败,将所述消息加入所述第一数据库的发送失败队列中等待重新发送,并将失败原因写入所述监控日志得到失败原因日志。
8.根据权利要求7所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述将所述消息加入所述第一数据库的发送失败队列中等待重新发送这一步骤,具体包括:
从所述发送失败队列中定时获取数据给所述发送服务,以调用所述消息队列来重新发送定时获取的数据。
9.根据权利要求8所述的一种基于消息队列的分布式事务处理方法,其特征在于:所述将所述消息加入所述第一数据库的发送失败队列中等待重新发送这一步骤,还具体包括:
若重新发送的次数大于预设的最大发送次数,则将失败结果写入所述监控日志得到失败日志,并触发失败告警。
10.一种基于消息队列的分布式事务处理***,其特征在于:包括发送端和服务端,其中,所述发送端包括:
编号模块,用于对发送的消息进行顺序编号;
发送日志写入模块,用于将发送的消息及其顺序编号写入发送日志;
第一发送模块,用于发送消息给服务端,使所述服务端获取所述消息的顺序编号并与第一数据库中存储的顺序编号进行比较,当二者的顺序编号不连续则确定缺漏的起始顺序编号和结束顺序编号,当二者的顺序编号连续则将所述消息发送给消息队列;
缺漏数据获取与重发送模块,用于根据所述起始顺序编号和所述结束顺序编号从所述发送日志中获取缺漏数据,并将所述缺漏数据发送给所述服务端;
所述服务端包括:
接收模块,用于接收发送端发送的消息;
当前编号获取模块,用于获取所述消息的顺序编号作为当前编号;
上一次编号获取模块,用于从第一数据库中获取存储的所述发送端的顺序编号作为上一次编号;
缺漏数据修复模块,用于确定所述当前编号与所述上一次编号为不连续的编号,将缺漏的起始顺序编号和结束顺序编号返回给发送端,使发送端根据所述起始顺序编号和所述结束顺序编号从所述消息的发送日志中获取缺漏数据后重新发送给服务端;
第二发送模块,用于确定所述当前编号与所述上一次编号为连续的编号,将所述消息发送给消息队列;
其中,所述第一数据库为非关系型数据库。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911404579.7A CN111158933A (zh) | 2019-12-31 | 2019-12-31 | 一种基于消息队列的分布式事务处理方法及*** |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201911404579.7A CN111158933A (zh) | 2019-12-31 | 2019-12-31 | 一种基于消息队列的分布式事务处理方法及*** |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111158933A true CN111158933A (zh) | 2020-05-15 |
Family
ID=70559581
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201911404579.7A Pending CN111158933A (zh) | 2019-12-31 | 2019-12-31 | 一种基于消息队列的分布式事务处理方法及*** |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111158933A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112306989A (zh) * | 2020-10-26 | 2021-02-02 | 北京健康之家科技有限公司 | 数据库实例的处理方法及装置、存储介质、电子装置 |
CN112882655A (zh) * | 2021-02-03 | 2021-06-01 | 广发证券股份有限公司 | 数据缓存方法、装置、电子设备及存储介质 |
CN113127508A (zh) * | 2021-04-23 | 2021-07-16 | 中国工商银行股份有限公司 | 序号获取方法、装置及*** |
CN113296985A (zh) * | 2021-06-16 | 2021-08-24 | 北京有竹居网络技术有限公司 | 一种消息处理方法及装置 |
CN113316190A (zh) * | 2021-05-10 | 2021-08-27 | 上海仝心电子科技有限公司 | 一种智慧云盒及*** |
CN114020495A (zh) * | 2021-11-10 | 2022-02-08 | 中国建设银行股份有限公司 | 一种信息处理***、方法、装置、设备及介质 |
CN114500443A (zh) * | 2021-12-27 | 2022-05-13 | 北京百度网讯科技有限公司 | 消息推送方法、装置、***、电子设备和存储介质 |
CN115629891A (zh) * | 2022-11-04 | 2023-01-20 | 苏州阿基米德网络科技有限公司 | 一种顺序消息多队列传输方法、电子设备及存储介质 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102056231A (zh) * | 2009-11-04 | 2011-05-11 | 中兴通讯股份有限公司 | 一种保证lte定位协议数据可靠传输的方法及设备 |
CN102571635A (zh) * | 2012-01-18 | 2012-07-11 | 浪潮(北京)电子信息产业有限公司 | 一种消息传输方法及设备 |
CN104731888A (zh) * | 2015-03-12 | 2015-06-24 | 北京奇虎科技有限公司 | 一种数据迁移的方法、装置和*** |
CN110535793A (zh) * | 2018-05-25 | 2019-12-03 | 微软技术许可有限责任公司 | 分布式***的消息全序机制 |
-
2019
- 2019-12-31 CN CN201911404579.7A patent/CN111158933A/zh active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102056231A (zh) * | 2009-11-04 | 2011-05-11 | 中兴通讯股份有限公司 | 一种保证lte定位协议数据可靠传输的方法及设备 |
CN102571635A (zh) * | 2012-01-18 | 2012-07-11 | 浪潮(北京)电子信息产业有限公司 | 一种消息传输方法及设备 |
CN104731888A (zh) * | 2015-03-12 | 2015-06-24 | 北京奇虎科技有限公司 | 一种数据迁移的方法、装置和*** |
CN110535793A (zh) * | 2018-05-25 | 2019-12-03 | 微软技术许可有限责任公司 | 分布式***的消息全序机制 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112306989A (zh) * | 2020-10-26 | 2021-02-02 | 北京健康之家科技有限公司 | 数据库实例的处理方法及装置、存储介质、电子装置 |
CN112882655A (zh) * | 2021-02-03 | 2021-06-01 | 广发证券股份有限公司 | 数据缓存方法、装置、电子设备及存储介质 |
CN113127508A (zh) * | 2021-04-23 | 2021-07-16 | 中国工商银行股份有限公司 | 序号获取方法、装置及*** |
CN113316190A (zh) * | 2021-05-10 | 2021-08-27 | 上海仝心电子科技有限公司 | 一种智慧云盒及*** |
CN113296985A (zh) * | 2021-06-16 | 2021-08-24 | 北京有竹居网络技术有限公司 | 一种消息处理方法及装置 |
CN113296985B (zh) * | 2021-06-16 | 2024-03-01 | 北京有竹居网络技术有限公司 | 一种消息处理方法及装置 |
CN114020495A (zh) * | 2021-11-10 | 2022-02-08 | 中国建设银行股份有限公司 | 一种信息处理***、方法、装置、设备及介质 |
CN114500443A (zh) * | 2021-12-27 | 2022-05-13 | 北京百度网讯科技有限公司 | 消息推送方法、装置、***、电子设备和存储介质 |
CN114500443B (zh) * | 2021-12-27 | 2024-03-29 | 北京百度网讯科技有限公司 | 消息推送方法、装置、***、电子设备和存储介质 |
CN115629891A (zh) * | 2022-11-04 | 2023-01-20 | 苏州阿基米德网络科技有限公司 | 一种顺序消息多队列传输方法、电子设备及存储介质 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN111158933A (zh) | 一种基于消息队列的分布式事务处理方法及*** | |
CN107592351B (zh) | 一种基于Redis的多用户发布订阅方法及*** | |
EP3386150A1 (en) | Terminal failure processing method, device and system | |
CN111614712B (zh) | 数据校验***、方法、装置、服务器及存储介质 | |
CN111835467B (zh) | 消息发送方法、装置、计算机设备和存储介质 | |
CN111245934A (zh) | 文件传输的反馈方法、装置、设备和存储介质 | |
CN101720478A (zh) | 高有效性传输 | |
CN109039552B (zh) | 一种数据恢复方法及装置 | |
CN101022473B (zh) | 一种在交换机中自动识别板卡配置并且生成局数据的方法 | |
CN112887196A (zh) | 消息发送方法、***、装置、设备及可读存储介质 | |
CN111162880B (zh) | 数据发送方法、装置、设备及存储介质 | |
CN111988391A (zh) | 一种消息发送方法及装置 | |
CN111611094A (zh) | 对异常mq信息的监控及管理方法 | |
CN109743133B (zh) | 数据对账方法及装置 | |
CN112087475B (zh) | 一种云平台组件应用的消息推送方法、装置及消息服务器 | |
CN117762652A (zh) | 基于消息中间件的分布式事务的处理方法及装置 | |
JP4786392B2 (ja) | 事象情報管理システム | |
CN109361629B (zh) | 一种基于Kafka大消息可靠传输方法 | |
CN111652681A (zh) | 一种单据处理方法、服务器及计算机可读存储介质 | |
CN116643900A (zh) | 消息队列的重发方法及装置、电子设备及存储介质 | |
EP3668106A1 (en) | Method and system for service provisioning to an optical network terminal | |
CN113778759B (zh) | 一种数据分发过程中的失败检测及恢复方法 | |
CN110928955B (zh) | 一种数据交互方法、装置、计算机设备及存储介质 | |
CN108880994B (zh) | 一种重发邮件的方法和装置 | |
CN107563942B (zh) | 一种物流数据批量处理方法、物流处理***以及处理装置 |
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 | ||
RJ01 | Rejection of invention patent application after publication | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200515 |