RabbitMQ 发布订阅-实现延时重试队列(参考)
RabbitMQ消息处理失败,我们会让失败消息进入重试队列等待执行,因为在重试队列距离真正执行还需要定义的时间间隔,因此,我们可以将重试队列设置成延时处理。今天参考网上其他人的实现,简单梳理下消息延时重试执行的思路。
消费失败后,自动延时将消息重新投递,当达到一定的重试次数后,将消息投递到失败消息队列,等待人工介入处理。在这里我们一步一步实现一个带有失败重试功能的发布订阅组件,使用该组件后可以非常简单的实现消息的发布订阅。
业务背景
- 结合RabbitMQ的Topic模式和Work Queue模式实现生产方产生消息,消费方按需订阅,消息投递到消费方的队列之后,多个worker同时对消息进行消费
- 结合RabbitMQ的 Message TTL 和 Dead Letter Exchange 实现消息的延时重试功能
- 消息达到最大重试次数之后,将其投递到失败队列,等待人工介入处理bug后,重新将其加入队列消费
执行流程图
- 生产者发布消息到主Exchange
- 主Exchange根据Routing Key将消息分发到对应的消息队列
- 多个消费者的worker进程同时对队列中的消息进行消费,因此它们之间采用“竞争”的方式来争取消息的消费
- 消息消费后,不管成功失败,都要返回ACK消费确认消息给队列,避免消息消费确认机制导致重复投递,同时,如果消息处理成功,则结束流程,否则进入重试阶段
- 如果重试次数小于设定的最大重试次数(默认为3次),则将消息重新投递到Retry Exchange的重试队列
- 重试队列不需要消费者直接订阅,它会等待消息的有效时间过期之后,重新将消息投递给Dead Letter Exchange,我们在这里将其设置为主Exchange,实现延时后重新投递消息,这样消费者就可以重新消费消息
- 如果三次以上都是消费失败,则认为消息无法被处理,直接将消息投递给Failed Exchange的Failed Queue,这时候应用可以触发报警机制,以通知相关责任人处理
- 等待人工介入处理(解决bug)之后,重新将消息投递到主Exchange,这样就可以重新消费了
技术实现:
创建Exchange
为了实现消息的延时重试和失败存储,我们需要创建三个Exchange来处理消息。
- master 主Exchange,发布消息时发布到该Exchange
- master.retry 重试Exchange,消息处理失败时(3次以内),将消息重新投递给该Exchange
- master.failed 失败Exchange,超过三次重试失败后,消息投递到该Exchange
所有的Exchange声明(declare)必须使用以下参数
参数 | 值 | 说明 |
---|---|---|
exchange | - | Exchange名称 |
type | topic | Exchange 类型 |
passive | false | 如果Exchange已经存在,则返回成功,不存在则创建 |
durable | true | 持久化存储Exchange,这里仅仅是Exchange本身持久化,消息和队列需要单独指定其持久化 |
no-wait | false | 该方法需要应答确认 |
在RabbitMQ的管理界面中,我们可以看到创建的三个Exchange
消息发布
消息发布时,使用basic_publish
方法,参数如下
参数 | 值 | 说明 |
---|---|---|
message | - | 发布的消息对象 |
exchange | master | 消息发布到的Exchange |
routing-key | - | 路由KEY,用于标识消息类型 |
mandatory | false | 是否强制路由,指定了该选项后,如果没有订阅该消息,则会返回路由不可达错误 |
immediate | false | 指定了当消息无法直接路由给消费者时如何处理 |
发布消息时,对于message
对象,其内容使用json编码后的字符串,同时消息进行持久化
消息订阅
消息订阅的实现相对复杂一些,需要完成队列的声明以及队列和Exchange的绑定
Declare Queue
对于每一个订阅消息的服务,都必须创建一个该服务对应的队列,将该队列绑定到关注的路由规则,这样之后,消息生产者将消息投递给Exchange之后,就会按照路由规则将消息分发到对应的队列供消费者消费了。
消费服务需要declare三个队列
[queue_name]
队列名称,格式符合[服务名称]@订阅服务标识
[queue_name]@retry
重试队列[queue_name]@failed
失败队列
Declare队列时,参数规定规则如下
参数 | 值 | 说明 |
---|---|---|
queue | - | 队列名称 |
passive | false | 队列不存在则创建,存在则直接成功 |
durable | true | 队列持久化 |
exclusive | false | 排他,指定该选项为true则队列只对当前连接有效,连接断开后自动删除 |
no-wait | false | 该方法需要应答确认 |
auto-delete | false | 当不再使用时,是否自动删除 |
对于@retry
重试队列,需要指定额外参数
'x-dead-letter-exchange' => 'master'
'x-dead-letter-routing-key' => [queue_name],
'x-message-ttl' => 30 * 1000 // 重试时间设置为30s
这里的两个header字段的含义是,在队列中延迟30s后,将该消息重新投递到x-dead-letter-exchange
对应的Exchange中,并且routing key指定为消费队列的名称,这样就可以实现消息只投递给原始出错时的队列,避免消息重新投递给所有关注当前routing key的消费者了。
在RabbitMQ的管理界面中,Queues部分可以看到我们创建的三个队列
查看队列的详细信息,我们可以看到 queueName@retry 队列与其它两个队列的不同
队列和Exchange绑定
创建完队列之后,需要将队列与Exchange绑定(bind
),不同队列需要绑定到之前创建的对应的Exchange上面
Queue | Exchange |
---|---|
[queue_name] | master |
[queue_name]@retry | master.retry |
[queue_name]@failed | master.failed |
绑定时,需要提供订阅的路由KEY,该路由KEY与消息发布时的路由KEY对应,区别是这里可以使用通配符同时订阅多种类型的消息。
参数 | 值 | 说明 |
---|---|---|
queue | - | 绑定的队列 |
exchange | - | 绑定的Exchange |
routing-key | - | 订阅的消息路由规则 |
no-wait | false | 该方法需要应答确认 |
在RabbitMQ的管理界面中,我们可以看到该队列与Exchange和routing-key的绑定关系
消息消费实现
使用 basic_consume
对消息进行消费的时候,需要注意下面参数
参数 | 值 | 说明 |
---|---|---|
queue | - | 消费的队列名称 |
consumer-tag | - | 消费者标识,留空即可 |
no_local | false | 如果设置了该字段,服务器将不会发布消息到 发布它的客户端 |
no_ack | false | 需要消费确认应答 |
exclusive | false | 排他访问,设置后只允许当前消费者访问该队列 |
nowait | false | 该方法需要应答确认 |
消费端在消费消息时,需要从消息中获取消息被消费的次数,以此判断该消息处理失败时重试还是发送到失败队列。
在消息发送到重试队列和失败队列时,我们在消息的headers中添加了一个名为x-orig-routing-key
的字段,该字段是实现消息重试的关键字段,由于我们的消息需要在不同的Exchange,Queue之间流转,为了避免消息在重新投递到主Exchange时,被所有的消费者队列重新消费,在重试过程中,我们将消息的routing-key修改为队列名称,直接投递给原始消费消息的队列。x-orig-routing-key
用于在之后能够重新获取到最开始的routing-key。
这里的重复消费是指 某个消息被两个消费方A和B消费了,其中A消费失败,B成功,这时候,消息由A消费者重新投递到主Exchange后,B消费队列也会获取到该消息,因此就会导致B消费者重复消费已经消费国的消息
本文实现延时重试,使用了三个重试Exchange,Exchange如果订阅特别多的话,Exchange的压力会非常大,因此在非常极端的情况下,消息大批量失败,且消息收发非常快,那么Exchange的性能可能会有问题。
本文是使用发布订阅实现延时重试的消息执行,也会有其他思路。