RabbitMQ-下-高级特性

RabbitMQ 高级特性

1 消息的可靠投递

概述

1.1 生产者层面 Producer====>Exchange

针对Producer===》Exchange
confirm模式
对Producer端发送消息的时候设置一个confirmCallback的监听，到达或者不到达MQ服务中间件Exchange，监听confirmCallback都会被执行。如果Exchange成功收到消息返回true,反着为false.也就是说不管消息有没有到达Exchange都会执行监听方法。
步骤：

生产者

• 1:
  
• 2

失败后:再去做一些重发的处理。。。。

注意：CorrelationData correlationData = new CorrelationData();

《 correlationData这个对象的使用》
回调函数中confirm中的三个参数详解

1.2 生产者层面 Exchange ====》Queue

针对Exchange===>Queue
return模式
Exchange将消息路由到Queue失败了才会执行returnCallback。
步骤：

生产者：

• 1
• 2
  
  失败后:再去做一些重发的处理或者落地的处理

returnedMessage()参数解释

1.3 消费者层面

消费者：
针对Queue===>Consumer
消费者确认机制，队列发消息给消费者，消费者进行处理，回调信息，如果处理成功就把消息从队列中移除，如果失败就在重新发一次。

该消息被拒绝 而且重回队列 排队到末尾在执行 这可以叫死信消息
RabbitMQ默认是丢弃

消费者没有返回ACK/NACK 则消息状态是unacked
消费者重启在继续消费 或者新的消费者加入消费

Consumer Ack

概念

三种确认方式

步骤：

• 1
  
• 2
  
• 3
  
  测试：
  

1.4 中间件

• 1.对交换机持久化
• 2.队列持久化
• 3.消息持久化
• 4.broker高可用

2 消费端限流

步骤：

• 1
  
• 2
  
  生产者发10条消息 消费端每次从MQ拉去一条消息来消费，直到手动确认消费完毕后，才继续拉去下一条

注意：官网解释perfetch：当前消费者channel允许的最大未确认消息个数


在channel中处理了一条就塞一条

3 TTL （过期时间&存活时间）

我们可以在RabbitMQ中的队列消息设置过期时间，然后这个过期时间到了会变成死信消息，死信消息默认是丢弃。

• Time To Live
• 当消息到达存活时间后，还没有被消费，就会被自动清除
• 可以对 整个队列 或 单个消息 进行设置过期消息
  

RabbitMQ 管控台

创建队列

创建交换机

点进交换机 绑定队列


发送消息

结果：10s后会自动删除

JAVA编码设置：

设置1.队列过期时间

队列设定的时间：消息进入队列的时间 加你设定的过期时间的时间点才会过期
比如 第一条是13:10:10 +10s 那就13:10:20才会过期

设置2.消息单独过期

设置了队列过期 在设置消息过期 messagePostProcessor 消息的后处理对象的使用

注意： 设置了队列 又设置了消息 消息过期 但不会马上消失 只有到了顶端才会被消费。

死信队列（DLX）

Dead Letter Exchange(死信交换机)，当消息成为Dead Message后 要丢弃的时候，也可以重新发送到另一个交换机，这个交换机叫做DLX 死信交换机

提问回答：
1消息在什么情况下会成为死信：

• 1:队列消息长度到达限制
• 2:消费者拒绝消息，basicNack/basicReject,并且不把消息重新放入原目标队列。
• 3:原队列存在消息过期设置，消息到达超时时间没有被消费
• 2如何给队列绑定死信交换机：
  
  步骤图解：
  

设置队列过期时间和消息长度限制

测试结论：
第三种要注意 我制造了个消费者 然后自己消费发生错误 但不重回队列 丢弃 就成死信消息

延迟消息（TTL+DLX）

延迟队列，就是消息进入队列后不会立即消费，只有到达指定时间才会消费。

运用：

业务图解

TTL+DLX

代码演示：
订单系统1： 设置正常的交换机+绑定死信交换机+和死信路由Key

2

测试 发送消息
消费者：完成一些列的了逻辑，万变不离其中

日志与监控

命令（了解下就行了）

消息追踪

• 1： Firehose
  

管控台


随便往哪个队列发送消息 都会同步 如果开启RabbitMQ性能会下降

RabbitMQ应用型问题（思路）

1.消息可靠性保障

消息补偿机制

2.消息幂等信性保障 （确保有幂等性）

消费者拒绝消息 重回队列 重发机制可能也会重复消费 对我整个业务 和结果没有影响

1 针对于update方法乐观锁解决方案

2 删除delete幂等性要求 也有可能需要

3 insert 存在幂等性 在id字段添加唯一约束

4 业务上也可以做些判断 还是要根据实际业务出发

RabbitMQ 集群搭建&HAProxy

HAProxy 反向代理 高可用 负载均衡 需要自己安装 （单机多实例 成为伪集群） 根据文档搭建 需要的可以找我