CN110224922A - 一种基于RabbitMQ的异步消息重试方法、系统及系统构建方法 - Google Patents

Abstract

本发明公开了一种基于RabbitMQ的异步消息重试方法、系统及系统构建方法，系统构建方法包括：配置交换的步骤、配置队列的步骤和将队列绑定到交换的步骤，通过该方法即可构建出系统。消息重试方法包括：在正常消息消费过程中，对处理失败的消息进行有限次重试的步骤，和对超出重试次数的消息进行人工处理的步骤；其中对消息的重试设置有延时机制，延时机制基于对消息设定的过期时间。本发明可对消费失败的消息自动进行分流重试，可避免对进程的影响和对系统资源的长期占用，所设置的人工介入处理可以确保消息的可靠消费。本发明可以设置消息的重试间隔，提高系统灵活性。

Description

一种基于RabbitMQ的异步消息重试方法、系统及系统构建 方法

技术领域

本发明涉及异步通信领域，尤其是一种基于RabbitMQ的消息重试系统的构建方法、基于该构建方法所构建的消息重试系统，以及基于该消息重试系统的异步消息重试方法。

背景技术

RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息中间件。通过客户端与RabbitMQ之间传递消息来进行不同进程Process/线程Thread之间的通信。这些客户端分为两类：Producer负责将消息发送到中间件；而Consumer负责从中间件取出消息并且处理该消息。在消息处理的过程中，由于业务逻辑错误，网络故障等原因导致处理任务失败。我们期望在消息消费异常时，自动延时将消息重试。目前基于RabbitMQ的实现方式主要有以下两种：

1.人工审核处理。消息消费异常时，Consumer记录详细信息到日志后立即ACK。后续人工查询日志并处理。它的缺点很明显，几乎没有自动重试逻辑，过多人工介入将造成高延迟、高成本。

2.Reject处理异常的消息。消息消费异常时，Consumer立即(或者hold住当前线程一段时间后)Reject该消息，消息中间件会将该消息重新放入队列里再消费。这种方式主要有以下两个问题：a.如果根本无法处理此消息，则可能导致无限循环；b.如果hold住当前线程，将大大降低Consumer的处理能力，如果立即reject，那么队列为空时将在消息被拒绝后立即处理该消息，非常高的重试的频率将导致资源严重浪费。

发明内容

本发明的发明目的在于：针对上述存在的问题，提供一种基于消息转发机制自动完成消息重试的方案，从而通过低复杂度的重试机制和简单的系统架构，实现可靠的消息消费。

本发明采用的技术方案如下：

一种基于RabbitMQ的消息重试系统的构建方法，其包括以下步骤：

A.分别创建第一交换、第二交换和第三交换，其中，发布的消息投递到第一交换，处理异常的消息投递到第二交换，处理失败的消息投递到第三交换；

B.分别创建第一队列、第二队列和第三队列，其中，第一队列用于存放发布的消息，第二队列用于存放处理异常的消息，第三队列用于存放处理失败的消息；

C.将第一队列绑定到第一交换，将第二队列绑定到第二交换，设置第二队列匹配所有路由匙，将第三队列绑定到第三交换，设置第三队列的路由匙匹配于对应的第三队列。

通过上述方法，可以构建出对消费失败的消息的自动分流、重试的系统，系统复杂度低，构建方法简单，通过三个交换和对应队列的配合，可使实现线程的分离，进而提高进程的处理效率，大幅提高系统的工作效率，避免了在消息处理失败时导致的系统资源的浪费。

进一步的，上述处理异常的消息是指重试次数未超过预定上限次数的消息，所述处理失败的消息是指重试次数超过所述预定上限次数的消息。

该设计可以避免无法处理的消息被无线循环处理，通过设计合理的门限，即可权衡对消息的处理成功率和系统开销。

本发明提供了一种基于RabbitMQ的消息重试系统，其由上述基于RabbitMQ的消息重试系统的构建方法构建而成。

本发明提供了一种基于上述基于RabbitMQ的消息重试系统的异步消息重试方法，其包括以下步骤：

S1.生产者发布消息到第一交换；

S2.所述第一交换根据路由匙将消息分发到对应的第一队列；

S3.消费者对所述第一队列中的消息进行消费；

S4.消息消费后，消费者向第一队列反馈处理成功与否，如果处理成功则结束流程，否则执行以下步骤；

S5.获取消息的重试次数，判断其是否超过设定的预定上限次数，若是，则执行步骤S7，否则，将消息投递到第二交换，第二交换的路由匙等于消息对应的第一队列的队列名字；

S6.第二队列在执行延时设定后，重新将消息投递到队列名字为消息对应路由匙的第一队列中；

S7.将消息投递给第三交换的第三队列待人工处理。

通过上述方法，可以自动将处理失败的消息分离出来，在不影响整个进程执行的基础上，保证消息处理的可靠性。本方法通过设定重试次数，可以避免无法处理的消息长期占用系统资源，同时平衡消息重试成功了和系统开销，大幅提高客户端对消息的处理能力。

进一步的，上述人工处理后，还包括：

S8.待人工介入处理第三队列中的消息后，重新将消息投递到第一队列,即可将消息重新消费。

将消息投递到第一队列而非第一交换，可以避免造成部分队列消息的重复消费。

进一步的，上述S6中的延时设定具体为：等待消息过期。

因消息自身会携带时间信息，通过判断消息的时间是否过期的方式即可实现延时，较设定计时器的方式，可以降低延时机制的复杂度，提高运行的稳定性。同时，针对不同的消息，也便于设定对应的延时时间，使得方法对消息的重试具有针对性，提高了方法的灵活度。

进一步的，上述消息的过期时间设定点为：在S5中将消息投递到第二交换前设定。

进一步的，上述过期时间等于当前重试间隔。

进一步的，上述S7中，将消息投递给第三交换的第三队列时或之后，触发报警机制，以通知相关责任人进行人工处理。报警机制的设定，对于消息重试的执行具有极高的及时性，尤其适用于具有高时效性要求的场景。

进一步的，上述S6具体为：第二队列在执行延时设定后，将消息投递到默认交换，默认交换再将消息重新投递到队列名字为消息附带路由匙的第一队列中。

综上所述，由于采用了上述技术方案，本发明的有益效果是：

1、本发明基于消息中转的方式，通过在主进程上设置分线程对消息进行重传的方式，可以保证主进程执行的效率，提高消息处理的完整性。

2、本发明的系统或方法中，可设置消息的重试次数，进而避免无法处理的消息一直占用系统资源，影响进程，也可以平衡消息处理的完整度和系统开销。所设置的人工介入处理可以确保消息的可靠消费。

3、本发明可以灵活地设置消息的重试间隔，提高了对于所重试消息的针对性和系统的灵活性。

4、本发明中，RabbitMQ的一个虚拟主机只需要一个重试交换和一个重试队列即可实现所有主队列的消息重试，降低维护成本。

附图说明

本发明将通过例子并参照附图的方式说明，其中：

图1是异步消息重试方法的流程图。

具体实施方式

本说明书中公开的所有特征，或公开的所有方法或过程中的步骤，除了互相排斥的特征和/或步骤以外，均可以以任何方式组合。

本说明书(包括任何附加权利要求、摘要)中公开的任一特征，除非特别叙述，均可被其他等效或具有类似目的的替代特征加以替换。即，除非特别叙述，每个特征只是一系列等效或类似特征中的一个例子而已。

实施例一

一种基于RabbitMQ的消息重试系统的构建方法，其包括以下步骤：

1、创建exchange(交换)：

work exchange(主交换)：主exchange，发布消息时发布到该exchange，根据业务需要创建多个。

retry exchange(重试交换)：重试exchange，消息处理异常时(最大重试次数以内)，将消息重新投递给该exchange，一个virtual host(虚拟主机)创建一个。

fail exchange(失败交换)：失败exchange，超过最大重试次数后，将消息投递给该exchange，为了保持业务隔离性，和work exchange保持一致。

所有的exchange声明都使用以下参数：

2、创建queue：

work queue：主队列，存放发布的消息。声明参数如下：

retry queue：重试队列，存放重试次数未到最大重试次数的消息。参数如下：

fail queue：失败队列，存放重试超过最大重试次数的消息，与work queue保持对应。参数如下：

3、绑定queue到exchange：

work queue：绑定到work exchange。

retry queue：绑定到retry exchange。routing-key(路由匙)为“#”，表示匹配所有的routing-key。

fail queue:绑定到fail exchange。routing-key与对应的work queue绑定时用的routing-key相同。

实施例二

本实施例公开了一种基于Rabbi tMQ的消息重试系统，其由上述实施例的基于Rabbi tMQ的消息重试系统的构建方法构建而成。

实施例三

如图1所示，本实施例公开了一种基于上述实施例的基于RabbitMQ的消息重试系统的异步消息重试方法，其包括以下步骤：

1.生产者发布消息到work exchange。

2.work exchange根据routing-key将消息分发到对应的消息队列。

3.多个消费者实际中同时对主队列中的消息进行消费。因此他们之间采用“竞争”的方式来争取消息的消费。

4.消息消费后，不管成功失败，消费者都要返回ACK消费确认给队列，避免消息重复投递。同时，如果处理成功则结束流程，否则进入重试阶段。

5.从消息的header(头文件)中获取重试次数x-retry-count(如果没有改参数则设置默认值0)，如果小于设定的最大重试次数(max-try-count)，则设置消息的过期时间(expiration)为当前重试间隔，并将header中的x-retry-count加1，然后将消息投递到retry exchange，routing-key等于消息对应的work queue的队列名字。

6.重试队列不需要消费者直接订阅，它会等待消息的有效时间过期后，重新将消息投递到x-dead-letter-exchange，我们在这里设置它为default exchange(默认交换)。default exchange会根据消息附带的routing-key(第5步中设置成等于work queue的队列名字)重新投递消息到队列名字等于routing-key的work queue中。这样就实现了延时后消息的重新消费。

7.如果重试次数超过设定的最大重试次数，则认为消息无法被处理，直接将消息投递给fail exchange的fail queue，这时候触发报警机制，以通知相关责任人处理。

8.等待人工介入处理后，重新将消息投递到work queue,注意不能投递到workexchange，因为可能会造成部分队列的消息重复消费。这样就可以重新消费了。

实施例四

本实施例公开了一种基于Rabbi tMQ的异步消息重试方法，其包括以下步骤：

1、创建exchange(交换)：

work exchange(主交换)：主exchange，发布消息时发布到该exchange，根据业务需要创建多个。

retry exchange(重试交换)：重试exchange，消息处理异常时(最大重试次数以内)，将消息重新投递给该exchange，一个virtual host(虚拟主机)创建一个。

fail exchange(失败交换)：失败exchange，超过最大重试次数后，将消息投递给该exchange，为了保持业务隔离性，和work exchange保持一致。

所有的exchange声明都使用以下参数：

2、创建queue：

work queue：主队列，存放发布的消息。声明参数如下：

retry queue：重试队列，存放重试次数未到最大重试次数的消息。参数如下：

fail queue：失败队列，存放重试超过最大重试次数的消息，与work queue保持对应。参数如下：

3、绑定queue到exchange：

work queue：绑定到work exchange。

retry queue：绑定到retry exchange。routing-key(路由匙，为消息传递的路由)为“#”，表示匹配所有的routing-key。

fail queue:绑定到fail exchange。routing-key与对应的work queue绑定时用的routing-key相同。

4、消息的处理流程如图1所示。说明如下：

1.生产者发布消息到work exchange。

2.work exchange根据routing-key将消息分发到对应的消息队列。

3.多个消费者实例同时对主队列中的消息进行消费。因此他们之间采用“竞争”的方式来争取消息的消费。

4.消息消费后，不管成功失败，消费者都要返回ACK消费确认给队列，避免消息重复投递。同时，如果处理成功则结束流程，否则进入重试阶段。

5.从消息的header(头文件)中获取重试次数x-retry-count(如果没有改参数则设置默认值0)，如果小于设定的最大重试次数(max-try-count)，则设置消息的过期时间(expiration)为当前重试间隔，并将header中的x-retry-count加1，然后将消息投递到retry exchange，routing-key等于消息对应的work queue的队列名字。

6.重试队列不需要消费者直接订阅，它会等待消息的有效时间过期后，重新将消息投递到x-dead-letter-exchange，我们在这里设置它为default exchange(默认交换)。default exchange会根据消息附带的routing-key(第5步中设置成等于work queue的队列名字)重新投递消息到队列名字等于routing-key的work queue中。这样就实现了延时后消息的重新消费。

7.如果重试次数超过设定的最大重试次数，则认为消息无法被处理，直接将消息投递给fail exchange的fail queue，这时候触发报警机制，以通知相关责任人处理。

8.等待人工介入处理后，重新将消息投递到work queue,注意不能投递到workexchange，因为可能会造成部分队列的消息重复消费。这样就可以重新消费了。

本发明并不局限于前述的具体实施方式。本发明扩展到任何在本说明书中披露的新特征或任何新的组合，以及披露的任一新的方法或过程的步骤或任何新的组合。

Claims (10)

1.一种基于RabbitMQ的消息重试系统的构建方法，其特征在于，包括以下步骤：

A.分别创建第一交换、第二交换和第三交换，其中，发布的消息投递到第一交换，处理异常的消息投递到第二交换，处理失败的消息投递到第三交换；

B.分别创建第一队列、第二队列和第三队列，其中，第一队列用于存放发布的消息，第二队列用于存放处理异常的消息，第三队列用于存放处理失败的消息；

C.将第一队列绑定到第一交换，将第二队列绑定到第二交换，设置第二队列匹配所有路由匙，将第三队列绑定到第三交换，设置第三队列的路由匙匹配于对应的第三队列。

2.如权利要求1所述的基于RabbitMQ的消息重试系统的构建方法，其特征在于，所述处理异常的消息是指重试次数未超过预定上限次数的消息，所述处理失败的消息是指重试次数超过所述预定上限次数的消息。

3.一种基于RabbitMQ的消息重试系统，其特征在于，其由如权利要求2所述的基于RabbitMQ的消息重试系统的构建方法构建而成。

4.一种基于权利要求3所述的基于RabbitMQ的消息重试系统的异步消息重试方法，其特征在于，其包括以下步骤：

S1.生产者发布消息到第一交换；

S2.所述第一交换根据路由匙将消息分发到对应的第一队列；

S3.消费者对所述第一队列中的消息进行消费；

S4.消息消费后，消费者向第一队列反馈处理成功与否，如果处理成功则结束流程，否则执行以下步骤；

S5.获取消息的重试次数，判断其是否超过设定的预定上限次数，若是，则执行步骤S7，否则，将消息投递到第二交换，第二交换的路由匙等于消息对应的第一队列的队列名字；

S6.第二队列在执行延时设定后，重新将消息投递到队列名字为消息对应路由匙的第一队列中；

S7.将消息投递给第三交换的第三队列待人工处理。

5.如权利要求4所述的异步消息重试方法，其特征在于，所述人工处理后，还包括：

S8.待人工介入处理第三队列中的消息后，重新将消息投递到第一队列,即可将消息重新消费。

6.如权利要求4或5所述的异步消息重试方法，其特征在于，所述S6中的延时设定具体为：等待消息过期。

7.如权利要求6所述的异步消息重试方法，其特征在于，所述消息的过期时间设定点为：在S5中将消息投递到第二交换前设定。

8.如权利要求7所述的异步消息重试方法，其特征在于，所述过期时间等于当前重试间隔。

9.如权利要求4、5、7、8之一所述的异步消息重试方法，其特征在于，所述S7中，将消息投递给第三交换的第三队列时或之后，触发报警机制，以通知相关责任人进行人工处理。

10.如权利要求4、5、7、8之一所述的异步消息重试方法，其特征在于，所述S6具体为：第二队列在执行延时设定后，将消息投递到默认交换，默认交换再将消息重新投递到队列名字为消息附带路由匙的第一队列中。