rabbitmq笔记

环境构建

1. 拉取镜像

docker pull rabbitmq:3.8.19-management
1

2. 创建网络

docker network create app-tier --driver bridge
1

3. 使用docker命令启动rabbitmq

docker run \
-e RABBITMQ_DEFAULT_USER=chenmin \
-e RABBITMQ_DEFAULT_PASS=cm021035 \
-v mq-plugins:/plugins \
--name mq \
--hostname mq \
--network app-tier \
-p 15672:15672 \
-p 5672:5672 \
-d \
rabbitmq:3.8.19-management
1
2
3
4
5
6
7
8
9
10
11

4. 进入容器

docker exec -it mq /bin/bash
1

5. 输入IP地址进入到rabbitmq界面，地址为：http://ip:15672

rabbitmq使用

1. 保证消息的可靠性

   1. 发送者的可靠性
      1.重连机制
      2.生产者确认
      1.publisher-confirm-type:none,simple,correlated

   2. MQ的可靠性
      1.一旦MQ宕机，内存中的消息会丢失
      2.内存空间有限，当消费者故障或处理过慢时，会导致消息积压，引发MQ阻塞
      解决问题：

       1. 数据持久化
       	1. 交换机持久化
       	2. 队列持久化
       	3. 消息持久化
      
       2. 惰性队列
       	1. 接收到消息后直接存入磁盘而非内存（内存中只保留最近的消息，默认2048条）
       	2. 消费者要消费消息时才会从磁盘读取并加载到内存
      
       3. rabbitMq如何保证消息的可靠性
       	1. 通过配置可以让交换机，队列，消息都持久化
       	2. 引入lazyQueue，lazyQueue会将所有消息都持久化
       	3. 开启持久化和生产者确认时，rabbitmq只有在消息持久化完成后才会给生产者返回ack回执
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13

   3. 消费者的可靠性

      1. 消费者确认机制
         为了确认消费者是否成功处理消息，rabbitmq提供了消费者确认机制，当消费者处理
         消息结束后，应该向rabbitmq发送一个回执，告知rabbitmq自己消息处理状态，回执有三中可选值：
         ack:成功处理消息，rabbitmq从队列中删除该消息
         nack:消息处理失败，rabbitmq需要再次投递消息
         reject:消息处理失败并拒绝该消息，rabbitmq从队列中删除该消息
         springAMQP已经实现了消息确认功能，并允许我们公国配置文件选择ACK处理方式，有三种方式：

         1. none:不处理，即消息投递给消费者后立即ack,消息会立刻从mq删除，非常不安全
         2. manual:手动模式，需要自己在业务代码中调用api，发送ack或reject,存在业务入侵
         3. auto:自动模式，springAMQP利用aop对我们的消息处理逻辑做了环绕增强，当业务正常执行时则自动返回ack,当业务出现异常时，根据异常判断返回不同结果：
            如果是业务异常，会自动返回nack
            如果是消息处理或校验异常，自动返回reject

      2. 消费失败处理
         失败消息处理策略

          1. RejectAndDontRequeueRecoverer:重试耗尽后，直接reject，丢弃消息。默认就是这种方式
          2. ImmediateRequeueMessageRecoverer:重试耗尽后，返回nack，消息重新入队
          3. RepublishMessageRecoverer:重试耗尽后，将失败消息投递到指定的交换机
         1
         2
         3

      3. 业务幂等性
         唯一消息id
         在消息转换器中设置

   4. 延迟消息
      死信交换机
      当一个队列中的消息满足下列情况之一，就会成为死信：

       1. 消费者使用basic.reject或basic.nack声明消费失败，并且消息的requeue参数设置为false
       2. 消息是一个过期消息（达到队列或消息本身设置的过期时间），超时无人消费
       3. 要投递的队列消息堆积满了，最早的消息可能成为死信
      1
      2
      3

      如果队列通过dead-letter-exchange属性指定了一个交换机，那么该队列中的死信就会投递到这个交换机中，这个交换机称为死信交换机（Dead Letter Exchange,简称DLX）

      延迟消息插件

      取消超时订单

源码地址：https://gitee.com/persionalPage/mq-demo
视频地址：https://www.bilibili.com/video/BV1mN4y1Z7t9?p=1&vd_source=7ebf9410d44fe497a305dad4df81bf1b