基于RabbitMQ死信队列的任务处理方法和系统与流程

基于rabbitmq死信队列的任务处理方法和系统
技术领域
1.本发明属于消息处理技术领域，尤其涉及一种基于rabbitmq死信队列的任务处理方法和系统。


背景技术：

2.rabbitmq是一个开源的amqp实现，服务器端用erlang语言编写，支持多种客户端。用于在分布式系统中存储转发消息。在软件日常开发过程中，会遇到一种场景，当消息处理在消费端系统遇到异常场景返回队列中时，消费端会立即再次获取处理，若此时异常情况未得到解决，就会产生无休止的消息交互，给消费端系统带来极大的负载压力及资源消耗。例如，提现成功后需要发送短信或通知提醒到用户，若正巧运营商升级暂时无法提供服务，系统则持续不断尝试访问运营商，直至运营商系统恢复为止。
3.虽然rabbitmq自身有提供消息过期和死信机制，但两种方式都有局限性。消息过期仅对队列中的首条消息有效；死信队列仅能在队列上设置固定存活时间，基于以上传统方式实现的延迟队列机制则也只能按固定时间差进行消息补偿，缺乏灵活度，且队列消息数据量庞大时，在队列ttl到期的瞬间仍会给消费端系统带来压力。


技术实现要素：

4.本发明针对现有技术中的不足，提供一种基于rabbitmq死信队列的任务处理方法和系统。
5.第一方面，本发明提供一种基于rabbitmq死信队列的任务处理方法，包括：
6.s1，创建业务队列normal_queue；配置业务队列的参数x-dead-letter-exchange和x-dead-letter-routing-key指向死信队列；
7.s2，创建死信队列normal_queue_retry；配置死信队列的参数x-dead-letter-exchange和x-dead-letter-routing-key指向业务队列；
8.s3，配置死信队列的参数x-message-ttl设置补偿消息在死信队列中的存活时间；
9.s4，当业务队列处理消息时，对消息报文头自定义属性retry-times补偿次数进行判断校验；
10.s5，如果存在retry-times属性，则消息为补偿消息并根据阶梯策略判断补偿消息是否到达执行补偿的时间；
11.s6，如果补偿消息已到达最大补偿次数，则直接删除消息；
12.s7，如果补偿消息已到补偿时间，则进行s10的操作；
13.s8，如果补偿消息未到补偿时间，则将消息再返回死信队列中等待下次轮询并进行s13的操作；
14.s9，如果不存在retry-times属性，则消息为正常消息并进行s10的操作；
15.s10，判断消息正常处理是否成功；
16.s11，如果否，则复制当前消息报文并在消息头中添加自定义属性msg-timestamp
times补偿次数进行判断校验；
39.第二判断模块，用于在第一判断模块确定存在retry-times属性的情况下，确定消息为补偿消息并根据阶梯策略判断补偿消息是否到达执行补偿的时间；
40.第一消息删除模块，用于在第二判断模块确定补偿消息已到达最大补偿次数的情况下，直接删除消息；
41.第一消息正常处理模块，用于在第二判断模块确定补偿消息已到补偿时间的情况下，执行第三判断模块的操作；
42.第一消息转移模块，用于在第二判断模块确定补偿消息未到补偿时间的情况下，将消息再返回死信队列中等待下次轮询并执行第三消息转移模块的操作；
43.第二消息正常处理模块，用于在第一判断模块确定不存在retry-times属性，确定消息为正常消息并执行第三判断模块的操作；
44.第三判断模块，用于判断消息正常处理是否成功；
45.第二消息转移模块，用于在第三判断模块确定消息正常处理没有成功的情况下，复制当前消息报文并在消息头中添加自定义属性msg-timestamp为当前时间的时间戳，并将消息发送至死信队列；
46.第一消息删除模块，用于在第三判断模块确定消息正常处理成功的情况下，正常确认并删除消息；
47.第三消息转移模块，用于消息在延迟队列到期后通过死信队列的交换机转发至与消息携带的路由键相匹配的业务队列中，以供消费者尝试消费并返回执行第一判断模块的操作。
48.第三方面，本发明提供一种计算机设备，包括处理器和存储器；其中，处理器执行存储器中保存的计算机程序时实现第一方面所述的基于rabbitmq死信队列的任务处理方法的步骤。
49.第四方面，本发明提供一种计算机可读存储介质，用于存储计算机程序；计算机程序被处理器执行时实现第一方面所述的基于rabbitmq死信队列的任务处理方法的步骤。
50.本发明提供一种基于rabbitmq死信队列的任务处理方法和系统，其中方法保留rabbitmq原有延迟队列特性的同时，使用自定义请求头消息拒绝策略结合自定义执行策略校验，使得消息队列的消息执行可以突破原生消息ttl及死信队列的局限性，可根据实际生产开发需要灵活定制合适的消息补偿策略，不仅有效减少业务系统间短时间内非必要的频繁交互，还能显著分散大批量消息执行所带来的系统压力，并且本发明仅需两个队列即可完成消息流转，相较于需要多个不同ttl死信队列的传统方案更加简洁精炼；另外适配消息队列的消息最终销毁确认功能，清除补偿总耗时过长的消息队列的消息，节省rabbitmq内存空间，避免死信队列消息积压。
附图说明
51.为了更清楚地说明本发明的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
52.图1为本发明实施例提供的一种基于rabbitmq死信队列的任务处理方法的流程
图；
53.图2为本发明实施例提供的一种基于rabbitmq死信队列的任务处理方法的结构示意图；
54.图3为本发明实施例提供的一种基于rabbitmq死信队列的任务处理系统的结构示意图。
具体实施方式
55.下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
56.在一实施例中，如图1和图2所示，本发明实施例提供一种基于rabbitmq死信队列的任务处理方法，包括：
57.步骤s1，创建业务队列normal_queue；配置业务队列的参数x-dead-letter-exchange和x-dead-letter-routing-key指向死信队列。
58.创建含有死信配置的死信队列，用于存储还未被消费者处理完成的消息，受单个或多个消费者系统消息获取及控制消息流转。死信队列在本实施例中需要额外增加死信配置参数x-dead-letter-exchange和x-dead-letter-routing-key，分别指定了死信队列的交换机和路由键，当死信队列内有消息拒绝或者过期时，会根据此死信队列的交换机(dlx)配置将消息自动转发至相应的死信队列中暂存。
59.步骤s2，创建死信队列normal_queue_retry；配置死信队列的参数x-dead-letter-exchange和x-dead-letter-routing-key指向业务队列。
60.步骤s3，配置死信队列的参数x-message-ttl设置补偿消息在死信队列中的存活时间。
61.本步骤中，在消息本身的存活时间大于消息所在队列的存活时间的情况下，消息本身的存活时间取决于其所在队列的存活时间；在消息本身的存活时间小于消息所在队列的存活时间的情况下，消息满足本身的存活时间后变为死信。
62.通过在basic.publish方法中加入expiration的参数属性，单位ms，来设置消息有效期ttl。
63.可选地，设置方案包括以下两种：
64.1)直接对amqp的基础属性设置有效期，即对amqp.basicproperties的expiration参
65.数设置值，此时，在消息本身的存活时间小于消息所在队列的存活时间的前提下，消息到达有效期即从所在队列中抹除。
66.2)通过方法调用对amqp的基础属性塞值，实现有效期的设置，此时，在消息本身的存活时间小于消息所在队列的存活时间的前提下，消息即使达到有效期，也不会马上在其所在的队列中抹除，且消息是否达到有效期是在消息即将投递到消费者之前判定的。
67.步骤s4，当业务队列处理消息时，对消息报文头自定义属性retry-times补偿次数进行判断校验。
68.步骤s5，如果存在retry-times属性，则消息为补偿消息并根据阶梯策略判断补偿消息是否到达执行补偿的时间。
69.步骤s6，如果补偿消息已到达最大补偿次数，则直接删除消息；避免消息在队列中积压。
70.步骤s7，如果补偿消息已到补偿时间，则进行s10的操作。
71.步骤s8，如果补偿消息未到补偿时间，则将消息再返回死信队列中等待下次轮询并进行s13的操作。
72.步骤s9，如果不存在retry-times属性，则消息为正常消息并进行s10的操作。
73.步骤s10，判断消息正常处理是否成功。
74.步骤s11，如果否，则复制当前消息报文并在消息头中添加自定义属性msg-timestamp为当前时间的时间戳，并将消息发送至死信队列。
75.步骤s12，如果是，则正常确认并删除消息。
76.步骤s13，消息在延迟队列到期后通过死信队列的交换机转发至与消息携带的路由键相匹配的业务队列中，以供消费者尝试消费并返回执行s4的操作。
77.需要说明的是，在定义一个消息队列是会绑定死信对接名称、死信队列的交换机、过期时间和延迟队列名称。在将消息推送到死信队列后，等待存活时间到了，会把过期的消息发布到死信队列的交换机中，死信队列的交换机会把过期的消息推送到延迟队列中，只需要监听延迟队列就会拿到需要重新推送的消息。
78.延迟队列用于临时存储死信队列拒绝或过期时自动转发过来的消息。延迟队列在本实施例中也需要指定死信配置参数x-dead-letter-exchange和x-dead-letter-routing-key，值为死信队列的交换机和路由键，代表延迟队列中拒绝或过期的消息会返回到死信队列中，但不同于死信队列，延迟队列是没有消费者监听，延迟队列中的消息永远不会被消费确认或拒绝，所以延迟队列需要新增一个死信配置参数x-message-ttl：队列中所有消息能够存活的时间，单位为毫秒数，本方案中以30秒为例。综上可知，延迟队列中所有消息每隔30秒自动过期并根据dlx配置将所有消息自动转发至死信队列中。
79.延迟队列中所有消息仅能以固定每隔30秒循环补偿，但无法自主控制每次执行的间隔时间，因此还需消费者对消息拒绝策略及执行策略进行修改适配，相互配合最终达成以阶梯式时间差作消息补偿。
80.针对消息拒绝策略，在消息消费异常需要补偿时，原生basicnack方法拒绝消息仅会把消息发送至死信队列，无法做出人为干预。采用由消费者自定义消息重新推送消息的方式：使用当前消息队列的消息报文体，创建一条带有自定义消息头的消息，自定义消息头包含字段retry-times(当前补偿次数)和msg-timestamp(当前消息创建时间戳)，最终组合后由消费者主动推送至延迟队列，最后调用basicack把当前消息队列的消息确认消费，从消息队列中抹除。
81.a)如果消息头中无自定义字段，代表是首次进入拒绝策略，则retry-times设置初始值1。
82.b)如果消息头中存在自定义字段，则获取retry-times当前值+1并重新赋值。
83.针对消息执行策略，在消费者获取到消息队列的消息准备业务执行前，需增加消费前置校验：校验当前消息队列的消息是否为补偿消息且已达到预期的执行时间；获取消
息队列的消息报文头，如果消息队列的消息报文头中含有自定义字段retry-times(当前补偿次数)，代表当前消息队列消息是补偿消息，此时可根据补偿次数及创建时间戳判断是否需要真正执行补偿业务流程。
84.a)在消息头中无自定义字段的情况下，代表非补偿消息，跳过执行策略验证。
85.b)在消息头中存在自定义字段的情况下，获取retry-times并计算出当前补偿次数对应所需的间隔时间；结合当前时间判断是否满足间隔时间要求，满足则开始执行消息处理流程，不满足则调用原生basicnack拒绝消息发送至延迟待队列，等待下次执行校验。
86.c)在消息头中存在自定义字段，且retry-times值大于一定基数的情况下，代表消息补偿总耗时已超出预期，选择销毁补偿总耗时超出预期的消息。
87.执行策略举例：1m，2m，4m，8m，16m，32m，1h，...；首次补偿间隔期需1分钟，第二次较于之前间隔期需2分钟，第七次开始每隔1小时补偿一次，直至48小时后不再补偿，消息最终销毁。在实际应用中应由开发者灵活制定贴合系统应用场景的执行策略，发挥系统最佳性能。一定要给补偿制定一个终止策略，防止过度积极的补偿策略对下游服务造成不利影响。需要说明的是，上述例子只是示例性说明，不应理解为对本发明的限制。
88.本实施例提供的基于rabbitmq死信队列的任务处理方法，保留rabbitmq原有延迟队列特性的同时，使用自定义请求头消息拒绝策略结合自定义执行策略校验，使得消息队列的消息执行可以突破原生消息ttl及死信队列的局限性，可根据实际生产开发需要灵活定制合适的消息补偿策略，不仅有效减少业务系统间短时间内非必要的频繁交互，还能显著分散大批量消息执行所带来的系统压力，并且本发明仅需两个队列即可完成消息流转，相较于需要多个不同ttl死信队列的传统方案更加简洁精炼；另外适配消息队列的消息最终销毁确认功能，清除补偿总耗时过长的消息队列的消息，节省rabbitmq内存空间，避免死信队列消息积压。
89.基于同一发明构思，本发明实施例还提供了基于rabbitmq死信队列的任务处理系统，由于该系统解决问题的原理与前述基于rabbitmq死信队列的任务处理方法相似，因此该系统的实施可以参见基于rabbitmq死信队列的任务处理方法的实施，重复之处不再赘述。
90.在另一实施例中，本发明一个实施例提供的基于rabbitmq死信队列的任务处理系统，如图3所示，包括：
91.业务队列创建模块10，用于创建业务队列normal_queue；配置业务队列的参数x-dead-letter-exchange和x-dead-letter-routing-key指向死信队列。
92.死信队列创建模块20，用于创建死信队列normal_queue_retry；配置死信队列的参数x-dead-letter-exchange和x-dead-letter-routing-key指向业务队列。
93.消息存活时间设置模块30，用于配置死信队列的参数x-message-ttl设置补偿消息在死信队列中的存活时间。
94.第一判断模块40，用于当业务队列处理消息时，对消息报文头自定义属性retry-times补偿次数进行判断校验。
95.第二判断模块50，用于在第一判断模块确定存在retry-times属性的情况下，确定消息为补偿消息并根据阶梯策略判断补偿消息是否到达执行补偿的时间。
96.第一消息删除模块60，用于在第二判断模块确定补偿消息已到达最大补偿次数的
情况下，直接删除消息。
97.第一消息正常处理模块70，用于在第二判断模块确定补偿消息已到补偿时间的情况下，执行第三判断模块的操作。
98.第一消息转移模块80，用于在第二判断模块确定补偿消息未到补偿时间的情况下，将消息再返回死信队列中等待下次轮询并执行第三消息转移模块的操作。
99.第二消息正常处理模块90，用于在第一判断模块确定不存在retry-times属性，确定消息为正常消息并执行第三判断模块的操作。
100.第三判断模块100，用于判断消息正常处理是否成功。
101.第二消息转移模块110，用于在第三判断模块确定消息正常处理没有成功的情况下，复制当前消息报文并在消息头中添加自定义属性msg-timestamp为当前时间的时间戳，并将消息发送至死信队列。
102.第一消息删除模块120，用于在第三判断模块确定消息正常处理成功的情况下，正常确认并删除消息。
103.第三消息转移模块130，用于消息在延迟队列到期后通过死信队列的交换机转发至与消息携带的路由键相匹配的业务队列中，以供消费者尝试消费并返回执行第一判断模块的操作。
104.关于上述各个模块更加具体的工作过程可以参考前述实施例公开的相应内容，在此不再进行赘述。
105.在另一实施例中，本发明实施例还提供了一种计算机设备，包括处理器和存储器；其中，处理器执行存储器中保存的计算机程序时实现前述实施例公开的基于rabbitmq死信队列的任务处理方法。
106.关于上述方法更加具体的过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
107.在另一实施例中，本发明实施例还提供一种计算机可读存储介质，用于存储计算机程序；计算机程序被处理器执行时实现前述公开的基于rabbitmq死信队列的任务处理方法。
108.关于上述方法更加具体的过程可以参考前述实施例中公开的相应内容，在此不再进行赘述。
109.本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似部分互相参见即可。对于实施例公开的系统、设备、存储介质而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
110.本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
111.以上结合具体实施方式和范例性实例对本发明进行了详细说明，不过这些说明并
不能理解为对本发明的限制。本领域技术人员理解，在不偏离本发明精神和范围的情况下，可以对本发明技术方案及其实施方式进行多种等价替换、修饰或改进，这些均落入本发明的范围内。本发明的保护范围以所附权利要求为准。