CN112437001B - 保证消息可靠性投递与消费方法、装置 - Google Patents

Abstract

本发明涉及一种保证消息可靠性投递与消费方法、装置、计算机设备和存储介质，所述方法包括：如果在所述第一时间阈值内收到投递回馈且所述投递回馈是写入不成功，或在所述第一时间阈值内没有收到投递回馈，则重新向所述消息队列投递所述消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值；如果在所述第二时间阈值内收到消费回馈且所述消费回馈是消费不成功，或在所述第二时间阈值内没有收到消费回馈，则重新向所述消费端投递所述消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值。上述方法可以保证消息传递的可靠性。

Description

保证消息可靠性投递与消费方法、装置

技术领域

本发明涉及消息队列技术领域，特别是涉及保证消息可靠性投递与消费方法、装置、计算机设备和存储介质。

背景技术

当前主流的消息队列(MQ)提供了灵活、海量吞吐、高可用的解决方案，广受欢迎的KAFKA、Rocket MQ、Rabbit MQ等都有强劲的表现，能解决系统异步处理、流量控制、服务解耦场景需求。

在一些特定的场景(例如金融系统)中，对消息的投递和消费的可靠性要求比较高。虽然，现在主流的消息队列产品都提供了非常完善的消息可靠性保证机制，可以做到在消息传递过程中，即使发生网络中断或者硬件故障，也能确保消息的可靠传递，不丢消息。然而，消息队列自身以外的消息生产、消费则消息队列产品通常不会做消息队列以外的保障机制。因此，无法满足消息的投递和消费的可靠性的高要求。同时，如消息监控、报告比对等方案由于消息队列产品不同，每个团队各自研发，没有统一的标准，有时重复建设，浪费公司开发能力，增加成本。

发明内容

基于此，有必要提供一种保证消息可靠性投递与消费方法、装置、计算机设备和存储介质。

一种保证消息可靠性投递与消费方法，包括：

在生产端向消息队列投递消息后，确定所述生产端是否在第一时间阈值内收到所述消息队列输出的投递回馈，

如果在所述第一时间阈值内收到投递回馈且所述投递回馈是写入不成功，或在所述第一时间阈值内没有收到投递回馈，则重新向所述消息队列投递所述消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值；

在消费端手动签收了所述消息队列中的消息后，确定所述消息队列是否在第二时间阈值内收到所述消费端输出的消费回馈，

如果在所述第二时间阈值内收到消费回馈且所述消费回馈是消费不成功，或在所述第二时间阈值内没有收到消费回馈，则重新向所述消费端投递所述消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值。

在其中一个实施例中，所述方法还包括：

基于所述生产端收到的投递回馈，生成生产端表，所述生产端表中存储的是对应的投递回馈是写入成功的消息和没有投递回馈的消息；基于所述消费端对所述消息的消费结果，生成消费端表，所述消费端表中存储的是消费成功的消息；其中，每条消息具有唯一的业务流水号；

比对所述生产端表和所述消费端表中的消息是否一致，

如果不一致，则确定不一致的消息，重新向所述消费端投递所述消息。

在其中一个实施例中，所述比对所述生产端表和所述消费端表中的消息是否一致，包括：

如果所述生产端表和/或所述消费端表中多条消息的业务流水号相同，则保留一条消息，且将其他消息删除；

确定所述生产端表和所述消费端表中的消息的数量是否一致，

如果不一致，则将所述生产端表和所述消费端表中的多条消息按照业务流水号的升序或降序排列，将所述生产端表中的各消息的业务流水号与所述消费端表中的业务流水号依次进行匹配，确定不一致的消息。

在其中一个实施例中，所述重新向所述消费端投递所述消息，包括：

对消费端签收的消息进行消息的幂等，以确定消费端是否正在处理所述消息或已经完成所述消息的处理，如果消费端正在处理所述消息则将所述消息退回所述消息队列中；如果消费端已经完成所述消息的处理，则删除所述消息。

在其中一个实施例中，所述方法还包括：

基于所述生产端收到的投递回馈，消息写入所述消息队列不成功的第一比率，以及所述生产端收不到所述消息回馈的第二比率；基于所述消费端收到的消费回馈，确定所述消息消费不成功的第三比率；

基于预先设置的所述第一比率、所述第二比率、所述第三比率与报警类别信息之间的对应关系，确定所述第一比率和所述第二比率对应的报警类别信息；

基于所确定的报警类别信息，向预设终端发送报警信息。

在其中一个实施例中，所述重新向所述消费端投递所述消息，包括：

根据所述第一比率、所述第二比率和所述第三比率确定所述生产端通过消息队列向所述消费端重新投递所述消息，或所述生产端直接将所述消息投递给所述消费端。

在其中一个实施例中，所述方法还包括：

所述生产端以预定时间间隔向所述消息队列发送水印消息，其中所述水印消息没有业务内容；

所述消息队列收到水印消息后向所述生产端输出投递回馈，并在所述消费端签收所述水印消息后删除所述消息队列内的水印消息。

一种保证消息可靠性投递与消费装置，包括：

生产端监听模块，用于在生产端向消息队列投递消息后，确定所述生产端是否在第一时间阈值内收到所述消息队列输出的投递回馈，

第一重新投递模块，用于如果在所述第一时间阈值内收到投递回馈且所述投递回馈是写入不成功，或在所述第一时间阈值内没有收到投递回馈，重新向所述消息队列投递所述消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值；

消费端监听模块，用于在消费端手动签收了所述消息队列中的消息后，确定所述消息队列是否在第二时间阈值内收到所述消费端输出的消费回馈，

第二重新投递模块，用于如果在所述第二时间阈值内收到消费回馈且所述消费回馈是消费不成功，或在所述第二时间阈值内没有收到消费回馈，重新向所述消费端投递所述消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值。

一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行上述所述手势测试方法的步骤。

一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行上述所述手势测试方法的步骤。

上述保证消息可靠性投递与消费方法、系统、计算机设备和存储介质，在消息生产阶段：生产端采用异步模式，通过监听投递回馈确定生产端是否顺利的将消息写入消息队列MQ，如果生产端接收到的投递回馈是写入失败或一直没有接收到投递回馈，则记录生产端短时存储消息生产记录标记投递状态，根据投递状态确定异常问题，从而，保证了消息能够顺利的投递到消息队列中。消费端采用手动签收模式(推模式或者拉模式)签收消息，手动签收需要消费端在代码声明式告知消息队列消息处理结果，然后可以根据消费端对消息的消费情况，保证了消费失败的消息能够重新从消费端获得。从而，在消费端保证了消息能够写入消息队列，且对无法写入消息队列的消息也进行了记录。监听消费端对消息的消费情况能保证签收的消息被消费，且无法消费消息也进行了记录。

附图说明

图1为一个实施例中保证消息可靠性投递与消费方法的一个流程图；

图2为一个实施例中保证消息可靠性投递与消费方法的另一个流程图；

图3为一个实施例中保证消息可靠性投递与消费装置的结构框图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

本申请的说明书和权利要求书及所述附图中的术语“第一”、“第二”、“第三”和“第四”等是用于区别不同对象，而不是用于描述特定顺序。此外，术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结果或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

本申请中的生产端和消费端可以包括智能手机(如Android手机、iO S手机、Windows Phone手机等)、平板电脑、掌上电脑、笔记本电脑、移动互联网设备 MID(MobileInternet Devices，简称：MID)或穿戴式设备等，上述生产端和消费端仅是举例，而非穷举，包含但不限于上述生产端和消费端，为了描述的方便，下面实施例中将上述生产端和消费端称为用户设备UE(User equipment，简称： UE)。当然在实际应用中，上述用户设备也不限于上述变现形式，例如还可以包括：智能车载终端、计算机设备等等。需要说明的是，在本发明实施例中并不限定消息队列服务器的具体类型。

参阅图1至2为本申请实施例提供的一种保证消息可靠性投递与消费方法的流程示意图，该方法可以包括：

步骤101、在生产端向消息队列投递消息后，确定生产端是否在第一时间阈值内收到消息队列输出的投递回馈。

其中，第一时间阈值是从生产端向消息队列投递消息后的一段时间。

该步骤中，生产端以异步模式向消息队列投递消息，在该消息队列中加入confirm机制，即消息队列服务器每次成功接收生产端发布的数据后，调用消息队列的应用程序编程接口API(Application Programming Interface，简称：API)接口向生产端回复投递消息，例如一个确认字符ACK数据，该ACK数据用于指示消息写入消息队列成功或不成功。消息队列服务器将接收到的消息数据存储在消息队列中的磁盘中，并将数据的数据状态标记为待发送状态，在接收到数据接收方消费数据请求后，从消息队列中按照预设顺序从磁盘中依次读取该待发送状态的数据。

步骤102、如果在第一时间阈值内收到投递回馈且投递回馈是写入不成功，或在第一时间阈值内没有收到投递回馈，则重新向消息队列投递消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值。

可以理解的是，重新向消息队列投递消息直至监听到写入成功的投递回馈是指，在第N次重新向消息队列投递消息后收到了投递回馈，且投递回馈是写入成功，此时，不需要消息队列是在第一时间阈值内收到的。

该步骤中，在一直没有收到投递回馈和虽然收到了投递回馈但是投递回馈是写入不成功这两种情况下，消息都需要进行重新投递，重新投递的第一次数阈值是预先设定的。重新投递的具体情况包括：在某一次重新投递后，在预设时间阈值内收到了投递回馈且投递回馈是写入成功，则此时停止消息的重新投递；或者，在重新投递了第一次数阈值(如3次)后，每一次重新投递后，都收到了投递回馈且投递回馈是写入不成功或者是超时未收到投递回馈。此时，将消息的属性数据增加至生产端表中，此时表中要记录业务唯一编号(业务流水号)、消息编号、内容、状态、时间戳等。注意，重新投递的消息的业务唯一编号(业务流水号)不变，消息编号、状态、时间戳会变化。例如，如果一条消息重新投递了三次，此时生产端表中会有三条消息记录，但是这三条消息记录的业务唯一编号(业务流水号)和内容是相同的。

步骤103、在消费端手动签收了消息队列中的消息后，确定消息队列是否在第二时间阈值内收到消费端输出的消费回馈。

在消费端中加入confirm机制，当消费端成功消费数据时，向该消息队列服务器反馈一个ACK数据，该ACK数据用于指示消费端消费消息成功或不成功。

步骤104、如果在第二时间阈值内收到消费回馈且消费回馈是消费不成功，或在第二时间阈值内没有收到消费回馈，则重新向消费端投递消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值。

其中，第二时间阈值是从消费端签收消息队列输出的消息后的一段时间。第一时间阈值和第二时间阈值可以相同也可以不相同。

本申请，在消息生产阶段：生产端采用异步模式，通过监听投递回馈确定生产端是否顺利的将消息写入消息队列MQ，例如，生产端接收到回调结果是写入失败，则重新写入。一直没有接收到回调结果，则记录生产端短时存储消息生产记录标记投递状态，根据投递状态确定异常问题，从而，保证了消息能够顺利的投递到消息队列中。在消息消费阶段：消费端采用手动签收模式(推模式或者拉模式)签收消息，手动签收需要消费端在代码声明式告知消息队列消息处理结果，然后可以根据消费端对消息的消费情况，保证了消费失败的消息能够重新从消费端获得。从而，在消费端保证了消息能够写入消息队列，且对无法写入消息队列的消息也进行了记录。监听消费端对消息的消费情况能保证签收的消息被消费，且无法消费消息也进行了记录。

当然，将写入消息队列的消息进行持久化处理和/或多机备份，持久化处理包括：写入磁盘文件、写入第三方存储设备中；多机备份包括：集群、多集群同步、做镜像队列。

可以理解的是，通过持久化、多机备份的方式对消息进行冗余存储，保证了消息可靠，在IDC故障或者业务代码故障时保证消息不丢失、可恢复、恢复后消息可靠。提供消息生产的服务接口，满足常见http、tcp通讯协议，实时返回生产端生产请求，通过持久化的缓存组件或者是NoSQL数据库，写入便捷短时小容量高速存储设备，设备硬盘采用SSD，消息成功写入MQ后删除消息体，仅留下消息ID，当到达过期时间立即删除该消息，以解决防止遇到IDC等故障时，消息丢失的问题。

进一步地，在上述步骤104中，重新向消费端投递消息，包括：

对消费端签收的消息进行消息的幂等，以确定消费端是否正在处理消息或已经完成消息的处理，如果消费端正在处理消息则将消息退回消息队列中；如果消费端已经完成消息的处理，则删除消息。

可以理解的是，在第二时间阈值内没有收到消费端输出的消费回馈的一种情况是消费端正在消费消息，而不是消费端对消息失败，因此，通过消息的幂等，避免了消息的重复消费，同时减轻了消费端的数据处理压力。

在本申请实施例的一些变更实施方式中，方法还包括：

步骤105、基于生产端收到的投递回馈，生成生产端表，生产端表中存储的是对应的投递回馈是写入成功的消息和没有投递回馈的消息；基于消费端对消息的消费结果，生成消费端表，消费端表中存储的是消费成功的消息；其中，每条消息具有唯一的业务流水号。

该步骤中，基于生产端收到的投递回馈，生成生产端表，是记录生产端收到的投递回馈，具体包括：如果在第一时间阈值内收到了投递回馈且投递回馈包含写入成功，则将消息增加至生产端表中；如果重新向消息队列投递消息后，收到了投递回馈且投递回馈包含写入成功，那么该消息也消息增加至生产端表中；如果重新向消息队列投递消息后，一直没有收到投递回馈，那么该消息也消息增加至生产端表中，其中，一直没有收到投递回馈，不代表消息没有被写入消息队列，例如，生产端和消息队列的网络链路不稳造成生产端无法收到消息队列。也就是说，生产端表中存储的是有可能写入消息队列的消息。

步骤106、比对生产端表和消费端表中的消息是否一致。

该步骤中，消息的消费在时间上滞后于消息的生产，故生产端表中的消息生产的时间是第一时间段生产的消息，而消费端表中的消息是第二时间段消费端的消息，第二时间段是预估的第一时间段生产的消息完成消息消费的时间。

生产端消息表和消费端消息表中存储有消息的业务流水号(具有唯一性)，消息编号，内容，状态，时间戳等，其中业务流水号具有唯一性，即上述步骤 102中重新投递的消息的业务流水号不变。比对生产端表和消费端表中的消息是否一致，可以通过比对两个表中的业务流水号是否一致是否一致实现。

本实施例，比对生产端表和消费端表中的消息是否一致，基于两个表中的消息是否一致判断消息传输过程是否丢失，不用关心消息是在传输过程中的那个环节丢失的，提高了消息传输的完整性，提高用户体验。

在一实施例中，上述步骤106具体包括：

步骤106a、如果生产端表和/或消费端表中多条消息的业务流水号相同，则保留一条消息，且将其他消息删除。

由于消息会被重新投递至消息队列，故生产端表和/或消费端表中可能会有至少两条业务流水号相同且消息内容相同的消息，只是消息的消息编号、状态、时间戳不同，这些消息实质上是相同的消息。

步骤106b、确定生产端表和消费端表中的消息的数量是否一致。

步骤106c、如果不一致，将生产端表和消费端表中的多条消息按照业务流水号的升序或降序排列，将生产端表中的消息的业务流水号与消费端表中的业务流水号依次进行匹配，确定不一致的消息。

该步骤中，由于生产端表和消费端表中的多条消息按照业务流水号的升序或降序排列的，故取消费端表中的任一消息，与生产端表从最小的业务流水号开始匹配，直至在生产端表找到一致的业务流水号，那么说明生产端的该条消息消费成功。或者，匹配到生产端表中的业务流水号比消费端表待匹配的业务流水号大，则那么说明生产端的该条消息消费失败。

步骤107、如果不一致，则确定不一致的消息，重新向消费端投递消息。

在本申请实施例的一些变更实施方式中，方法还包括：

步骤108、基于生产端收到的投递回馈，消息写入消息队列不成功的第一比率，以及生产端收不到消息回馈的第二比率；基于消费端收到的消费回馈，确定消息消费不成功的第三比率。

可以理解的是，生产端每次投递的消息都有记录，即消息投递日志，该消息投递日志记录了生产端的消息投递记录以及消息端收到的投递回馈，根据消息投递日志即可确定第一比率、第二比率和第三比率，第一比率是生产端向消息队列投递消息后，生产端收到投递回馈且投递回馈是写入不成功的消息的数量与生产端向消息队列投递的消息总数量的比值。第二比率是生产端向消息队列投递消息后，生产端没有收到投递回馈的消息的数量与生产端向消息队列投递的消息总数量的比值。第三比率是消费端消费不成功的消息数量与消费端签收的消费的数量的比值。

步骤109、基于预先设置的第一比率、第二比率、第三比率与报警类别信息之间的对应关系，确定第一比率和第二比率对应的报警类别信息，基于所确定的报警类别信息，向预设终端发送报警信息。

可以理解的是，当第一比率大于预设第一报警阈值时，发出报警信息；当第二比率大于预设的第二报警阈值时，发出报警信息。第一比率大于预设第一报警阈值和第二比率大于预设的第二报警阈值分别对应有不同的报警级别以及报警方式，例如，第一比率大于预设第一报警阈值对应的报警级别为高级，报警消息发送给维护人员A。第二比率大于预设的第二报警阈值对应的报警级别为中级，报警消息发送给维护人员B。

进一步地，上述步骤中重新向消费端投递消息，包括：

根据第一比率、第二比率和第三比率确定生产端通过消息队列向消费端重新投递消息，或生产端直接将消息投递给消费端。

可以理解的是，第一比率或第二比率过高，则说明生产端、消息队列和消费端之间的链路出现了问题，此时应采取消费端直接将消息重新发送给消费端。

在本申请实施例的一些变更实施方式中，方法还包括：

生产端以预定时间间隔向消息队列发送水印消息，其中水印消息没有业务内容；

消息队列收到水印消息后向生产端输出投递回馈，并在消费端签收水印消息后删除消息队列内的水印消息。

本实施例中，采用潜入式监控方式，生产端以预定时间间隔产生水印消息，该水印消息没有业务内容的消息，有字段标记为心跳检测消息，消费端收到后不需要做业务处理，给消息队列MQ做响应标记消息消费成功即可。例如，生产端向消息队列发送了水印消息，并且收到了消息队列返回的写入成功的反馈，然后，消息队列将该水印消息发送给消费端，消息队列一直没有收到消费端反馈的消息签收成功的反馈，则说明在消息队列和消费端之间的链接出现了问题，如此业务人员可以根据实际的业务场景进行相应的处理。

进一步参考图3，作为对上述方法的实现，本申请实施例提供了一种保证消息可靠性投递与消费的装置的一个实施例，该保证消息可靠性投递与消费的装置的实施例与图1所示的保证消息可靠性投递与消费方法的实施例相对应，由此，上文针对图1和图2中保证消息可靠性投递与消费方法描述的操作和特征同样适用于业务数据处理装置及其中包含的模块，在此不再赘述。

如图3所示，该保证消息可靠性投递与消费装置可以包括：

生产端监听模块301，用于在生产端向消息队列投递消息后，确定生产端是否在第一时间阈值内收到消息队列输出的投递回馈，

第一重新投递模块302，用于如果在第一时间阈值内收到投递回馈且投递回馈是写入不成功，或在第一时间阈值内没有收到投递回馈，重新向消息队列投递消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值；

消费端监听模块303，用于在消费端手动签收了消息队列中的消息后，确定消息队列是否在第二时间阈值内收到消费端输出的消费回馈，

第二重新投递模块304，用于如果在第二时间阈值内收到消费回馈且消费回馈是消费不成功，或在第二时间阈值内没有收到消费回馈，重新向消费端投递消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值。

本申请实施例还提供一种计算机存储介质，其中，该计算机存储介质存储用于电子数据交换的计算机程序，该计算机程序使得计算机执行如上述方法实施例中记载的任何一种监测消息队列中数据丢失方法的部分或全部步骤。

本申请实施例还提供一种计算机程序产品，所述计算机程序产品包括存储了计算机程序的非瞬时性计算机可读存储介质，所述计算机程序可操作来使计算机执行如上述方法实施例中记载的任何一种监测消息队列中数据丢失方法的部分或全部步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，该计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，前述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory， ROM)等非易失性存储介质，或随机存储记忆体(Random Access Memory，RAM) 等。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本发明的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干变形和改进，这些都属于本发明的保护范围。因此，本发明专利的保护范围应以所附权利要求为准。

Claims (9)

1.一种保证消息可靠性投递与消费方法，其特征在于，包括：

在生产端向消息队列投递消息后，确定所述生产端是否在第一时间阈值内收到所述消息队列输出的投递回馈，

如果在所述第一时间阈值内收到投递回馈且所述投递回馈是写入不成功，或在所述第一时间阈值内没有收到投递回馈，则重新向所述消息队列投递所述消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值；

在消费端手动签收了所述消息队列中的消息后，确定所述消息队列是否在第二时间阈值内收到所述消费端输出的消费回馈，

如果在所述第二时间阈值内收到消费回馈且所述消费回馈是消费不成功，或在所述第二时间阈值内没有收到消费回馈，则重新向所述消费端投递所述消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值；

所述方法还包括：

基于所述生产端收到的投递回馈，生成生产端表，所述生产端表中存储的是对应的投递回馈是写入成功的消息和没有投递回馈的消息；基于所述消费端对所述消息的消费结果，生成消费端表，所述消费端表中存储的是消费成功的消息；其中，每条消息具有唯一的业务流水号；

比对所述生产端表和所述消费端表中的消息是否一致，

如果不一致，则确定不一致的消息，重新向所述消费端投递所述消息。

2.根据权利要求1所述的保证消息可靠性投递与消费方法，其特征在于，所述比对所述生产端表和所述消费端表中的消息是否一致，包括：

如果所述生产端表和/或所述消费端表中多条消息的业务流水号相同，则保留一条消息，且将其他消息删除；

确定所述生产端表和所述消费端表中的消息的数量是否一致，

如果不一致，则将所述生产端表和所述消费端表中的多条消息按照业务流水号的升序或降序排列，将所述生产端表中的各消息的业务流水号与所述消费端表中的业务流水号依次进行匹配，确定不一致的消息。

3.根据权利要求1所述的保证消息可靠性投递与消费方法，其特征在于，所述重新向所述消费端投递所述消息，包括：

对消费端签收的消息进行消息的幂等，以确定消费端是否正在处理所述消息或已经完成所述消息的处理，如果消费端正在处理所述消息则将所述消息退回所述消息队列中；如果消费端已经完成所述消息的处理，则删除所述消息。

4.根据权利要求1所述的保证消息可靠性投递与消费方法，其特征在于，所述方法还包括：

基于所述生产端收到的投递回馈，消息写入所述消息队列不成功的第一比率，以及所述生产端收不到所述消息回馈的第二比率；基于所述消费端收到的消费回馈，确定所述消息消费不成功的第三比率；

基于预先设置的所述第一比率、所述第二比率、所述第三比率与报警类别信息之间的对应关系，确定所述第一比率和所述第二比率对应的报警类别信息；

基于所确定的报警类别信息，向预设终端发送报警信息。

5.根据权利要求4所述的保证消息可靠性投递与消费方法，其特征在于，所述重新向所述消费端投递所述消息，包括：

根据所述第一比率、所述第二比率和所述第三比率确定所述生产端通过消息队列向所述消费端重新投递所述消息，或所述生产端直接将所述消息投递给所述消费端。

6.根据权利要求1所述的保证消息可靠性投递与消费方法，其特征在于，所述方法还包括：

所述生产端以预定时间间隔向所述消息队列发送水印消息，其中所述水印消息没有业务内容；

所述消息队列收到水印消息后向所述生产端输出投递回馈，并在所述消费端签收所述水印消息后删除所述消息队列内的水印消息。

7.一种保证消息可靠性投递与消费装置，其特征在于，包括：

生产端监听模块，用于在生产端向消息队列投递消息后，确定所述生产端是否在第一时间阈值内收到所述消息队列输出的投递回馈，

第一重新投递模块，用于如果在所述第一时间阈值内收到投递回馈且所述投递回馈是写入不成功，或在所述第一时间阈值内没有收到投递回馈，重新向所述消息队列投递所述消息直至监听到写入成功的投递回馈或重新投递的次数达到第一次数阈值；

消费端监听模块，用于在消费端手动签收了所述消息队列中的消息后，确定所述消息队列是否在第二时间阈值内收到所述消费端输出的消费回馈，

第二重新投递模块，用于如果在所述第二时间阈值内收到消费回馈且所述消费回馈是消费不成功，或在所述第二时间阈值内没有收到消费回馈，重新向所述消费端投递所述消息直至监听到消费成功的消费回馈或重新投递的次数达到第二次数阈值；

第三重新投递模块，用于基于所述生产端收到的投递回馈，生成生产端表，所述生产端表中存储的是对应的投递回馈是写入成功的消息和没有投递回馈的消息；基于所述消费端对所述消息的消费结果，生成消费端表，所述消费端表中存储的是消费成功的消息；其中，每条消息具有唯一的业务流水号；比对所述生产端表和所述消费端表中的消息是否一致，如果不一致，则确定不一致的消息，重新向所述消费端投递所述消息。

8.一种计算机设备，包括存储器和处理器，所述存储器中存储有计算机可读指令，所述计算机可读指令被所述处理器执行时，使得所述处理器执行如权利要求1至6中任一项权利要求所述保证消息可靠性投递与消费方法的步骤。

9.一种存储有计算机可读指令的存储介质，所述计算机可读指令被一个或多个处理器执行时，使得一个或多个处理器执行如权利要求1至6中任一项权利要求所述保证消息可靠性投递与消费方法的步骤。

Images