CN116094651A - 消息重试方法、系统、电子设备及存储介质 - Google Patents

Abstract

本申请提供一种消息重试方法、系统、电子设备及存储介质，该方法应用于包括服务器和RabbitMQ中间件的控制系统，RabbitMQ中间件中设置有延迟队列、中转队列和至少一个重试队列，该方法包括：服务器在对消息队列中的第一消息消费失败时，生成第一消息对应的重试消息并存储至延迟队列，重试消息为统一的目标格式，消息队列中存储的消息共用延迟队列；在延迟队列中的重试消息流转至中转队列时，服务器获取重试消息并在确定重试消息满足重试条件时，将重试消息对应的第一消息存储至目标重试队列，服务器对目标重试队列中的第一消息进行消费。本申请可减少延迟队列和重试队列的数量，对符合条件的消息重新推送，提高消息消费成功率。

Description

消息重试方法、系统、电子设备及存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种消息重试方法、系统、电子设备及存储介质。

背景技术

消息队列RabbitMQ是实现了高级消息队列协议(Advanced Message QueuingProtocol，AMQP)的开源消息代理软件，亦称面向消息的中间件。在业务设计过程中会经常使用RabbitMQ，以实现松耦合的功能应用。目前队列消费的场景逐渐增多，但是因为一些不可控的因素(如，请求第三方超时，数据库超时等)会导致队列消费不能正常结束，影响业务的流转。为了尽可能降低人为干预，提升系统性能，常常在异常的地方增加重试机制，通过建立延迟队列、重试队列的方式实现重试。

现有方式中在基于重试机制实现重试时，由于业务的差异往往一种消费者对应匹配的一种延迟队列和重试队列，虽然完成了重试功能，但涉及的延迟队列和重试队列会成倍的增加，不易于维护。

发明内容

鉴于上述问题，本申请实施例提供一种克服上述问题或者至少部分地解决上述问题的消息重试方法、系统、电子设备及存储介质。

第一方面，本申请实施例提供一种消息重试方法，应用于控制系统，所述控制系统包括服务器和RabbitMQ中间件，所述RabbitMQ中间件中设置有延迟队列、中转队列和至少一个重试队列，所述方法包括：

所述服务器在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列；

在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配；

所述服务器消费所述目标重试队列中的所述第一消息。

第二方面，本申请实施例提供一种消息重试的控制系统，所述控制系统包括服务器和RabbitMQ中间件，所述RabbitMQ中间件中设置有延迟队列、中转队列和至少一个重试队列；

所述服务器用于：在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列；

在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器还用于：获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配；

所述服务器还用于：消费所述目标重试队列中的所述第一消息。

第三方面，本申请实施例提供一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现第一方面所述的消息重试方法的步骤。

第四方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现第一方面所述的消息重试方法的步骤。

本申请实施例的技术方案，服务器在对消息队列中的第一消息消费失败的情况下，基于第一消息生成统一目标格式的重试消息，将重试消息存储至公用的延迟队列，可以实现不同业务场景共用同一延迟队列，减少延迟队列的数量；在延迟队列中的重试消息流转至中转队列后，服务器获取中转队列中的重试消息，并在确定重试消息满足重试条件时，将重试消息对应的第一消息存储至目标重试队列，可以通过中转队列为延迟队列流转出的重试消息提供一暂存空间，避免延迟队列流转出的重试消息直接进入重试队列，且可以实现对符合条件的消息重新进行推送，提高消息的消费成功率，降低后期人工接入的次数；通过针对每一业务类型设置一重试队列，可以减少重试队列的数量。

且本申请提供的重试机制在实现多个业务场景共用一套延迟队列和中转队列，同一业务类型的业务共用一重试队列的基础上，在有新业务应用时易于移植，易于维护，易于迭代，保障了业务的正常进行，同时可提高处理效率，降低维护成本。

附图说明

图1表示本申请实施例提供的控制系统对应的架构示意图之一；

图2表示本申请实施例提供的消息重试方法的示意图；

图3表示本申请实施例提供的RabbitMQ中间件配置的交换机以及队列的关联关系示意图；

图4表示本申请实施例提供的消息重试方法的整体实施流程示意图；

图5表示本申请实施例提供的消息重试方法的交互过程示意图；

图6表示本申请实施例提供的控制系统对应的架构示意图之二；

图7表示本申请实施例提供的电子设备的结构框图。

具体实施方式

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

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。

在本申请的各种实施例中，应理解，下述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。

本申请针对现有技术中在基于重试机制实现重试功能时，存在的延迟队列和重试队列成倍增加，不易于维护的问题，引入了一种新的消息重试机制，能够解决延迟队列、重试队列多的问题，且在有新业务应用时易于移植，能够保障业务的正常进行，同时可提高开发效率。其中，本申请的消息重试机制可以基于go语言、Java语言或者其他语言实现。

下面对本申请提供的消息重试方法进行介绍，本申请提供的消息重试方法，应用于控制系统，参见图1所示，所述控制系统包括服务器和RabbitMQ中间件，所述RabbitMQ中间件中设置有延迟队列、中转队列和至少一个重试队列，服务器可以与RabbitMQ中间件通信，向RabbitMQ中间件中的队列发送数据、访问RabbitMQ中间件中的队列。参见图2所示，该方法包括如下步骤：

步骤201、所述服务器在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列。

本实施例中服务器可以作为消费者，对存储于消息队列中的消息进行消费，在服务器对消息队列中的第一消息消费失败的情况下，生成第一消息对应的重试消息。其中，第一消息可以为消息队列在某一时刻提供给服务器的消息，为存储于消息队列中的多个消息中的其中一个。

在生成第一消息对应的重试消息之后，将重试消息存储至延迟队列中，本实施例中的重试消息为统一的目标格式，通过将重试消息配置为统一的目标格式，可以将消息队列中的不同消息对应的重试消息统一存储至支持目标格式的延迟队列，实现消息队列中所存储的消息可共用延迟队列，通过共享延迟队列，可以实现不同的业务场景共用同一延迟队列，以减少延迟队列的数量。

步骤202、在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配。

本实施例中的延迟队列相当于一个缓存队列，用于存储重试消息，但是延迟队列对重试消息的缓存时长有一定限制，在重试消息在延迟队列中的停留时长达到设定时长时，重试消息会自动流转至中转队列。中转队列相当于一个中转站，用于接收延迟队列流转出的重试消息，进而实现从延迟队列流转出的重试消息可以共用中转队列。

服务器通过访问中转队列获取中转队列中的重试消息，对重试消息是否满足重试条件进行判定。在确定重试消息满足重试条件时，将重试消息对应的第一消息存储到至少一个重试队列中的目标重试队列。

针对RabbitMQ中间件中设置的至少一个重试队列而言，每个重试队列对应于一业务类型。将重试消息对应的第一消息存储到重试队列时，需要基于第一消息对应的业务类型，在至少一个重试队列中筛选出目标重试队列，目标重试队列的业务类型与第一消息的业务类型匹配。这里的匹配可以是两个业务类型相同，针对至少一个重试队列中不存在业务类型与第一消息的业务类型相同的重试队列的情况，这里的匹配可以是业务类型相近。

由于RabbitMQ中间件基于业务类型设置至少一个重试队列，可以实现每个业务类型对应于一重试队列，相较于现有技术中每个业务对应于一重试队列的情况，可以减少重试队列的数量。

且本申请通过引入中转队列，可以为延迟队列流转出的重试消息提供一暂存空间，避免延迟队列流转出的重试消息直接进入重试队列。通过服务器访问中转队列、判定重试消息是否满足重试条件，将满足重试条件的重试消息对应的第一消息存储至重试队列，保证重试队列中存储可以进行再次消费的消息，避免不满足条件的消息进入重试队列，在一定程度上提升了处理效率。

步骤203、所述服务器消费所述目标重试队列中的所述第一消息。

在将重试消息对应的第一消息存储至目标重试队列之后，服务器通过访问目标重试队列，可以再次消费第一消息，实现对消息失败的第一消息再次消费。

本申请上述实施过程，服务器在对消息队列中的第一消息消费失败的情况下，基于第一消息生成统一目标格式的重试消息，将重试消息存储至公用的延迟队列，可以实现不同业务场景共用同一延迟队列，减少延迟队列的数量；在延迟队列中的重试消息流转至中转队列后，服务器获取中转队列中的重试消息，并在确定重试消息满足重试条件时，将重试消息对应的第一消息存储至目标重试队列，可以通过中转队列为延迟队列流转出的重试消息提供一暂存空间，避免延迟队列流转出的重试消息直接进入重试队列，且可以实现对符合条件的消息重新进行推送，提高消息的消费成功率，降低后期人工接入的次数；通过针对每一业务类型设置一重试队列，可以减少重试队列的数量。

且本申请提供的重试机制在实现多个业务场景共用一套延迟队列和中转队列，同一业务类型的业务共用一重试队列的基础上，在有新业务应用时易于移植，易于维护，易于迭代，保障了业务的正常进行，同时可提高处理效率，降低维护成本。

下面对生成第一消息对应的重试消息的过程进行介绍，所述服务器生成所述第一消息对应的重试消息时，包括：

所述服务器对所述第一消息中的消息内容进行排序、拼接，对拼接结果进行加密生成消息内容签名；

所述服务器将所述第一消息对应的消息来源、消息内容和消息内容签名封装为统一的消息结构体，以获取所述重试消息；其中，所述第一消息对应的消息来源为预先配置。

服务器在确定第一消息对应的消息内容签名时，针对第一消息中的消息内容进行排序，在排序之后将消息内容以&字符进行连接，以实现对排序后的消息内容进行拼接，获取拼接结果。然后对拼接成的字符串进行加密生成消息内容签名，在进行加密处理时可以采用预设加密方式，如采用MD5信息摘要算法(MD5 Message-Digest Algorithm)进行加密。

需要说明的是，本实施例中的消息内容为对应于key和value的数据格式，在对消息内容进行排序时，可以基于消息内容中的key进行排序，如按照首字母从a到z的顺序进行排序，若遇到相同首字母，则看第二个字母，其中，所有一级节点包含二级节点的，二级节点也需要按照从a到z的顺序排序，以此类推。在排序完成之后，可以将所有key及对应的value按照key＝value&key＝value……的形式拼接，再对拼成的字符串采用MD5加密。

服务器在基于消息内容获取消息内容签名之后，可以将第一消息对应的消息来源、消息内容和消息内容签名封装为统一的消息结构体，以获取重试消息，即，本实施例中的重试消息为构建的消息结构体；其中第一消息对应的消息来源为预先配置。

通过构建统一的消息结构体，以获取重试消息，可以将消息队列中的不同消息对应的重试消息统一存储至延迟队列，实现消息队列中所存储的消息对应的消息结构体可共用延迟队列，其中，不同消息对应的消息结构体可共用延迟队列，可以理解为消息队列中的不同消息可共用延迟队列。

在本申请一实施例中，所述方法还包括：

所述RabbitMQ中间件配置延迟交换机和所述延迟队列，设置所述延迟队列的队列属性并将所述延迟交换机和所述延迟队列进行绑定，所述队列属性包括限制时长、所述延迟队列与重试中转交换机的第一绑定关系；

所述RabbitMQ中间件配置所述重试中转交换机和所述中转队列，并将所述重试中转交换机和所述中转队列进行绑定；

所述RabbitMQ中间件配置重试交换机和所述至少一个重试队列，并将所述重试交换机和所述至少一个重试队列进行绑定。

本申请实施例中的RabbitMQ中间件可以配置延迟交换机、重试中转交换机以及重试交换机，并可以配置与延迟交换机绑定的延迟队列、与重试中转交换机绑定的中转队列以及与重试交换机绑定的至少一个重试队列。即，RabbitMQ中间件包括延迟交换机、重试中转交换机、重试交换机、延迟队列、中转队列以及至少一个重试队列。具体而言，RabbitMQ中间件配置延迟交换机和延迟队列，建立两者的绑定关系，实现将延迟交换机和延迟队列进行绑定；RabbitMQ中间件配置重试中转交换机和中转队列，建立两者的绑定关系，实现将重试中转交换机和中转队列进行绑定；RabbitMQ中间件配置重试交换机和至少一个重试队列，建立重试交换机和至少一个重试队列的绑定关系，实现将重试交换机和至少一个重试队列进行绑定。

RabbitMQ中间件还需要针对延迟队列，设置延迟队列的队列属性，延迟队列的队列属性至少包括限制时长、延迟队列与重试中转交换机的第一绑定关系。这里的限制时长即为允许消息在延迟队列中停留的时长阈值，即，消息在延迟队列中缓存的时长不能大于该时长阈值。针对延迟队列而言，其对应的第一绑定关系所绑定的对象为重试中转交换机，通过设置第一绑定关系，可以实现延迟队列中的重试消息在满足流转条件(在延迟队列中的停留时长达到限制时长)时、自动流转至重试中转交换机，进而暂存至中转队列。

参见图3所示，为延迟交换机、延迟队列、重试中转交换机、中转队列、重试交换机、至少一个重试队列的关联关系的具体示意。

本实施例中延迟交换机、延迟队列、重试中转交换机、中转队列以及重试交换机的数量均为一个，即，延迟交换机、延迟队列、重试中转交换机、中转队列以及重试交换机可以由不同的消息共享；重试队列的数量与业务类型相关，每个业务类型对应于一重试队列，可以将同一业务类型的消息分发至同一重试队列，实现同一业务类型的消息的聚合，且相较于现有的一个业务对应于一重试队列的方案，可以大大减少重试队列的数量。

本申请所提供的重试机制，可以基于延迟交换机、延迟队列、重试中转交换机、中转队列以及重试交换机的共享，减少延迟交换机、延迟队列以及重试交换机的数量，通过引入可由不同消息共享的重试中转交换机和中转队列，可以通过中转队列为延迟队列流转出的重试消息提供一暂存空间，避免延迟队列流转出的重试消息直接进入重试队列；通过基于业务类型设置重试队列，可以大大减少重试队列的数量。

在本申请一实施例中，所述服务器将所述重试消息存储至所述延迟队列，包括：所述服务器将所述重试消息发送至所述延迟交换机，由所述延迟交换机将所述重试消息存储至所述延迟队列。

服务器在生成重试消息、将重试消息存储至延迟队列时，可以将重试消息发送至延迟交换机，由延迟交换机基于与延迟队列的绑定关系、将接收到的重试消息存储至延迟队列，实现基于延迟队列缓存重试消息。

相应地，在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器获取所述中转队列中的所述重试消息时，包括：

在所述重试消息在所述延迟队列中的存储时长达到所述限制时长的情况下，所述重试中转交换机基于所述第一绑定关系获取所述延迟队列流转出的所述重试消息、将所述重试消息存储至所述中转队列；

所述服务器访问所述中转队列、以获取所述中转队列中的所述重试消息。

重试消息存储于延迟队列之后，在重试消息在延迟队列中的存储时长达到限制时长时，重试消息可自动流转出延迟队列，并基于延迟队列的队列属性，自动进入重试中转交换机，具体为基于延迟队列与重试中转交换机的第一绑定关系，重试消息自动进入重试中转交换机。重试中转交换机基于第一绑定关系获取延迟队列流转出的重试消息之后、将重试消息存储至中转队列，实现将重试消息暂存至中转队列，等待服务器的访问。服务器通过访问中转队列、获取中转队列中的重试消息。其中，服务器可以对中转队列进行监听，在监听到中转队列进入重试消息的情况下，访问中转队列，获取重试消息，在服务器获取重试消息之后，中转队列可以不再存储该重试消息。

服务器在获取中转队列中的重试消息之后，判定重试消息是否满足重试条件，若重试消息满足重试条件，则将重试消息对应的第一消息发送至重试交换机，由重试交换机基于第一消息的业务类型在至少一个重试队列中确定目标重试队列，将第一消息存储至目标重试队列。

下面对基于消费失败的第一消息生成重试消息、重试消息流转的过程进行介绍。服务器在消费第一消息失败的情况下，根据第一消息的消息内容生成消息内容签名，将第一消息对应的消息来源、消息内容和消息内容签名封装为统一的消息结构体，以获取重试消息。将获取的重试消息发送至延迟交换机，延迟交换机将接收到的重试消息存储至延迟队列。在重试消息在延迟队列中的停留时长达到限制时长时，重试消息基于第一绑定关系自动流转至重试中转交换机，重试中转交换机将重试消息暂存至中转队列。服务器通过访问中转队列获取重试消息，判定重试消息是否满足重试条件，在确定重试消息满足重试条件的情况下，将重试消息对应的第一消息发送至重试交换机，重试交换机将重试消息对应的第一消息存储至对应的重试队列，在重试消息不满足重试条件的情况下，则忽略该重试消息，同时中转队列中也不会继续暂存该重试消息。

本申请上述实施过程，服务器基于与延迟交换机的交互将重试消息存储至延迟队列，在重试消息从延迟队列中流转出之后通过重试中转交换机暂存至中转队列，可以避免延迟队列流转出的重试消息直接进入重试队列；服务器通过访问中转队列筛选满足重试条件的重试消息，以便于对符合条件的消息重新进行推送，提高消息的消费成功率。

在本申请一实施例中，操作人员可以预先通过yml的方式配置待消费消息对应的重试次数、消息来源、业务有效期，在执行本申请的消息重试方法时加载配置的内容，其中消息来源用于与其他信息配合生成重试消息，重试次数以及业务有效期用于进行重试消息是否满足重试条件的判定。不同的业务对应的重试次数、业务有效期可以有所区别，不同消息对应的消息来源可以有所区别，消息队列中的消息为待消费消息。

下面对服务器判定重试消息是否满足重试条件的过程进行介绍，服务器在获取所述中转队列中的所述重试消息之后，对所述重试消息进行解析，获取所述第一消息对应的消息内容签名；将所述第一消息对应的消息内容签名记为key、对key进行加1增量操作，比较增量操作返回值和所述第一消息对应的重试次数阈值；在所述增量操作返回值小于所述第一消息对应的重试次数阈值的情况下，检测所述第一消息对应的消息内容签名是否在所述第一消息对应的业务有效期内；在所述第一消息对应的消息内容签名在所述第一消息对应的业务有效期内的情况下，确定所述重试消息满足所述重试条件；其中，所述第一消息对应的重试次数阈值和业务有效期为预先配置。

本申请实施例对应的存储环境为redis环境，即数据采用key-value的形式进行存储。服务器在访问中转队列获取重试消息之后，对重试消息进行解析，获取第一消息对应的消息来源、消息内容以及消息内容签名，然后将第一消息对应的消息内容签名记为key、对key进行incr操作，将key中存储的数字值增1，获取增量操作返回值，这里的增量操作返回值为key对应的value。

在获取增量操作返回值之后，比较增量操作返回值和第一消息对应的重试次数阈值，在增量操作返回值小于第一消息对应的重试次数阈值的情况下，确定第一消息的重试次数未超过重试次数阈值，可以继续检测第一消息对应的消息内容签名是否在第一消息对应的业务有效期内，若在，则可以直接确定重试消息满足重试条件，否则确定重试消息不满足重试条件。

其中，由于第一消息对应的业务有效期为预先配置，本实施例对应于redis环境，在检测第一消息对应的消息内容签名是否在第一消息对应的业务有效期内时，可以在确定当前重试为首次重试时，基于预先配置的第一消息对应的业务有效期在redis中设置业务有效期，以便于后续使用。在基于增量操作返回值确定当前重试为非首次重试时，可以直接检测第一消息对应的消息内容签名是否在第一消息对应的业务有效期内(相当于检测消息内容签名在redis中的有效期是否已失效)。

本申请上述实施过程，服务器在获取重试消息之后，对其进行解析获取第一消息对应的消息内容签名，基于第一消息对应的消息内容签名检测第一消息的重试次数是否超过重试次数阈值，在未超过的情况下，检测第一消息对应的消息内容签名是否在第一消息对应的业务有效期内，实现在重试次数以及有效期两个维度检测重试消息是否满足重试条件。

在本申请一实施例中，所述将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，包括：

所述服务器在确定所述重试消息满足重试条件的情况下，将所述重试消息对应的第一消息和所述第一消息关联的路由关键字routingkey发送至所述重试交换机，由所述重试交换机基于所述第一消息关联的routingkey将所述第一消息存储至所述目标重试队列；

其中，所述重试交换机基于所述第一消息关联的routingkey在所述至少一个重试队列中确定与所述第一消息的业务类型匹配的所述目标重试队列。

服务器在通过检测确定重试消息满足重试条件的情况下，确定重试消息对应的第一消息，将重试消息对应的第一消息和第一消息关联的routingkey发送至重试交换机。由于服务器在检测重试消息是否满足重试条件时，需要对重试消息进行解析获取第一消息对应的消息来源、消息内容以及消息内容签名，则服务器可以直接基于消息内容确定第一消息，第一消息关联的routingkey可以基于第一消息对应的消息来源确定。

重试交换机在接收到重试消息对应的第一消息以及第一消息所关联的routingkey之后，基于第一消息关联的routingkey将重试消息对应的第一消息存储至目标重试队列。第一消息关联的routingkey中可以存储有分发规则，重试交换机利用第一消息关联的routingkey中的分发规则可以在至少一个重试队列中确定与第一消息的业务类型匹配的目标重试队列，并将第一消息分发至目标重试队列。

本申请上述实施过程，通过将第一消息发送至重试交换机，重试交换机在至少一个重试队列中筛选出与第一消息对应的业务类型匹配的目标重试队列，将第一消息存储至目标重试队列，可以基于业务类型实现第一消息的分发。

在本申请一实施例中，在所述服务器消费所述目标重试队列中的所述第一消息之后，所述方法还包括：在消费成功的情况下，终止对所述第一消息的消费；在消费失败的情况下，将所述第一消息对应的消息来源、消息内容和消息内容签名重新封装为重试消息，将重新生成的重试消息发送至所述延迟队列。

在服务器对目标重试队列中的第一消息进行消费之后，若消费成功，则终止对第一消息的消费；若消费失败，则可以将第一消息对应的消息来源、消息内容和消息内容签名重新封装为重试消息，并将重新生成的重试消息发送至延迟队列进行缓存，以便于可以在重新生成的重试消息满足重试条件的情况下，继续消费第一消息。

上述过程，在对目标重试队列中的第一消息消费失败之后，通过重新生成重试消息，可以再次提供对第一消息进行消费的机会，以提高消息消费成功率。

下面通过一整体实施流程对本申请提供的消息重试方法进行介绍，参见图4所示，包括如下步骤：

步骤401、服务器对消息队列中的第一消息进行消费。在消费失败的情况下，执行步骤402，在消费成功的情况下，执行步骤411。

步骤402、服务器根据第一消息对应的消息内容、消息来源以及消息内容签名，生成第一消息对应的重试消息，将重试消息发送至延迟交换机。

步骤403、延迟交换机将收到的重试消息存储至延迟队列。

步骤404、在重试消息在延迟队列中的停留时长达到限制时长时，基于第一绑定关系，重试消息自动流转至重试中转交换机。

步骤405、重试中转交换机将重试消息暂存至中转队列。

步骤406、服务器访问中转队列获取重试消息，解析重试消息，获取第一消息对应的消息内容、消息内容签名、消息来源，基于第一消息对应的消息内容签名确定重试消息是否满足重试条件。在满足重试条件的情况下，执行步骤407，否则执行步骤411。

步骤407、将第一消息发送至重试交换机。

步骤408、重试交换机基于第一消息对应的业务类型将第一消息存储至目标重试队列。

步骤409、服务器对目标重试队列中的第一消息进行消费，在消费成功的情况下，执行步骤411，否则执行步骤410。

步骤410、根据第一消息重新生成重试消息，将重试消息发送至延迟交换机。

步骤411、终止对第一消息的消费。

上述实施流程，对应的交互情况可参见图5所示，服务器向延迟交换机发送第一消息的重试消息，延迟交换机将重试消息存储至延迟队列，延迟队列中的重试消息自动流转至重试中转交换机，重试中转交换机将重试消息暂存至中转队列，中转队列中满足重试条件的重试消息对应的第一消息传输至重试交换机，重试交换机将第一消息缓存至对应的重试队列，在服务器对重试队列中的第一消息消费成功时，终止对第一消息的消费，在服务器对重试队列中的第一消息消费失败时，重新生成重试消息发送至延迟交换机。

上述实施过程，通过将重试消息存储至公用的延迟队列，可以减少延迟队列的数量；通过引入中转队列可以为延迟队列流转出的重试消息提供一暂存空间，通过进行是否满足重试条件的检测，可以对符合条件的消息重新进行推送，提高消息的消费成功率；通过针对每一业务类型设置一重试队列，可以减少重试队列的数量；通过重新生成重试消息，可以再次提供对第一消息进行消费的机会。

以上为本申请提供的消息重试方法的整体实施流程，服务器在对消息队列中的第一消息消费失败的情况下，基于第一消息生成统一目标格式的重试消息，将重试消息存储至公用的延迟队列，可以实现不同业务场景共用同一延迟队列，减少延迟队列的数量；在延迟队列中的重试消息流转至中转队列后，服务器获取中转队列中的重试消息，并在确定重试消息满足重试条件时，将重试消息对应的第一消息存储至目标重试队列，可以通过中转队列为延迟队列流转出的重试消息提供一暂存空间，避免延迟队列流转出的重试消息直接进入重试队列，且可以实现对符合条件的消息重新进行推送，提高消息的消费成功率，降低后期人工接入的次数；通过针对每一业务类型设置一重试队列，可以减少重试队列的数量。

且本申请提供的重试机制在实现多个业务场景共用一套延迟队列和中转队列，同一业务类型的业务共用一重试队列的基础上，在有新业务应用时易于移植，易于维护，易于迭代，保障了业务的正常进行，同时可提高处理效率，降低维护成本。

服务器在获取重试消息之后，对其进行解析，在重试次数以及有效期两个维度检测重试消息是否满足重试条件，可以实现筛选出符合条件的消息以重新推送；通过重新生成重试消息，可以再次提供对第一消息进行消费的机会，以提高消息消费成功率。

本申请实施例还提供一种消息重试的控制系统，参见图6所示，所述控制系统600包括服务器601和RabbitMQ中间件602，所述RabbitMQ中间件602中设置有延迟队列、中转队列和至少一个重试队列；

所述服务器601用于：在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列；

在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器601还用于：获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配；

所述服务器601还用于：消费所述目标重试队列中的所述第一消息。

可选地，所述服务器601在生成所述第一消息对应的重试消息时，还用于：对所述第一消息中的消息内容进行排序、拼接，对拼接结果进行加密生成消息内容签名；将所述第一消息对应的消息来源、消息内容和消息内容签名封装为统一的消息结构体，以获取所述重试消息；其中，所述第一消息对应的消息来源为预先配置。

可选地，所述RabbitMQ中间件602还用于：配置延迟交换机6021和所述延迟队列，设置所述延迟队列的队列属性并将所述延迟交换机6021和所述延迟队列进行绑定，所述队列属性包括限制时长、所述延迟队列与重试中转交换机6022的第一绑定关系；配置所述重试中转交换机6022和所述中转队列，并将所述重试中转交换机6022和所述中转队列进行绑定；配置重试交换机6023和所述至少一个重试队列，并将所述重试交换机6023和所述至少一个重试队列进行绑定。RabbitMQ中间件602可以包括延迟交换机6021、重试中转交换机6022、重试交换机6023、延迟队列、中转队列以及至少一个重试队列。

可选地，所述服务器601在将所述重试消息存储至所述延迟队列时，还用于：将所述重试消息发送至所述延迟交换机6021，由所述延迟交换机6021将所述重试消息存储至所述延迟队列。

可选地，在所述重试消息在所述延迟队列中的存储时长达到所述限制时长的情况下，所述重试中转交换机6022基于所述第一绑定关系获取所述延迟队列流转出的所述重试消息、将所述重试消息存储至所述中转队列；

所述服务器601用于访问所述中转队列、以获取所述中转队列中的所述重试消息。

可选地，所述服务器601在获取所述中转队列中的所述重试消息之后，还用于：对所述重试消息进行解析，获取所述第一消息对应的消息内容签名；将所述第一消息对应的消息内容签名记为key、对key进行加1增量操作，比较增量操作返回值和所述第一消息对应的重试次数阈值；在所述增量操作返回值小于所述第一消息对应的重试次数阈值的情况下，检测所述第一消息对应的消息内容签名是否在所述第一消息对应的业务有效期内；在所述第一消息对应的消息内容签名在所述第一消息对应的业务有效期内的情况下，确定所述重试消息满足所述重试条件；其中，所述第一消息对应的重试次数阈值和业务有效期为预先配置。

可选地，在将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列时，所述服务器601还用于：在确定所述重试消息满足重试条件的情况下，将所述重试消息对应的第一消息和所述第一消息关联的路由关键字routingkey发送至所述重试交换机6023，由所述重试交换机6023基于所述第一消息关联的routingkey将所述第一消息存储至所述目标重试队列；其中，所述重试交换机6023基于所述第一消息关联的routingkey在所述至少一个重试队列中确定与所述第一消息的业务类型匹配的所述目标重试队列。

可选地，所述服务器601在消费所述目标重试队列中的所述第一消息之后，还用于：在消费成功的情况下，终止对所述第一消息的消费；在消费失败的情况下，将所述第一消息对应的消息来源、消息内容和消息内容签名重新封装为重试消息，将重新生成的重试消息发送至所述延迟队列。

以上为关于消息重试的控制系统的相关介绍，对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可，这里不再进一步阐述。

另一方面，本申请实施例还提供了一种电子设备，包括存储器、处理器、总线以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述消息重试方法中的步骤。

举例如下，图7示出了一种电子设备的实体结构示意图。如图7所示，该电子设备可以包括：处理器(processor)710、通信接口(Communications Interface)720、存储器(memory)730和通信总线740，其中，处理器710，通信接口720，存储器730通过通信总线740完成相互间的通信。处理器710可以调用存储器730中的逻辑指令，处理器710用于执行以下步骤：在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列；在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配；消费所述目标重试队列中的所述第一消息。其中，处理器710还可以执行本方案中的其他步骤，这里不再进行一一阐述。

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

再一方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述各实施例提供的消息重试方法中的步骤。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

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

Claims (11)

1.一种消息重试方法，应用于控制系统，其特征在于，所述控制系统包括服务器和RabbitMQ中间件，所述RabbitMQ中间件中设置有延迟队列、中转队列和至少一个重试队列，所述方法包括：

所述服务器在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列；

在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配；

所述服务器消费所述目标重试队列中的所述第一消息。

2.根据权利要求1所述的方法，其特征在于，所述服务器生成所述第一消息对应的重试消息，包括：

所述服务器对所述第一消息中的消息内容进行排序、拼接，对拼接结果进行加密生成消息内容签名；

所述服务器将所述第一消息对应的消息来源、消息内容和消息内容签名封装为统一的消息结构体，以获取所述重试消息；其中，所述第一消息对应的消息来源为预先配置。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述RabbitMQ中间件配置延迟交换机和所述延迟队列，设置所述延迟队列的队列属性并将所述延迟交换机和所述延迟队列进行绑定，所述队列属性包括限制时长、所述延迟队列与重试中转交换机的第一绑定关系；

所述RabbitMQ中间件配置所述重试中转交换机和所述中转队列，并将所述重试中转交换机和所述中转队列进行绑定；

所述RabbitMQ中间件配置重试交换机和所述至少一个重试队列，并将所述重试交换机和所述至少一个重试队列进行绑定。

4.根据权利要求3所述的方法，其特征在于，所述服务器将所述重试消息存储至所述延迟队列，包括：

所述服务器将所述重试消息发送至所述延迟交换机，由所述延迟交换机将所述重试消息存储至所述延迟队列。

5.根据权利要求3所述的方法，其特征在于，所述在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器获取所述中转队列中的所述重试消息，包括：

在所述重试消息在所述延迟队列中的存储时长达到所述限制时长的情况下，所述重试中转交换机基于所述第一绑定关系获取所述延迟队列流转出的所述重试消息、将所述重试消息存储至所述中转队列；

所述服务器访问所述中转队列、获取所述中转队列中的所述重试消息。

6.根据权利要求2所述的方法，其特征在于，所述服务器在获取所述中转队列中的所述重试消息之后，所述方法还包括：

对所述重试消息进行解析，获取所述第一消息对应的消息内容签名；

将所述第一消息对应的消息内容签名记为key、对key进行加1增量操作，比较增量操作返回值和所述第一消息对应的重试次数阈值；

在所述增量操作返回值小于所述第一消息对应的重试次数阈值的情况下，检测所述第一消息对应的消息内容签名是否在所述第一消息对应的业务有效期内；

在所述第一消息对应的消息内容签名在所述第一消息对应的业务有效期内的情况下，确定所述重试消息满足所述重试条件；

其中，所述第一消息对应的重试次数阈值和业务有效期为预先配置。

7.根据权利要求3所述的方法，其特征在于，所述将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，包括：

所述服务器在确定所述重试消息满足重试条件的情况下，将所述重试消息对应的第一消息和所述第一消息关联的路由关键字routingkey发送至所述重试交换机，由所述重试交换机基于所述第一消息关联的routingkey将所述第一消息存储至所述目标重试队列；

其中，所述重试交换机基于所述第一消息关联的routingkey在所述至少一个重试队列中确定与所述第一消息的业务类型匹配的所述目标重试队列。

8.根据权利要求2所述的方法，其特征在于，在所述服务器消费所述目标重试队列中的所述第一消息之后，所述方法还包括：

在消费成功的情况下，终止对所述第一消息的消费；

在消费失败的情况下，将所述第一消息对应的消息来源、消息内容和消息内容签名重新封装为重试消息，将重新生成的重试消息发送至所述延迟队列。

9.一种消息重试的控制系统，其特征在于，所述控制系统包括服务器和RabbitMQ中间件，所述RabbitMQ中间件中设置有延迟队列、中转队列和至少一个重试队列；

所述服务器用于：在对消息队列中的第一消息消费失败的情况下，生成所述第一消息对应的重试消息、将所述重试消息存储至所述延迟队列，所述重试消息为统一的目标格式，所述消息队列中存储的消息共用所述延迟队列；

在所述延迟队列中的所述重试消息流转至所述中转队列的情况下，所述服务器还用于：获取所述中转队列中的所述重试消息，并在确定所述重试消息满足重试条件时，将所述重试消息对应的第一消息存储至所述至少一个重试队列中的目标重试队列，每个重试队列对应于一业务类型，所述目标重试队列对应的业务类型与所述第一消息对应的业务类型匹配；

所述服务器还用于：消费所述目标重试队列中的所述第一消息。

10.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至8任一项所述的消息重试方法的步骤。

11.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储计算机程序，所述计算机程序被处理器执行时实现如权利要求1至8任一项所述的消息重试方法的步骤。

Images