4.RabbitMQ高级特性

RabbitMQ

一、高级特性

消息的可靠性

• exchange confirm
• 回退
• consumer ack

消费端限流

• 自动确认设置为手动，设置每次消费10的步长

TTL(TimeToLive)

• RabbitMQ过期队列和过期消息处理机制：

  • 1.当队列和队列当中的消息(1条消息)都设置了过期时间，以时间短的为准

  • 2.当队列存在多条消息时，且存在设置了过期时间的消息，RabbitMQ是怎么处理的呢？

    • 1.并不是以时间短的消息为准删除所有消息❎
    • 2.RabbitMQ是将该队列中的消息逐个进行消费，当发现过期的消息，将其删除✅，节省ARM

• 在queue定义中添加实例：

死信队列DLX

• 什么是死信队列

  • 消息成为Dead message后被重新发送到另一个交换，这个交换机被就是DLX

• 死信队列图解

  • 

• 成为死信队列的条件有哪些

  • 超时未被消费：x-message-ttl
  • 超长:x-max-length;x-max-length-bytes
  • 被消费者拒绝签收basicNack，并且requeue=”false“

延迟队列(TTL+DLX)

• 延迟队列图解：

  • 

• 延迟队列应用场景

  • 1、下单成功在规定时间内未进行付款取消订单
  • 2、成功注册账号在七天之后发短信问候

• 延迟队列的使用

  • 1.定义正常队列，交换机并绑定
  • 2.定义死信队列、死信交换机并绑定
  • 3.设置正常队列的x-message-ttl，x-dead-letter-exchange，也可以设置x-dead-letter-routing-key
  • 4.consumer编写Listener类(implements ChannelAwareMessageListener) 重写onMessage(Message message,Channel channel)方法，在xml文件中设置rabbitMQ监听类，监听的对列是死信队列
  • 4.启动consumer测试，producer测试向正常队列发送message

二、日志监控

RabbitMQ默认日志存放路径：/var/log/rabbitmq/rabbit@xxx.log

日志包含的内容：日志包含了RabbitMQ的版本号、Erlang的版本号、RabbitMQ服务节点名称、cookie的hash值、RabbitMQ配置文件地址、内存限制、磁盘限制、默认账户guest的创建以及权限配置等等。

RabbitMQ常用的命令操作

• 查看队列：rabbitmqctl list_queues
• 查看exchange：rabbitmqctl list_exchanges
• 查看用户：rabbitmqctl list_users
• 查看连接：rabbitmqctl list_connections
• 查看消费者信息：rabbitmqctl list_consumers
• 查看环境：rabbitmqctl environment
• 查看未被确认的队列：rabbitmqctl list_queues name messages_unacknowledged
• 查看单个队列的内存使用情况：rabbitmqctl list_queues name memory
• 查看准备就绪的队列：rabbitmqctl list_queues name messages_ready

三、消息追踪（了解）

Firehouse

rabbitmq_tracing

消息追踪的方式

• 1.Firehouse

  • 机制：friehouse是将发送给consumer的消息投递给默认交换机（amq.rabbitmq.trace topic型），发送到这个交换机的消息routingKey为public.exchange和deliver.queuename。其中exchangename和queuename为实际exchange和queue的名称，分别对应生产者投递到exchange的消息，和消费者从queue上获取的消息。
  • 开启Firehouse命令：rabbitmqctl trace_on
  • 关闭Firehouse命令：rabbitmqctl trace_off
  • 注意：打开Firehouse会影响消息的写入功能，适当打开后请关闭

• 2.rabbitmq_tracing

  • 机制：通透Firehouse是一样的，只是通过插件可以进行可视化，方便管理
  • 启动插件命令：rabbitmq-plugins enable rabbitmq_tracing

为什么要进行消息追踪

• 1.某条消息异常丢失
• 2.producer获取consumer与RabbitMQ断开连接
• 3.中间件与RabbitMQ采用了同的确认机制
• 4.中间件与RabbitMQ采用了不同的转发策略
• 5.或者交换机没有与任何队列进行绑定，并且生产者不感知或者不进行相应的措施
• 6.RabbitMQ集群策略本身导致的消息丢失

四、应用问题

1.消息可靠性保障

• 消息补偿机制的目的是确保消息100%发送成功

• 消息补偿机制是目前大型企业用于解决高并发，确保消息可靠性的主流方案，面试题会问怎么设计怎么实现的

• 消息补偿机制具体流程图&解释：

  • 

  • 流程解释：

    • 正常流程：

      • producer发送业务Q1给consumer，同时业务入producer库发送延迟消息Q3给回调服务；消费者成功消费入consumer库，发送确认消息Q2给回调服务将业务消费id写入MDB，Q3到达时会与MDB中的消费id进行比对是否一致，一致说明成功，回调服务不进行操作

    • 出现异常的流程：

      • Q1失败：回调服务会拿到Q3的id与MDB进行比对，未发现消费id会进行调用producer重新发送
      • Q1和Q3都失败：定时检查服务会查看MDB和业务DB,看两个数据 库中id消息是否匹配，Q1和Q3未发送出去，MDB数据是比DB数据库中业务多的，这是定时检查服务会调用producer重新发送

  • 总结：简单的回答消息补偿机制是怎么实现的，就是将消息写入数据库中，对比前后id是否缺少一致，最后的的保障是定时检查服务

2.消息的幂等性保障

• 什么是消息的幂等性保障：

  • 幂等性保障就是一次或者多次请求同一个资源，对资源本身应该具有相同的结果，在MQ中指，消费多条相同的消息，得到与消费该消息一次相同的结果。

• 幂等性保障措施–乐观锁机制流程图&解释：

  • 

  • 流程解释：

    • 当发送一条消费消息给consumer，这条消息会携带id和version号，当这条消息被消费过后会将version进行+1 操作，当由于其他原因这条id=1&version=1的消息从producer再次发送到consumer时，无法再次消费，因为version已经发生变化，不管producer发送多少次都不会再次别consumer消费

五、集群搭建（了解，用到时查文档）

RabbitMQ的高可用集群

• 图解：

  • 

• HAProxy解释：

  • High availability proxy 高可用代理

• 集群搭建文档

  • [RabbitMQ器群搭建文档]