消息的可靠性保证

  • 发送方保证：
  • 需要使用RabbitMQ发送端确认机制，确认消息成功发送到RabbitMQ并被处理；
  • 需要使用RabbitMQ消息返回机制，若没发现目标队列，中间件会通知发送方；
  • 消费方
  • 需要使用RabbitMQ消费端确认机制，确认消息没有发生处理异常；
  • 需要使用RabbitMQ消费端限流机制，限制消息推送速度，保障接收端服务稳定；
  • RabbitMQ自身
  • 大量堆积的消息会给RabbitMQ产生很大的压力，需要使用RabbitMQ消息过期时间，防止消息大量积压；
  • 过期后会直接被丢弃，无法对系统运行异常发出警报，需要使用RabbitMQ死信队列，收集过期消息，以供分析；

发送端确认机制

解决的问题：消息真的发出去了吗？

  • 消息发送后，若中间件收到消息，会给发送端一个应答；
  • 生产者接收应答， 用来确认这条消息是否正常发送到中间件；
三种确认机制
  • 单条同步确认；
  • 配置channel，开启确认模式： channel.confirmSelect();
  • 每发送一条消息，调用channel.wairForConfirms()方法， 等待确认；
  • 多条同步确认（不推荐）；
  • 配置channel，开启确认模式： channel.confirmSelect();
  • 发送多条消息后，调用channel.wairForConfirms()方法，等待确认；
  • 异步确认：
  • 配置channel，开启确认模式： channel.confirmSelect();
  • 在channel上配置监听：addConfirmListener，发送消息后，会回调此方法，通知是否发送成功;
  • 异步确认有可能是单条，有可能是多条，取决于MQ；

消息返回机制

问题：消息真的被路由了么？

  • 消息发送后，中间件会对消息进行路由；
  • 若没有发现目标队列，中间件会通知发送方；
  • Return Lisener会被调用；
消息返回的开启方法
  • 在RabbitMQ基础配置中有一个关键配置项：Mandatory;
  • Mandatory若为false，RabbitMQ将直接丢弃无法路由的消息；
  • Mandatory若为true，RabbitMQ才会处理无法路由的消息；

消费端确认机制

  • 默认情况下，消费端接收消息时候，消息会被自动确认（ACK）;
消费端ACK类型
  • 自动ACK: 消费端收到消息后， 会自动签收消息；
  • 手动ACK: 消费端收到消息后，不会自动签收消息，需要在业务代码中显式签收消息；
  • 单条手动ACK: multiple = false；（推荐）
  • 多条手动ACK: multiple = true；
重回队列
  • 若设置了重回队列，消息被NACK之后，会返回队列末尾，等待进一步被处理；
  • 不建议开启重回队列；

消费端限流机制

背景：

  • 业务高峰期，可能出现发送端和接收端性能不一致，大量消息会被同时推到接收端，造成接收端服务崩溃；
  • 需要使用RabbitMQ消费端限流机制，限制消息推送速度，保障接收端服务稳定；
RabbitMQ-Qos服务质量保障
  • Qos功能保证了在一定数目的消息未被确认前，不消费新的消息；
  • Qos功能的前提是不使用自动确认,使用手动确认；

原理：

QoS原理是当消费端有一定数量的消息未被ACK确认时，RabbitMQ不会给消费端推送新的消息；
RabbitMQ正是使用了QoS机制实现了消费端限流；

消费端参数限制
  • prefetchCount：针对一个消费端最多推送多少未确认消息；
  • global: true,针对整个消费端限流，false：针对当前channel；
  • prefetchSize：0（单个消息大小限制，一般为0）；

针对prefetchSzie与global两项，RabbitMQ暂时未实现；

消息过期机制

  • 默认情况下，消息进入队列，会永远存在，直到被消费；
  • 大量堆积的消息会给mq造成很大压力；
  • 需要使用RabbitMQ消息过期时间，防止消息大量积压；
RabbitMQ的过期时间（TTL）
  • RabbitMQ的过期时间被称为TTL（Time to Live），生存时间；
  • RabbitMQ的过期时间分为消息TTL和队列TTL；
  • 消息TTL：设置了单条消息的过期时间；
  • 队列TTL：设置了队列中所有消息的过期时间；
如何找到自己的TTL
  • TTL的设置主要考虑技术架构与业务；
  • TTL应该明显长于服务的平均重启时间；
  • TTL长于业务高峰时间；

RabbitMQ的死信队列

对于过期消息：

  • 消息被设置了过期时间，过期后是会被直接丢弃的；
  • 直接被丢弃的消息，无法对系统运行异常发出警报；
  • 需要使用RabbitMQ死信队列，收集过期消息，以供分析；
什么是死信队列？
  • 死信队列：队列被配置了DLX属性（Dead-Letter-Exchange）；
  • 当一个消息变成死信（dead message）后，能重新被发布到另一个Exchange，这个Exchange也是一个普通交换机；
  • 死信被死信交换机路由之后，一般进入一个固定的队列；
怎样会变成死信
  • 消息被拒绝（reject/nack），并且requeue=false；
  • 消息过期（TTL到期）；
  • 队列达到最大长度；
死信队列设置方法
  • 设置转发、接收死信的交换机和队列：
  • Exchange：dlx.exchange
  • Queue: dlx.queue
  • RoutingKey: #
  • 在需要设置死信的队列加入参数：
  • x-dead-letter-exchange = dlx.exchange