RabbitMq入门

学习RabbitMq所做的笔记

学习来源——黑马程序员RabbitMQ入门到实战教程，MQ消息中间件，微服务rabbitmq消息队列实战，rabbitmq面试题一套全覆盖_哔哩哔哩_bilibili

 3、Mq技术选型

5、数据隔离

在RabbitMq中有虚拟主机的概念，默认是"\"，队列以及交换机都会属于一个虚拟主机

6、Spring AMQP

官方地址：Spring AMQP

Spring AMQP是基于AMQP协议定义的一套API规范，提供了模板来发送和接收消息。包含两部分。其中spring-amqp是抽象，spring-rabbit是底层默认实现。

引入依赖

配置文件

发送消息

首先，需要注入Bean —— RabbitMqTemplate，然后发送消息

消费消息

作为消费者，首先需要交给Spring管理，例如使用 @Component注解，其次，在方法上加上@RabbitListener注解，并指明监听的队列

7、work模型

• 一个队列可以绑定多个消费者
• 队列中的消息只能被消费一次
• 可以通过prefetch配置控制消费者的拉取速度

案例

 发送消息

消费消息

结果

消费者1，消费者2各消费25条消息

结论一

像队列发送消息时，若消费者有多个，消息只会被消费一次

结论二

若队列有多个消费者，队列会将消息以轮询的方式给消费者

 案例修改

 修改消费者的处理速度

结果

消费者1和消费者2仍然消费25个

消费者消息推送限制

 加上该参数后，保证消费者将拉取的消息消费完才会从队列拉取消息

 8、Fanout（广播 ）交换机

Fanout交换机会将消息广播到每一个队列，可以达到一个消息多次消费的功能

案例

 1、添加交换机

添加交换机时要指定交换机的类型，名称最好也起一个见名知意的

2、绑定队列

绑定两个队列，分别叫fanout.queue1、fanout.queue2

3、消费者

 4、生产者

结果

可以看到两个队列都能收到

9、Direct交换机

Direct交换机会叫消息发送到指定的队列，Direct相比Fanout更加灵活，也可以实现Fantou交换机的效果

• 每一个Queue会与交换机有一个BindingKey
• 发送消息时，指定消息的RoutingKey
• 交换机会将消息发送给BingdingKey与Routing匹配的队列上

案例

 消费者

生产者

 

结果

可以看到，red RoutingKey的消息，两个队列都能收到 ，而blue RoutingKey的消息，只有队列1会收到

10、Topic交换机

Topic交换机与Direct交换机类似，区别于Topic交换机下的RoutingKey可以是多个单词的列表，中间用‘.’分隔。

Queue于交换机绑定时的BingingKey可以带通配符。

• #：0个或多个单词
• *：一个单词 

RoutingKey 有 A.a、A.b、A.c.q、A.d.q

BindingKey 有A.#、A.*

使用A.#的队列，可以接收上面四种RoutingKey的消息，而A.*的队列只能接收 A.a、A.b的消息

使用Diect交换机，但没有Topic方便，并且若再加一个RoutingKey，例如A.f，那么在Direct交换机下，还要去修改队列的BindingKey

案例

再上述需求中，队列1的BindingKey时China.#，队列2的BingKey时#.news

消费则

生产者

预期只有消费者2能收到

 预期消费者1、消费者2都能收到消息

预期只有消费者1能收到

11、使用代码声明交换机于队列

案例

 需要注意的是，在创建Binding时，需要用到前面声明的交换机于队列，我们利用Spring的自动注入可以实现，但需要注意Bean的名称和参数名称一致。

通过Bean的方式进行声明比较麻烦，还利用注解进行绑定

12、消息转换器

 

 发送完后去控制台，会发现默认使用的Java序列化方式进行序列化的，序列化后的内容比较大、可读性查、且具有安全问题。

改成Json序列化

13、生产者重连

14、生产者确认

代码实现

配置文件

 代码实现

Return 确认机制

Confirm 确认机制

测试

注意：在单元测试里，一旦代码执行完毕，程序也就停止，异步回调可能就接收不到，可以在最后加个 Thread.sleep() 来等待回调的执行。

总结

15、数据持久化

当Mq本身宕机的时候，再次将它重启，原本存在内存的数据就会丢失，为了防止这种情况需要进行持久化。此外，内存的资源是比较有限的，当发送的消息非常多的时候，内存也会不够用，导致消息阻塞

案例

 向RabbitMq发送1000000条消息，观看阻塞状态。注意，这个时候需要将生产者确认机制关闭，提高发送速度

 观看控制台可以发现，有一段时间消息处理速度为0，说明这段时间在进行page out操作，导致Mq业务阻塞

 交换机持久化

队列持久化

 消息持久化

Spring AMQP下，发送的消息默认就是持久化的

Lazy Queue

 Lazy Queue也可以解决数据持久解决的问题，并且Lazy Queue在写入数据做了优化，性能更佳，推荐使用

16、消费者确认

Spring Boot会自动对我们的RabbitMq监听器进行代理，业务正常会自动返回ack

 17、消息失败处理

配置以上参数后，就可设置失败重试次数，当多次重试都失败后，默认会直接丢弃消息

失败消息处理策略

RepublishMessageRecoverer策略

1、定义交换机与队列

2、定义 RepublishMessageRecoverer

由于该配置只需在消息消费确认机制开启后才需要生效，故可以加个注解（截图中 name 后面的单词错了，应该是 enabled）

3、消费者监听器

可以看到消费者故意抛出了异常，所以肯定会返回nack。进行测试，去控制台 error.queue队列 看效果

 18、业务幂等性

在消息队列中，对于消息消费的业务，也要进行幂等性的保证

唯一ID

 该方案下，需要多出插入数据、读取数据的操作，对原本的方案有侵入，且有性能影响

业务判断

根据业务状态进行判断，通常情况下状态的改变具有单向性时可以使用，当状态已经改变后，例如从未支付->已支付，再去修改状态自然无效了。

总结

19、延迟消息

延迟消息：生产者发送消息时指定一个时间，消费者不会立刻收到消息，而是在指定时间后才会收到消息

20、死性交换机

利用死性交换机发送延迟消息

使用死性交换机实现延迟消息比较麻烦，需要一组正确的交换机和对了，还需要一组死性交换机和一个队列。

生产者要先把消息发给正常的交换机，并且消息要设置过期时间，当时间一到，消息就会被发送到死性交换机，然后就会发送到队列中，最后由消费者消费，达到延迟消息的效果。

21、延迟消息插件

插件下载

Releases · rabbitmq/rabbitmq-delayed-message-exchange · GitHub

将插件拷贝到容器中

格式：docker cp 本地文件路径 counterID全称:容器路径

docker cp rabbitmq_delayed_message_exchange-3.8.9-0199d11c.ez 9ca420db0ffd:/plugins

启动插件

首先进入容器 docker exec -it myRabbitMQ /bin/bash

然后进入插件目录 cd /plugins

启动插件 rabbitmq-plugins enable rabbitmq_delayed_message_exchange

结果如下

消费者

生产者

22、超时订单思路