Rabbit MQ 的几个高级特性

1、Confirm 确认消息

 

1.1、理解 Confirm 消息确认机制

 

• 消息的确认，是指生产者投递消息后，如果 Broker 收到消息，则会给我们生产者一个应答。
• 生产者进行接收应答，用来确定这条消息是否正常的发送到 Broker,这种方式也是消息的可靠性投递的核心保障。

 

 

1.2、如何实现 Confirm 确认消息实现

 

• 第一步：在channel 上开启确认模式：channel.confirmSelect()
• 第二步：在 channel 上添加监听：addConfirmListener,监听成功和失败的返回结果，根据具体的结果对消息进行重新发送、或者记录日志等后续处理。

 

2、Return 消息机制

 

• 1. Return Listener 用于处理一些不可路由的消息。
• 2. 我们的消息生产者，通过指定一个Exchange 和 Routing Key , 把消息送达到某一个队列中去，然后我们的消费者监听队列，进行消费处理操作。
• 3. 但是在某些情况下，如果我们在发送消息的时候，当前的 exchange 不存在，或者指定的 Routing Key 路由不到，这个时候如果我们需要监听这种不可达的消息，就需要使用 Return Listener.

 

 

在基础 API 中有一个关键的配置项：

• Mandatory : 如果该配置为 true,则监听器会接收到路由不可达的消息，然后进行后续处理，如果为 false,那么 broker 端自动删除该消息！

---

3、消费端限流

 

3.1、什么是消费端限流

        假设有这个一个场景，首先我们的 RabbitMQ 服务器有上万条未处理的消息，我们随便打开一个消费者的客户端，就会有巨量的消息瞬间全部推送过来，但是我们的单个客户端无法同时处理这么多数据，很有可能导致该客户端服务器崩溃或线上故障等。

 

3.2、理解消费端限流

 

• RabbitMQ 提供了一种 qos(服务质量保证)功能，即在非自动确认消息的前提下，如果一定数目的消息（通过基于 consumer 或者 channel设置 Qos的值）未被确认前，不进行消费新的消息。

• void BasicQos(unit prefetchSize,ushort prefetchCount,bool global);

 

3.3、BasicQos 参数说明

 

参数说明：

• prefetchSize : 0
• prefetchCount : 会告诉 RabbitMQ 不要同时给一个消费者推送多于 N 个消息，即一旦有N个消息会没有 ack,则该 consumer 将 block掉，直到有消息 ack .
• global : true/false 是否将上面设置应用于 channel.简单点说，就是上面限流是 channel级别的还是consumer 级别。

 
注意：

• prefetchSize 和 global 这两项，rabbitMQ没有实现，暂且不研究。
• prefetch_count 在 no_ask = false 的情况下生效，即在自动应答的情况下这两个值是不生效的。

 

4、消费端ACK与重回队列

 

4.1、消费端的手工 ACK 和 NACK

 

• 消费端进行消费的时候，如果由于业务异常我们可以进行日志的记录，然后进行补偿。
• 如果由于服务器宕机等严重问题，那我们需要手工进行ACK保障消费端消费成功。
   

4.2、消费端的重回队列

 

• 消费端重回队列是为了对没有处理成功的消息，把消息重新回递给 Broker.
• 一般我们在实际应用中，都会关闭重回队列，也就是设置为 False.

 

5、TTL队列/消息

 

• TTl是Time To Live 的缩写，也就是生存时间。
• RabbitMQ 支持消息的过期时间，在消息发送时可以进行指定。
• RabbitMQ 支持队列的过期时间，从消息入队列开始计算，只要超过了队列的超时时间配置，那么消息会自动的清除。

 

6、死信队列

 

6.1、死信队列：DLX , Dead-Letter_Exchange

 
死信队列：DLX , Dead-Letter_Exchange

• 利用DLX,当消息在一个队列中变成死信（dead message）之后，它能被重新 publish 到另一个 Exchange,这个 Exchange 就是 DLX.
   

关于 DLX :

• DLX也是一个正常的Exchange,和一般的Exchange没有区别，它能在任何的队列上被指定，实际上就是设置某个队列的属性。
• 当这个队列中有死信时，RabbitMQ就会自动的将这个消息重新发布到设置的Exchange上去，进而被路由到另一个队列。
• 可以监听这个队列中消息做相应的处理，这个特性可以弥补 RabbitMQ 3.0 以前支持的immediate参数的功能。

 

6.2、消息变成死信有以下几种情况

 
消息变成死信有以下几种情况：

• 消息被拒绝（basic.reject/basic.nack）并且 requeue = false.
• 消息 TTL 过期。
• 队列达到最大长度。

 

6.3、死信队列设置

 
死信队列设置如下：

 

• 首先需要设置死信队列的exchange和queue,然后进行绑定：
  1、Exchange : dlx.exchange
  2、Queue : dlx.queue
  3、RoutingKey : #
• 然后我们进行正常声明交换机、队列、绑定，只不过我们需要在队列上加一个参数即可：arguments.put(“x-dead-letter-exchange”,“dlx.exchange”);
• 这样消息在过期、requeue、队列在达到最大长度时，消息就可以直接路由到死信队列。

 
 
 
 
 
 
 
 
 
 
 
.