认识RabbitMq 第一篇（什么是MQ,基本概念，工作原理，持久化，以及发布确认）

最新推荐文章于 2024-02-02 11:08:31 发布

我的代码没错

最新推荐文章于 2024-02-02 11:08:31 发布

阅读量398

点赞数 2

分类专栏：个人笔记文章标签： rabbitmq java

本文链接：https://blog.csdn.net/m0_46937429/article/details/119796081

版权

个人笔记专栏收录该内容

70 篇文章 1 订阅

订阅专栏

MQ 的相关概念

什么是MQ

MQ (message queue) 就是队列的意思。FIFO 先进先出，只不过队列中存放的内容是 message 而已还是一种跨进程的通信机制，用于上下游传递消息。“逻辑解耦 + 物理解耦” 的通信服务。使用了MQ 之后消息发送只需要依赖 MQ 不用依赖其他服务。

什么是 RabbitMq

RabbitMq 是一个消息中间件。他接受并转发消息。可以当做一个快递的站点。当你要发送包裹的时候，把快递放到快递站点快递站点的快递员在为你派送。这中间 RabbitMq 与快递站的区别在于它不是处理快件而是接收存储和转发消息数据。

RabbitMq 的基本概念

Exchange

接受生产者发送的消息，并根据Binding规则将消息路由给服务器中的队列。ExchangeType决定了Exchange路由消息的行为。在RabbitMQ中，ExchangeType常用的有direct、Fanout和Topic三种

Message Queue

消息队列。我们发送给RabbitMQ的消息最后都会到达各种queue，并且存储在其中(如果路由找不到相应的queue则数据会丢失)，等待消费者来取。

Binding Key

它表示的是Exchange与Message Queue是通过binding key进行联系的，这个关系是固定。

Routing Key

生产者在将消息发送给Exchange的时候，一般会指定一个routing key，来指定这个消息的路由规则。这个routing key需要与Exchange Type及binding key联合使用才能生，我们的生产者只需要通过指定routing key来决定消息流向哪里。

RabbitMq 使用的场景

服务解耦

假设现在服务A 产生数据服务 BCD 又需要这些数据那么我们直接让A 服务中直接调用 BCD 服务。把数据传递下去就可以了。
但是随着我们的应用规模不断的扩大会有更多的服务需要A 的数据有几十甚至几百个下游的服务的话，还要考虑下游的服务会不会出错那么这样的话 A 服务中调用代码的维护就会很困难。
这样服务之间的耦合度过于紧密。

如下图所示
在这里插入图片描述

在考虑用在RabbitMq 解耦的情况
A服务只需要向服务器发送消息不用考虑睡需要这些数据如何谁需要的话自己去拿就可以了。
如图所示
在这里插入图片描述

流量消峰

假设我们的应用平时访问量是每300 s 请求我们用一台服务器即可轻松应对

而在高峰期访问量瞬间翻了十倍达到每秒 3000次甚至更多那么单个服务器是没有办法应对的这个时候要考虑多个服务器分散压力
但是也不可能永远都有这么多的高峰所以多个服务器就有点浪费了
我们也可以考虑用RabbitMq 来进行流量消峰 ,高峰情况下,瞬间出现的大量请求数据,先发送到消息队列服务器,排队等待被处理,而我们的应用,可以慢慢的从消息队列接收请求数据进行处理,这样把数据处理时间拉长,以减轻瞬时压力
这是消息队列服务器非常典型的应用场景
如图所示
在这里插入图片描述

异步调用

考虑定外卖支付成功的情况

支付后要发送支付成功的通知,再寻找外卖小哥来进行配送,而寻找外卖小哥的过程非常耗时,尤其是高峰期,可能要等待几十秒甚至更长

这样就造成整条调用链路响应非常缓慢

而如果我们引入RabbitMQ消息队列,订单数据可以发送到消息队列服务器,那么调用链路也就可以到此结束,订单系统则可以立即得到响应,整条链路的响应时间只有200毫秒左右

寻找外卖小哥的应用可以以异步的方式从消息队列接收订单消息,再执行耗时的寻找操作

Hello world

发送单个消息的生产者和接受者并打印出来消费者

添加依赖

        <!-- https://mvnrepository.com/artifact/com.rabbitmq/amqp-client -->
        <dependency>
            <groupId>com.rabbitmq</groupId>
            <artifactId>amqp-client</artifactId>
            <version>5.8.0</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/commons-io/commons-io -->
        <dependency>
            <groupId>commons-io</groupId>
            <artifactId>commons-io</artifactId>
            <version>2.6</version>
        </dependency>

生产者代码

如图所示
先写生产者的代码
在写消费者的代码
在这里插入图片描述

// 生产者 代码
public class Producer {
    // 准备队列的名字
    public static final String QUEUE_NAME = "fjj";
    public static void main(String[] args) throws Exception {
        // 创建链接的对象
        ConnectionFactory factory = new ConnectionFactory();
        // 设置工厂信息
        factory.setHost("localhost");
        // 用户名
        factory.setUsername("guest");
        // 密码
        factory.setPassword("guest");
        // 创建链接
        Connection connection = factory.newConnection();
        // 获取信道
        Channel channel = connection.createChannel();
        // 生成队列
        // 参数1 我们的消息 队列名字
        // 参数2 是否持久化（磁盘） 默认存储在内存中  true ，表示持久化，会存盘，服务器重启仍然存在，false，非持久化
        // 参数2 是否只供一个消费者消费 是否消息共享 true 可以多个消费者消费
        // 参数4 最后一个消费者走后 是否自动删除
        // 其他参数
        channel.queueDeclare(QUEUE_NAME, true, false,true,null);
        // 准备发送的消息  我这里写100条消息
        String message = " Hi，My name is fjj";
        ArrayList<String> list = new ArrayList<>();
        for (int i = 0; i < 100; i++) {
            list.add(message+i);
        }
        for (String messages : list) {
            // 参数1  发送到那个交换机
            // 参数2  路由的Key 的值 队列名称
            // 参数3  其他的参数
            // 参数4  发送的消息 这里必须转换一下 
            channel.basicPublish("",QUEUE_NAME,null,messages.getBytes());
        }
        System.out.println("发送over");
    }
}

查看我们的web 的界面
在这里插入图片描述

消费者代码



public class Consumer {
    // 准备要接收队列的名字
    public static final String QUEUE_NAME = "fjj";

    // 接收消息
    public static void main(String[] args) throws Exception {
        // 创建链接的对象
        ConnectionFactory factory = new ConnectionFactory();
        // 设置工厂的队列
        factory.setHost("localhost");
        // 用户名
        factory.setUsername("guest");
        // 密码
        factory.setPassword("guest");
        // 创建链接
        Connection connection = factory.newConnection();
        // 接收消息
        Channel channel = connection.createChannel();
        // 参数1  消费那个队列
        // 参数2  消费成功后 是否要自动应该
        // 参数3  消费者  没有成功消费 的一个回调
        // 参数4  消费者取消消费的回调
        // 声明 接收消息
        DeliverCallback deliverCallback = (consumerTag, message) -> {
            System.out.println("message = " +new String( message.getBody()));
        };
        // 取消消息的回调
        CancelCallback cancelCallback = consumerTag -> {
            System.out.println(" 消息中断");
        };
        channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);
    }
}

控制台查看
在这里插入图片描述
web 界面查看

工作队列原理

工作队列（任务队列）的主要思想是避免立即执行资源密集任务，而不得不等待它完成。相反我们安排在之后执行。把任务封装为消息并将其发送到队列。在后台运行的工作进程弹出任务并最终执行作业。当有多个工作线程时这些线程将一起处理这些任务。

轮训分发消息

在这个案例中我们会启动两个工作线程一个消息发送线程看看两个工作线程时如何工作的。

封装工具类

这种重复的代码应该抽离出来单独的。方便调用就行

public class RabbitmqUtil {
    public static Channel getChannel () throws Exception {
        // 创建链接的对象
        ConnectionFactory factory = new ConnectionFactory();
        // 设置工厂的队列
        factory.setHost("localhost");
        // 用户名
        factory.setUsername("guest");
        // 密码
        factory.setPassword("guest");
        // 创建链接
        Connection connection = factory.newConnection();
        // 接收消息
        Channel channel = connection.createChannel();
        return channel;
    }
}

启动两个工作的线程

消费者代码

// 这是 第一个工作线程
public class Consumer01 {
    // 准备要接收队列的名字
    public static final String QUEUE_NAME = "fjj";

    public static void main(String[] args) throws Exception {
        Channel channel = RabbitmqUtil.getChannel();
        // 接收消息
        // 参数1  消费那个队列
        // 参数2  消费成功后 是否要自动应该
        // 参数3  消费者  没有成功消费 的一个回调
        // 参数4  消费者取消消费的回调
        // 声明 接收消息
        DeliverCallback deliverCallback = (consumerTag, message) -> {
            System.out.println("message = " +new String( message.getBody()));
        };
        // 取消消息的回调
        CancelCallback cancelCallback = consumerTag -> {
            System.out.println(" 消息中断");
        };
        System.out.println("C1 等待线程中！！！！！！！！！");
        channel.basicConsume(QUEUE_NAME, true, deliverCallback, cancelCallback);
    }
}

另一个消费者代码跟这个一样就可以

创建生产者的代码


public class Producer01 {
    // 指定队列名称
    public static final String QUEUE_NAME = "fjj";
//    发送 大量的消息
public static void main(String[] args) throws Exception {
    // 创建链接
    Channel channel = RabbitmqUtil.getChannel();
    channel.queueDeclare(QUEUE_NAME,false,false,false,null);
    // 发送消息
    Scanner scanner = new Scanner(System.in);
    while (scanner.hasNext()) {
        String msg = scanner.next();
        channel.basicPublish("",QUEUE_NAME,null,msg.getBytes());
        System.out.println("生产者over");
    }
}
}

工作队列结果

在这里插入图片描述

你一个我一个这样的轮询方式

消息应答

消费者完成一个任务可能需要一段时间，如果其中一个消费者处理一个长的任务并仅只完成了部分突然它挂掉了，会发生什么情况 RabbitMq 一旦消费者传递了一条消息便立即将该消息标记删除在这种情况下突然有个消费者挂掉了我们就会丢失数据以及后续发给这个消费者的数据都会消失

为了保证消息在发送的过程中不会丢失 RabbitMq 引入了消息应答机制就是：消费者在接收到消息后并且处理该消息之后高速 RabbitMq 它已经处理了，RabbitMq 可以把消息删除了

自动应答

消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡因为这种模式如果消息在接收到之前消费者那边出现链接或者Cannel 关闭，那么消息就丢失了。当然另一方面这种模式消费者那边可能传递过载的消息。没有对传递的消息数量进行限制也有可能消费者接收太多来不及处理消息。导致消息积压最终是的内存耗尽。最终这些消费者线程被操作系统杀死 所以这种默认适合在消费者可以高效并以某种速率能够处理这些消息的情况下使用。

手动应答

Cannel.basicAck(用于肯定确认) RabbitMq 已经知道该消息并且成功的处理消息，可以将其丢弃了
Cannel.basicNack (用于否定确认)
Cannel.basicReject(用于否定确认) 与Cannel.basicNack 相比少一个参数不处理该消息了直接拒绝可以将其丢弃了。

消息自动重新入队

如果消费者由于某些原因失去链接（其通道已关闭连接已关闭或者Tcp链接丢失），导致消息未发送ACK 确认 RabbitMq 将了解到消息未完全处理并对其重新排队如果此时其他消费者可以处理就会将其重新分发给另一个消费者这样即使某个消费者偶尔死亡也可以确保不会丢失任何消息

消息手动应答代码

生产者代码

public class Producer02 {
    // 设置 队列的名字
    public final static String QUEUE_NAME ="ack_Hello";

    public static void main(String[] args) throws Exception {
        // 获取信道
        Channel channel = RabbitmqUtil.getChannel();
        // 设置 发送
        channel.queueDeclare(QUEUE_NAME,false,false,false,null);
        Scanner scanner = new Scanner(System.in);
        while (scanner.hasNext()) {
            String msg = scanner.next();
            channel.basicPublish("",QUEUE_NAME,null,msg.getBytes("UTF-8"));
            System.out.println("生产者over");
        }
    }
}

消费者的Consumer03

public class Consumer03 {
    public final static String QUEUE_NAME ="ack_Hello";

    public static void main(String[] args) throws Exception{
        Channel channel = RabbitmqUtil.getChannel();
        DeliverCallback deliverCallback = (consumerTag, message) -> {
            // 沉睡
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("C3  接收到的消息 = " +new String( message.getBody()));
            // 1 消息的 标记
            // 2 是否批量应答
            channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
        };
        // 取消消息的回调
        CancelCallback cancelCallback = consumerTag -> {
            System.out.println(" 消息中断");
        };
        boolean authAck = false;
        channel.basicConsume(QUEUE_NAME, authAck, deliverCallback, cancelCallback);
    }
}

另一个消费者跟这个一样只不过睡眠的时间不一样而已

消息应答结果

正常情况下消息发送方发送两个消息 C1 和 C2 分别接收到消息并进行处理
但是在发送某个消息的时候这个时候 C2 消费者突然死掉了按道理来说轮询的方式接收消息这条消息就是C2 的可是 C2 死掉后此时这条消息就会回到消息队列重新入队然后会分配给C1消费者来消费。

RabbitMq 持久化

概念

刚刚看到了如何处理任务不丢失的情况但是如何保障当RabbitMq 服务停掉以后消息发送者发送过来的消息不丢失默认情况下 RabbitMq 退出或由于某种原因崩溃时它忽视队列和消息除非告知它不要这样做确保消息不丢失需要做两件事：我们需要将队列和消息都标记为持久化。

队列如何持久化

之前我们创建的队列都是非持久化的，rabbitmq 如果重启的话改队列就会被删除掉如果要队列实现持久化需要在声明队列的时候吧 burable 参数设置为持久化
在这里插入图片描述

但是需要注意的就是如果之前声明的队列不是持久化的，需要把原先的队列先删除或者重新创建一个持久化队列不然就会出现错误。

消息实现持久化

要想让消息持久化需要在消息生产者修改代码，MessageProperties.PERSISTENT_TEXT_PLAIN 添加这个属性。
在这里插入图片描述

将消息标记为持久化并不能完全保证不会丢失消息尽管他告诉 RabbitMq 将消息保存到磁盘，但是这里依然存在当消息刚准备存储在磁盘的时候，但是还没有存储完消息还在缓存的一个间断点此时并没有真正写入磁盘持久性保证并不强但是对于我们的简单任务队列而已这已经绰绰有余了。

不公平分发

在最开始的时候我们学习RabbitMq 分发消息采用的轮训分发但是哎某种场景下这种策略并不是很好比如说有两个消费者在处理任务其中有个消费者 1 处理任务的速度非常快而另一个消费者 2 处理速度慢这个时候我们还是采用轮训分发的话就会到这个处理速度非常快的这个消费者很大一部分时间处于空闲状态而处理慢的那个消费者一直在干活这种分配方式在这种情况下不太友好但是 RabbitMq 并不知道这种情况它依然很公平的进行分发
为了避免这种情况可以设置参数channel.basicQos(1)
在这里插入图片描述

预取值

本身消息的发送就是异步发送的，所以在任何时候，管道上肯定不止只有一个消息另外来自消费者的手动确定本质上也是异步的。因此这里就存在一个为确认的消息缓冲区，希望开发人员限制此缓冲区的大小，避免缓冲区里面无限制的未确认消息信息问题 这个时候就可以通过
channel.basicQos （）这个方法来设置“预期值的数”来完成的。该值定义通道上允许的未确定消息的最大数量 一旦数量达到配置的数量，RabbitMq
就停止在通道上传递消息、除非有一个未处理的消息被确认。

例子😊

假设在通道上有为确定的消息 5,6，7,8 并且通道的预取值设置的是4 ，此时 RabbitMq 就不会在往该通道发送任何消息。除非至少有一个未应答的消息被 ACK 比如说tag=6 这个消息刚刚被确认Ack , RabbitMq 将会感知这个情况并且在发送一条消息。消息应答和QoS 预取值对用户吞吐量有重大影响。通常，增加预取值将会提高向消费者传递消息的速度。虽然自动应答传输消息速率是最佳的，但是，在这种情况下已经传递但尚未处理的消息的数量也会增加，从而增加了消费者的RAM 消耗应该预取值尽量是1 为最保守的。当然这样会让吞吐量变的比较低，特别是消费者连接延迟很严重的情况下。对于大多数的应用来说，稍微高一点的值将是最佳的。

发布确认

单个确认发布

这是一种简单的确认方式，它是一种同步同步确认发布的方式，也就是发布一个消息之后只有它确认发布，后续的消息才能继续发布，waitForConfiemsOrDie(Long) 这个方法只有在消息被确认时候才返回，如果在指定时间范围内这个消息没有被确认那么它将抛出异常。
这种确认方式有一个最大的缺点就是：发布速度特别的慢因为如果没有确认发布的消息就会塞所有后续消息的发布，这种方式最多提供每秒不超过数白条发布消息的吞吐量，当然对于某应用程序来说这可能已经足够了。
代码

  public static void OneMessage () throws Exception {
        // 创建管道
        Channel channel = RabbitmqUtil.getChannel();
        // 队列的声明
        String queueName = UUID.randomUUID().toString();
        channel.queueDeclare(queueName,true,false,false,null);
        // 开启发布确认
        channel.confirmSelect();

        // 开始的时间
        long begin = System.currentTimeMillis();
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            // 发送消息
            String message =i +"";
            channel.basicPublish("",queueName,null,message.getBytes());
            //单个消息马上进行发布
            boolean b = channel.waitForConfirms();
            if (b) {
                System.out.println("发送成功！！！");
            }
        }
        // 结束时间
        long end = System.currentTimeMillis();
        System.out.println("单个发布消息耗时" + (end-begin) + "ms");

    }

批量发布消息

上面那种方式非常慢，与单个等待确认消息相比，先发布一批消息然后一起确认可以极大地提高吞吐量，当然这种方式的缺点就是：当发生故障导致发布出现问题时，不知道是那个消息出现问题了，我们必须将整个批处理保存在内存中，以记录重要的信息而后重新发布消息，当然这种方案仍是同步的也一样阻塞消息的发布。
代码

    public static void OnesMessage () throws Exception {
        // 获取到管道的
        Channel channel = RabbitmqUtil.getChannel();
        // 创建名字
        String quenename = UUID.randomUUID().toString();
        // 设置发送
        channel.queueDeclare(quenename,true,false,false,null);
        // 设置开始的时间
        long start = System.currentTimeMillis();
        // 设置发布确认
        channel.confirmSelect();
        // 设置批量发送的数
        int num = 100;
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            // 设置发送的消息
            String message =i +"";
            channel.basicPublish("",quenename,null,message.getBytes());
            // 这里设置判断 每100 条就发布确认一下
            if (i%num == 0) {
                channel.waitForConfirms();
            }
        }
        // 结束时间
        long end = System.currentTimeMillis();
        System.out.println("批量发布消息耗时" + (end-start) + "ms");

    }

异步确认发布

异步确认虽然编程逻辑比上面的要复杂，但是性价比最高，无论是可靠性还是效率都不错，他是利用回调函数来达到消息可靠性传递的，这个中间件也是通过函数回调来保证是否投递成功。
代码

    public static void AsynMessage () throws Exception {
        // 获取到管道的
        Channel channel = RabbitmqUtil.getChannel();
        // 创建名字
        String quenename = UUID.randomUUID().toString();
        // 设置发送
        channel.queueDeclare(quenename,true,false,false,null);
        // 设置开始的时间
        long start = System.currentTimeMillis();
        // 设置发布确认
        channel.confirmSelect();
        // 消息确认的回调函数
        ConfirmCallback ackCallback = (deliveryTag,multiple) -> {

        };
        // 消息失败的
        ConfirmCallback nackCallback = (deliveryTag,multiple) -> {
            System.out.println("没有确认的消息 = " + deliveryTag);
        };
        channel.addConfirmListener(ackCallback,nackCallback);
        // 设置批量发送的数
        int num = 100;
        for (int i = 0; i < MESSAGE_COUNT; i++) {
            // 设置发送的消息
            String message =i +"";
            channel.basicPublish("",quenename,null,message.getBytes());
            // 这里设置判断 每100 条就发布确认一下
            if (i%num == 0) {
                channel.waitForConfirms();
            }
        }
        // 结束时间
        long end = System.currentTimeMillis();
        System.out.println("批量发布消息耗时" + (end-start) + "ms");
    }

如何处理异步为确认的消息

最好的解决方案就是把未确认的消息放到一个基于内存的能被发布线程访问的队列，如何说用 ConcurrentLinkedQueue 这个队列在 confirm callbacks 与发布线程之间进行消息的传递。

3种发布确认速度对比

单独发布消息
同步等待确认，简单，但吞吐量非常有限
批量发布消息
批量同步等待确认，简单，合理的吞吐量，一旦出现问题但很难推断出是那条消息出了问题
异步处理
最佳性能和资源使用在出现错误的情况下可以很好的控制但是实现起来稍微难一点。
在这里插入图片描述

我的代码没错

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
认识RabbitMq 第一篇（什么是MQ,基本概念，工作原理，持久化，以及发布确认）

消息队列MQ 的相关概念什么是MQ什么是 RabbitMqRabbitMq 的基本概念ExchangeMessage QueueBinding KeyRouting KeyRabbitMq 使用的场景服务解耦流量消峰异步调用Hello world添加依赖生产者代码消费者代码工作队列原理轮训分发消息封装工具类启动两个工作的线程MQ 的相关概念什么是MQMQ (message queue) 就是队列的意思。FIFO 先进先出，只不过队列中存放的内容是 message 而已还是一种跨进程的通信机制，用于
复制链接

扫一扫