CN113742107A - 一种避免消息队列中消息丢失的处理方法及相关设备 - Google Patents

Abstract

本申请公开了一种避免消息队列中消息丢失的处理方法及相关设备，应用系统通过定时扫描存储于redis缓存中的业务消息，由于业务消息进入消息队列中通常会在短时间内即可被消费，因此将第一消息生成时间大于预设时间的业务消息判定为消息发送失败，触发消息重发补偿机制使得该业务消息能够重新进入消息队列，在保证消息队列的消息发送以及消费效率前提下，解决了由于网络抖动、消息队列宕机等情况造成的发送消息丢失、处理消息丢失等状况，导致的业务数据不一致的情况，应用系统功能紊乱的技术问题。

Description

一种避免消息队列中消息丢失的处理方法及相关设备

技术领域

本申请涉及互联网技术领域，尤其涉及一种避免消息队列中消息丢失的处理方法及相关设备。

背景技术

消息队列作为削峰和异步处理的组件，已经被大量广泛使用于各应用系统中。但是消息队列作为除应用系统、数据库等之外的独立组件，会存在由于网络抖动、消息队列宕机等情况造成的发送消息丢失、处理消息丢失等状况，导致了业务数据不一致的情况，应用系统功能紊乱的技术问题。

现有技术通常使用消息队列事务来保证消息发送且消费成功，但该方式会严重降低消息队列的消息发送以及消费的效率。

发明内容

本申请提供了一种避免消息队列中消息丢失的处理方法及相关设备，在保证消息队列的消息发送以及消费效率前提下，解决了由于网络抖动、消息队列宕机等情况造成的发送消息丢失、处理消息丢失等状况，导致的业务数据不一致的情况，应用系统功能紊乱的技术问题。

有鉴于此，本申请第一方面提供了一种避免消息队列中消息丢失的处理方法，所述方法包括：

S101、应用系统将业务数据构成的业务消息存入redis缓存中；

S102、所述应用系统向消息队列发送所述业务消息；

S103、所述应用系统按照预设时间间隔扫描所述redis缓存中的所有业务消息；

S104、若所述redis缓存的所有业务消息中存在第一消息生成时间大于预设时间的业务消息，则触发消息重发补偿机制，且更新所述第一消息生成时间。

可选地，还包括：

S105、所述应用系统监听所述业务消息在所述消息队列中的消费状态，所述消费状态包括消费成功以及消费失败；

S106、若所述业务消息的消费状态更新为消费失败，则删除所述消息队列以及所述redis缓存中的所述业务消息，并将所述业务消息存入数据库中，使得所述数据库按照以预设时间间隔为定时任务，触发消费失败补偿机制；

S107、若所述业务消息的消费状态更新为消费成功，则删除所述消息队列以及所述redis缓存中的所述业务消息。

可选地，所述步骤S101具体包括：

应用系统向redis缓存中发送业务数据构成的业务消息以及第一消息生成时间；

所述应用系统接收到所述redis缓存返回的备份成功回执后，执行向数据库发送所述业务消息以及第二消息生成时间的数据库事务；

所述应用系统接收Spring返回的所述数据库事务的执行成功回执。

可选地，所述消息重发补偿机制具体包括：

所述应用系统将所述redis缓存中的所述业务消息重新发送至所述消息队列中。

可选地，所述步骤S106具体包括：

若所述业务消息的消费状态更新为消费失败，则判断所述业务消息是否包含预设标记；

若所述业务消息不包含所述预设标记，则删除所述消息队列以及所述redis缓存中所述业务消息，并将所述业务消息存入数据库中，在所述数据库中将所述业务消息添加所述预设标记，记录所述业务消息的重试次数为0；

若所述业务消息包含所述预设标记，则以预设时间间隔为定时任务，将所述数据库中的所述业务消息发送至所述消息队列中，并将所述业务消息的重试次数加一。

可选地，所述步骤S106中若所述业务消息包含所述预设标记，则将所述数据库中的所述业务消息发送至所述消息队列中，并将所述业务消息的重试次数加一具体包括：

若所述业务消息包含所述预设标记，且所述业务消息的重试次数达到预设阈值，则触发邮件预警机制；

若所述业务消息包含所述预设标记，但所述业务消息的重试次数未达到所述预设阈值，则将所述数据库中的所述业务消息发送至所述消息队列中，并将所述业务消息的重试次数加一。

可选地，所述步骤S102具体包括：

若所述业务消息的消费状态更新为消费成功，则分别删除所述消息队列以及所述redis缓存中的所述业务消息。

本申请第二方面提供一种避免消息队列中消息丢失的处理系统，所述系统包括应用系统、消息队列以及redis缓存，其中：

所述应用系统将业务数据构成的业务消息存入所述redis缓存中；

所述应用系统向消息队列发送所述业务消息；

所述应用系统按照预设时间间隔扫描所述redis缓存中的所有业务消息；

若所述redis缓存的所有业务消息中存在第一消息生成时间大于预设时间的业务消息，则触发消息重发补偿机制，且更新所述第一消息生成时间。

可选地，还包括数据库，其中：

所述应用系统监听所述业务消息在所述消息队列中的消费状态，所述消费状态包括消费成功以及消费失败；

若所述业务消息的消费状态更新为消费失败，则删除所述消息队列以及所述redis缓存中的所述业务消息，并将所述业务消息存入数据库中，使得所述数据库按照以预设时间间隔为定时任务，触发消费失败补偿机制；

若所述业务消息的消费状态更新为消费成功，则删除所述消息队列以及所述redis缓存中的所述业务消息。

本申请第三方面提供了一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行本申请第一方面任一项所述的避免消息队列中消息丢失的处理方法。

从以上技术方案可以看出，本申请实施例具有以下优点：

本申请中，提供了一种避免消息队列中消息丢失的处理方法，应用系统通过定时扫描存储于redis缓存中的业务消息，由于业务消息进入消息队列中通常会在短时间内即可被消费，因此将第一消息生成时间大于预设时间的业务消息判定为消息发送失败，触发消息重发补偿机制使得该业务消息能够重新进入消息队列，在保证消息队列的消息发送以及消费效率前提下，解决了由于网络抖动、消息队列宕机等情况造成的发送消息丢失、处理消息丢失等状况，导致的业务数据不一致的情况，应用系统功能紊乱的技术问题。

附图说明

图1为本申请实施例中一种避免消息队列中消息丢失的处理方法的方法流程图；

图2为基于本申请第一个实施例提供的避免消息队列中消息丢失的处理方法的延伸实施例的方法流程图；

图3为本申请实施例中一种避免消息队列中消息丢失的处理系统的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请设计了一种避免消息队列中消息丢失的处理方法及相关设备，在保证消息队列的消息发送以及消费效率前提下，解决了由于网络抖动、消息队列宕机等情况造成的发送消息丢失、处理消息丢失等状况，导致的业务数据不一致的情况，应用系统功能紊乱的技术问题。

为了便于理解，请参阅图1，图1为本申请实施例中一种避免消息队列中消息丢失的处理方法的方法流程图，如图1所示，具体为：

S101、应用系统将业务数据构成的业务消息存入redis缓存中；

需要说明的是，在应用系统处理完业务后，生成的业务数据将构成业务消息。业务消息预先备份至redis缓存中，防止发送到消息队列的业务消息丢失。相对于将业务消息直接备份至数据库中，redis缓存的读写效率更高，能够降低数据库事务的等待时间，从而提升应用系统整体性能。

S102、应用系统向消息队列发送业务消息；

需要说明的是，在对业务消息进行了双重备份后，将业务消息发送至RabbitMQ消息队列中异步处理后续流程，业务消息需要在数据库中备份成功才可被发送到消息队列中，这是为了防止数据库处理失败而业务消息却发送成功导致的数据不完整的问题。

S103、应用系统按照预设时间间隔扫描redis缓存中的所有业务消息；

需要说明的是，应用系统中可以通过配置一个定时任务，来按照预设时间间隔扫描redis缓存中的所有业务消息，例如每分钟或每半分钟，在redis缓存中将缓存有已经发送至消息队列，但未被消费的业务消息，通过扫描业务消息可以获取到业务消息的第一消息生成时间，第一消息生成时间为应用系统将业务消息备份至redis缓存中的时间。

S104、若redis缓存的所有业务消息中存在第一消息生成时间大于预设时间的业务消息，则触发消息重发补偿机制，且更新第一消息生成时间。

需要说明的是，当redis缓存中，存在业务消息的第一消息生成时间大于预设时间的业务消息，则说明长时间该业务消息未被消费，可以认为消息发送失败，则触发消息重发补偿机制，将该业务消息进行发送补偿，从而确保业务消息的发送成功。同时，更新该业务消息在redis缓存中的第一消息生成时间，避免被重复扫描和补偿。

进一步地，请参阅图2，图2为基于本申请第一个实施例提供的避免消息队列中消息丢失的处理方法的延伸实施例的方法流程图，具体还包括：

S105、应用系统监听业务消息在消息队列中的消费状态，消费状态包括消费成功以及消费失败；

需要说明的是，应用系统将业务消息成功发送到消息队列后，还需要实时监听业务消息在消息队列中的消费状态，消费状态分为消费成功以及消费失败两种状态。

S106、若业务消息的消费状态更新为消费失败，则删除消息队列以及redis缓存中的业务消息，并将业务消息存入数据库中，使得数据库按照以预设时间间隔为定时任务，触发消费失败补偿机制；

需要说明的是，当监听到消息队列中的业务消息的消费状态更新为消费失败后，需要立刻删除消息队列以及redis缓存中的业务消息，删除消息队列中的业务消息是为了防止重复消费或者不断的消费导致的消息队列堵塞问题，删除redis缓存中的业务消息是为了防止消息重发补偿机制被触发，将业务消息重新备份至数据库中，以预设时间间隔为定时任务触发消费失败补偿机制。

S107、若业务消息的消费状态更新为消费成功，则删除消息队列以及redis缓存中的业务消息。

需要说明的是，若是消费成功，则同样立刻删除消息队列以及redis缓存中的业务消息。

进一步地，步骤S101具体包括：

应用系统向redis缓存中发送业务数据构成的业务消息以及第一消息生成时间；

需要说明的是，应用系统向redis缓存发送业务消息以及第一消息生成时间，第一消息生成时间为应用系统将业务消息备份至redis缓存中的时间。

应用系统接收到redis缓存返回的备份成功回执后，执行向数据库发送业务消息以及第二消息生成时间的数据库事务；

需要说明的是，在应用系统接收到redis缓存返回的备份成功回执后，才执行向数据库发送业务消息以及第二消息生成时间的数据库事务，数据库事务是由Spring控制。

应用系统接收Spring返回的数据库事务的执行成功回执。

需要说明的是，Spring向应用系统返回数据库事务的执行状态回执，若执行状态回执为执行成功回执，则无需重复备份，若执行状态回执为执行失败回执，则需要应用系统再次进行数据库事务的发送，重新发送的数据库事务中的第二消息生成时间将更新为实时。

进一步地，消息重发补偿机制具体包括：

应用系统将redis缓存中的业务消息重新发送至消息队列中。

需要说明的是，由于业务消息发送失败的概率十分低，可以利用redis缓存进行自动的消息重发补偿即可，同时保证了业务消息的处理效率。

进一步地，步骤S106具体包括：

若业务消息的消费状态更新为消费失败，则判断业务消息是否包含预设标记；

需要说明的是，业务消息的消费失败是属于常见的场景，可能需要人工介入进行处理，因此将业务消息同时备份至数据库中，方便后续运维的查询、更新、重试等操作。消费失败时，需要判断业务消息是否包含预设标记，存在预设标记代表该业务消息不是第一次消费失败。

若业务消息不包含预设标记，则删除消息队列以及redis缓存中业务消息，并将业务消息存入数据库中，在数据库中将业务消息添加预设标记，记录业务消息的重试次数为0；

需要说明的是，若是业务消息不包含预设标记，代表该业务消息是第一次被消费失败，在删除消息队列以及redis缓存中的业务消息的同时，需要赋予新加入数据库中该业务消息一个预设标记，同时记录该业务消息的重试次数为0。

若业务消息包含预设标记，则以预设时间间隔为定时任务，将数据库中的业务消息发送至消息队列中，并将业务消息的重试次数加一。

若是业务消息包含预设标记，代表该业务消息不是第一次被消费失败，则以预设时间间隔为定时任务，将仅保存在数据库中的该业务消息发送至消息队列中，同时将该业务消息的重试次数加一。

进一步地，步骤S106中若业务消息包含预设标记，则将数据库中的业务消息发送至消息队列中，并将业务消息的重试次数加一具体包括：

若业务消息包含预设标记，且业务消息的重试次数达到预设阈值，则触发邮件预警机制；

需要说明的是，当该业务消息被消费失败的次数达到预设阈值，说明由系统自动进行消费失败补偿机制是没有效果的，需要出发邮件预警机制，提示运维人员该业务消息的异常，从而保证该业务消息能够最终被处理成功，保证应用系统数据的一致性，避免遗漏。

若业务消息包含预设标记，但业务消息的重试次数未达到预设阈值，则将数据库中的业务消息发送至消息队列中，并将业务消息的重试次数加一。

进一步地，步骤S102具体包括：

若业务消息的消费状态更新为消费成功，则分别删除消息队列以及redis缓存中的业务消息。

需要说明的是，redis缓存作为业务消息的临时备份处，在业务消息被消费成功后，同样需要和消息队列中的业务消息一起被删除，避免触发消息重发补偿机制。

请参阅图3，图3为本申请实施例中一种避免消息队列中消息丢失的处理系统的结构示意图，如图3所示，包括应用系统201、消息队列202以及redis缓存203，其中：

应用系统201将业务数据构成的业务消息存入redis缓存203中。

应用系统201向消息队列202发送业务消息；

应用系统201按照预设时间间隔扫描redis缓存203中的所有业务消息；

若redis缓存203的所有业务消息中存在第一消息生成时间大于预设时间的业务消息，则触发消息重发补偿机制，且更新第一消息生成时间。

可选地，还包括数据库204，其中：

应用系统201监听业务消息在消息队列202中的消费状态，消费状态包括消费成功以及消费失败；

若业务消息的消费状态更新为消费失败，则删除消息队列202以及redis缓存203中的业务消息，并将业务消息存入数据库204中，使得数据库按照以预设时间间隔为定时任务，触发消费失败补偿机制；

若业务消息的消费状态更新为消费成功，则删除消息队列202以及redis缓存203中的业务消息。

本申请实施例还提供一种计算机可读存储介质，用于存储程序代码，该程序代码用于执行前述各个实施例所述的一种避免消息队列中消息丢失的处理方法中的任意一种实施方式。

本申请实施例中提供了一种避免消息队列中消息丢失的处理方法及相关设备，应用系统通过定时扫描存储于redis缓存中的业务消息，由于业务消息进入消息队列中通常会在短时间内即可被消费，因此将第一消息生成时间大于预设时间的业务消息判定为消息发送失败，触发消息重发补偿机制使得该业务消息能够重新进入消息队列，在保证消息队列的消息发送以及消费效率前提下，解决了由于网络抖动、消息队列宕机等情况造成的发送消息丢失、处理消息丢失等状况，导致的业务数据不一致的情况，应用系统功能紊乱的技术问题。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请的说明书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“A和/或B”可以表示：只存在A，只存在B以及同时存在A和B三种情况，其中A，B可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(英文全称：Read-OnlyMemory，英文缩写：ROM)、随机存取存储器(英文全称：Random Access Memory，英文缩写：RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims (10)

1.一种避免消息队列中消息丢失的处理方法，其特征在于，包括：

S101、应用系统将业务数据构成的业务消息存入redis缓存中；

S102、所述应用系统向消息队列发送所述业务消息；

S103、所述应用系统按照预设时间间隔扫描所述redis缓存中的所有业务消息；

S104、若所述redis缓存的所有业务消息中存在第一消息生成时间大于预设时间的业务消息，则触发消息重发补偿机制，且更新所述第一消息生成时间。

2.根据权利要求1所述的避免消息队列中消息丢失的处理方法，其特征在于，还包括：

S105、所述应用系统监听所述业务消息在所述消息队列中的消费状态，所述消费状态包括消费成功以及消费失败；

S106、若所述业务消息的消费状态更新为消费失败，则删除所述消息队列以及所述redis缓存中的所述业务消息，并将所述业务消息存入数据库中，使得所述数据库按照以预设时间间隔为定时任务，触发消费失败补偿机制；

S107、若所述业务消息的消费状态更新为消费成功，则删除所述消息队列以及所述redis缓存中的所述业务消息。

3.根据权利要求2所述的避免消息队列中消息丢失的处理方法，其特征在于，所述步骤S101具体包括：

应用系统向redis缓存中发送业务数据构成的业务消息以及第一消息生成时间；

所述应用系统接收到所述redis缓存返回的备份成功回执后，执行向数据库发送所述业务消息以及第二消息生成时间的数据库事务；

所述应用系统接收Spring返回的所述数据库事务的执行成功回执。

4.根据权利要求3所述的避免消息队列中消息丢失的处理方法，其特征在于，所述消息重发补偿机制具体包括：

所述应用系统将所述redis缓存中的所述业务消息重新发送至所述消息队列中。

5.根据权利要求4所述的避免消息队列中消息丢失的处理方法，其特征在于，所述步骤S106具体包括：

若所述业务消息的消费状态更新为消费失败，则判断所述业务消息是否包含预设标记；

若所述业务消息不包含所述预设标记，则删除所述消息队列以及所述redis缓存中所述业务消息，并将所述业务消息存入数据库中，在所述数据库中将所述业务消息添加所述预设标记，记录所述业务消息的重试次数为0；

若所述业务消息包含所述预设标记，则以预设时间间隔为定时任务，将所述数据库中的所述业务消息发送至所述消息队列中，并将所述业务消息的重试次数加一。

6.根据权利要求5所述的避免消息队列中消息丢失的处理方法，其特征在于，所述步骤S106中若所述业务消息包含所述预设标记，则将所述数据库中的所述业务消息发送至所述消息队列中，并将所述业务消息的重试次数加一具体包括：

若所述业务消息包含所述预设标记，且所述业务消息的重试次数达到预设阈值，则触发邮件预警机制；

若所述业务消息包含所述预设标记，但所述业务消息的重试次数未达到所述预设阈值，则将所述数据库中的所述业务消息发送至所述消息队列中，并将所述业务消息的重试次数加一。

7.根据权利要求2所述的避免消息队列中消息丢失的处理方法，其特征在于，所述步骤S102具体包括：

若所述业务消息的消费状态更新为消费成功，则分别删除所述消息队列以及所述redis缓存中的所述业务消息。

8.一种避免消息队列中消息丢失的处理系统，其特征在于，包括应用系统、消息队列以及redis缓存，其中：

所述应用系统将业务数据构成的业务消息存入所述redis缓存中；

所述应用系统向消息队列发送所述业务消息；

所述应用系统按照预设时间间隔扫描所述redis缓存中的所有业务消息；

若所述redis缓存的所有业务消息中存在第一消息生成时间大于预设时间的业务消息，则触发消息重发补偿机制，且更新所述第一消息生成时间。

9.根据权利要求8所述的避免消息队列中消息丢失的处理系统，其特征在于，还包括数据库，其中：

所述应用系统监听所述业务消息在所述消息队列中的消费状态，所述消费状态包括消费成功以及消费失败；

若所述业务消息的消费状态更新为消费失败，则删除所述消息队列以及所述redis缓存中的所述业务消息，并将所述业务消息存入数据库中，使得所述数据库按照以预设时间间隔为定时任务，触发消费失败补偿机制；

若所述业务消息的消费状态更新为消费成功，则删除所述消息队列以及所述redis缓存中的所述业务消息。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储程序代码，所述程序代码用于执行权利要求1-7任一项所述的避免消息队列中消息丢失的处理方法。

Images