RabbitMQ (三）高级特性 实现 死信队列 DLX TTL 消费端限流prefetch 消息可靠传递 confirm return 幂等性保障

本来想带过一下rabbit整合spring和spring-boot，我看网上很多相关文档，就没什么必要了，就来总结一下一些高级特性给自己看看。本章主要以理论为主，至于代码和使用，我在git上放了一套简单易懂的 例程。可以下载下来，在advance（高级）中，有延时队列可供参考。如过需要其学习rabbitMq其他简单使用可以阅读 RabbitMq (一）理论篇部分RabbitMQ（二）实践篇

---

前言

---

一、消息的可靠性传递

在使用RabbitMQ的时候，为了确保消息抵达Broker，Rabbit提供了两种方式供用户来控制消息投递的可靠性模式

• confirm 确认模式
• return 退回模式

RabbitMQ消息的整个投递过程：

• confirm 是判断消息是否被 exchange 收到。
• return 是消息被 exchange 收到，但是没有队列可以投递。

使用步骤大体是模式开启，写一下回调函数。做法不同的架构写的不太一样，但意思都是一样的，如果你发现你写的监听不起作用，八成就是模式没开启。

二、消息的可靠性接收

上面讲的可靠性传递，只是确定到了queue，那还需要确定消息到达消费端。

有三种确认方式：

• 自动确认 ： acknowledge = “none”
  消息一旦被Consumer收到，则自动确认签收，并将相应的message从rabbitmq的消息缓存中移除。
• 手动确认 ： acknowledge = “manual”
  实际业务处理可能会出现异常，可以设置手动签收，如果正常处理chanel.basicAck()正常签收，若发生异常chanel.basicNack()拒绝签收，让消息重新发送。
• 根据异常情况确认 ： acknowledge = “auto”
  

三、消费端限流

如果请求瞬间增多，超过最大处理请求，会导致系统奔溃。加以限制，让系统慢慢处理，就可以缓解请求突增的情况。

配置

四、TTL

TTL全称Time To Live（存活时间、过期时间），当消息到达存活时间后，还没有被消费，会自动被删除。

• 可以对消息设置时间，也可以对整个队列设置时间
• 设置队列过期时间参数：x-message-ttl,单位ms，会对整个队列生效。
• 设置消息过期使用参数：expriration。单位ms，当该消息在队列头部时，会单独判断该消息是否过期。
• 如果两者都设置了，则以时间较短的为准。

五、死信队列

DLX（dead letter exchange 死信交换机），当一个消息成为 dead message 后，可被重新发送到另一交换机，这个交换机就是DLX

什么情况下消息会成为死信：

• 队列消息长度达到限制
• 消费者拒绝消费消息，basicNack/basicReject，并且不把消息重新放入原目标队列，requeue=false
• 原队列存在消息过期设置，消息到达超时时间，未被消费；

六、延时队列

消息进入队列后不会立即被消费 ，等待达到时间后被消费。很可惜，RabbitMQ没有提供延时队列功能，但是可以使用TTL+死信队列组合实现延时队列效果

七、幂等性保障

一次或多次请求某一个资源，对于资源本身应该具有同一个效果。在MQ中，指消费同一条消息多次，得到消费该消息一次相同效果。

通过version版本控制