RabbitMQ 视频学习(基础篇)

本文以 阿里云 为基础,参考的是尚硅谷的视频:尚硅谷2021新版RabbitMQ教程 | 快速掌握MQ消息中间件

1、MQ 的相关概念

1.1、什么是 MQ?

MQ(Message Queue),从字面意思上看,本质上是个队列,FIFO先入先出,只不过队列中存放的内容是 message 而已,还是一种跨进程的通信机制,用于上下游传递消息。在互联网架构中,MQ是一种非常常见的上下游"逻辑解耦 + 物理解耦"的消息通信服务。使用了MQ之后,消息发送上游只需要依赖MQ,不用依赖其他服务。

1.2、为什么要使用 MQ?

1.2.1、流量消峰

5To6u8.png
举个例子,如果订单系统最多能处理一万次订单,这个处理能力能应付正常时段的下单时绰绰有余,正常时段我们下单一秒后就能返回结果。但是在高峰期,如果有两万次下单操作系统是处理不了的,只能限制订单超过一万后不允许用户下单。使用消息队列作为缓冲,我们可以取消这个限制,把一秒钟内下的订单分散成一段时间来处理,这时有些用户可能在下单十几秒后才能收到下单成功的操作,但是不能比下单的体验要好。

1.2.2、应用解耦

5TThZD.png
以电商应用为例,应用中有订单系统、库存系统、物流系统、支付系统。用户创建订单后,如果耦合调用库存系统、物流系统、支付系统,任何一个子系统出现了故障,都会造成下单操作异常。当转变成基于消息队列的方式后,系统间调用的问题会减少很多,比如物流系统因为发生故障,需要几分钟来修复。在这几分钟时间里,物流系统要处理的内存被缓存在消息队列中,用户的下单操作可以正常完成。当物流系统修复后,继续处理订单信息即可,中间下单用户感受不到物流系统的故障,提升系统的可用性。

1.2.3、异步处理

5T7GwD.png
有些服务间的调用是异步的,例如A调用B,B需要花费很长时间执行,但是A需要知道B什么时候可以执行完,以前一般有两种方式,第一种:A过一段时间去调用B的查询api查询。或者A提供一个Callback api,B执行完之后调用api通知A服务。这两种方式都不是很优雅,使用消息总线,可以很方便的解决这个问题,A调用B服务后,只需要监听B处理完成的消息,当B处理完成后,会发送一条消息给 MQ ,MQ 会将此消息转发给A服务。这样A服务既不用循环调用B的查询api,也不用提供Callback api。同样B服务也不用做这些操作。A服务还能及时的得到异步处理成功的消息。注:使用消息总线的时候,B服务在处理请求完成之前,A服务可以去做其他的任务,而以前的两种方式A服务在B服务处理请求的时候都是处于等待状态的

1.3、MQ 的分类

1.3.1、ActiveMQ

  • 优点:单机吞吐量万级,时效性 ms 级别,可用性高,基于主从架构实现高可用性,消息可靠性较低的概率丢失数据
  • 缺点:官方社区现在对Active MQ 5.x 维护越来越少,高吞吐量场景较少使用

1.3.2、KafKa

大数据的杀手锏,谈到大数据领域内的消息传输,则绕不开Kafka,这款为大数据而生的消息中间件,以其百万级别TPS的吞吐量名声大噪,迅速成为大数据领域的宠儿,再数据采集、传输、存储的过程中发挥着举足轻重的作用。目前已经被 LinkedIn、Uber、Twitter、Netflix等大公司所采纳。

  • 优点:性能卓越,单继写入TPS约在百万条/秒,最大的优点,就是吞吐量高。时效性 ms 级可用性非常高,kafka 是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用,消费者采用 Pull 的方式获取消息,消息有序,通过控制能够保证所有消息被消费且仅被消费一次;有优秀的第三方 Kafka Web 管理界面 Kafka - Manager;在日志领域比较成熟,被多家公司和多个开源项目使用;功能支持:功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用
  • 缺点:Kafka 单机超过 64 个队列/分区,Load 会发生明显的飙高现象,队列越多,load 越高,发送消息响应时间变长,使用短轮询方式,实时性取决于轮询间隔时间,消费失败不支持重试(简单的来说就是:会出现消息丢失的现象);支持消息顺序,但是一台代理宕机后, 就会产生消息乱序,社区更新较慢。

1.3.3、RocketMQ

RocketMQ出自阿里巴巴的开源产品,用JAVA语言实现,在设计的时候参考了Kafka,并做出了自己的一些改进。被阿里巴巴广泛应用在订单,交易,充值,流计算,消息推送,日志流处理,binlog 分发等场景。

  • 优点单机吞吐量十万级,可用性非常高,分布式架构,消息可以做到0丢失,MQ 功能较为完善,还是分布式的,扩展性好,支持10亿级别的消息堆积,不会因为堆积导致性能下降,源码是java 我们可以自己阅读源码,定制自己公司的 MQ。
  • 缺点支持的客户端语言不多,目前是JAVA 以及 C++,其中C++不成熟;社区活跃度一般,没有在MQ 核心中去实现 JMS 等接口,有些系统迁移需要修改大量代码。

1.3.4、RabbitMQ

2007年发布,是一个在 AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一

  • 优点:由于 erlang 语言的高并发特性,性能较好;吞吐量到万级,MQ 功能比较完善,健壮、稳定、易用、跨平台、支持多种语言,如:Python、Ruby、.NET、JAVA、JMS、C、PHP、ActionScript、STOMP等,支持AJAX 文档齐全;开源提供的管理界面非常棒,用起来非常好用,社区活跃度高;更新频率非常高
  • 缺点:商业版需要收费,学习成本较高。

1.4、MQ 的选择

1.4.1、Kafka

Kafka 主要特点是基于 Pull 的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,适合产生大量数据的互联网服务的数据收集业务。 大型公司建议可以选用,如果有日志采集功能,肯定是首选Kafka了。

1.4.2、RocketMQ

天生为金融互联网领域而生,对于可靠性要求很高的场景,尤其是电商里面的订单扣款,以及业务消峰,在大量交易涌入的时候,后端可能出现无法及时处理的情况。RocketMQ 在稳定性上可能更加值得信赖,这些业务场景在阿里双11已经经历了多次考验,如果你的业务有上述并发场景,建议可以选择 RocketMQ。

1.4.3、RabbitMQ

结合 erlang 语言本身的并发优势,性能好时效性微妙级别,社区活跃度也比较高,管理界面用起来也十分方便,如果你的数据量没有那么大,中小型公司优先选择功能比较完备的 RabbitMQ 。

2、RabbitMQ 的开始之路

2.1、RabbitMQ 的概念

RabbitMQ 是一个消息中间件:它接受并转发消息。你可以把它当做一个快递站点,当你要发送一个包裹的时候,你把你的包裹放到快递站,快递员最终会把你的快递送到收件人那里,按照这种逻辑 RabbitMQ 是一个快递站,一个快递员帮你传递快件。RabbitMQ与快递站的主要区别在于,它不处理快件而是接收,存储和转发消息数据。

2.2、四大核心概念

  • 生产者

    • 产生数据发送消息的程序是生产者
  • 交换机

    • 交换机是 RabbitMQ 非常重要的一个部件,一方面它接收来自生产者的消息,另一方面它将消息推送到队列中。交换机必须确切知道如何处理它接收到的消息,是将这些消息推送到特定队列还是推送到多个队列。亦或者是把消息丢弃,这个得由交换机类型决定。
  • 队列

    • 队列是 RabbitMQ 内部使用得一种数据结构,尽管消息流经 RabbitMQ 和应用程序,但是他们只能存储在队列中。队列仅受主机的内存和磁盘限制的约束,本质上是一个大的消息缓冲区。许多生产者可以将消息发送到一个队列,许多消费者可以尝试从一个队列中接收数据。这就是我们使用队列的方式。
  • 消费者

    • 消费与接收具有相似的含义。消费者大多时候是一个等待接收消息的程序。请注意生产者,消费者和消息中间件很多时候并不在同一个机器上。同一个应用程序既可以是生产者又是可以是消费者。
      5H4nAJ.png

2.3、RabbitMQ 的核心部分(六大模式)

在这里插入图片描述

2.3.1、各个名词介绍

5H5l5j.png

  • Broker:接收和分发消息的应用,RabbitMQ Server 就是 Message Broker
  • Virtual host:出于多租户和安全因素设计的,把 AMQP 的基本组件划分到一个虚拟的分组中,类似于网络中的 namespace 概念。当多个不同的用户使用同一个 RabbitMQ Server 提供的服务的时候,可以划分出多个vhost,每个用户在自己的 vhost 创建 exchange / queue 等。
  • Connection:publisher / consumer 和 broker 之间的TCP连接。
  • Channel:如果每一次访问 RabbitMQ 都建立一个 Connection,在消息量大的时候建立 TCP Connection 的开销将是巨大的,效率也较低。Channel 是在 Connection 内部建立的逻辑连接,如果应用程序支持多线程,通常每个 thread 创建单独的 channel 进行通讯,AMQP method 包含了channel id, 帮助客户端和 message broker 识别 channel,所以 channel 之间是完全隔离的。Channel 作为轻量级的 Connection 极大地减少了操作系统建立TCP Connection的开销
  • Exchange:message 到达 broker 的第一站,根据分发规则,匹配查询表中的 routing key,分发消息到 queue 中去。常用的类型有:direct(point-to-point),topic(publish-subscrible)and fanout(multicast)。
  • Queue:消息最终被送到这里等待 consumer 取走
  • Binding:exchange 和 queue 之间的虚拟连接,binding中可以包含 routing key,Binding 信息被保存到 exchange 中的查询表中,用于 message 的分发依据。

3、使用 RabbitMQ

查询 rabbitMQ,不指定的话默认为最新版本latest:
5XkvV0.png
拉取镜像:

docker pull rabbitmq:management

查看 docker 镜像列表:

5Xo3wt.png

Docker 容器操作:上面命令执行后,镜像就已经拉取到本地仓库了,然后可以进行容器操作,启动 RabbitMQ

# 设置账户密码运行 RabbitMQ
# -d 后台运行
# -p 映射对外开放的端口 主机端口:容器端口
# --name 指定rabbitMQ容器的名称
# -e 配置环境变量  -e RABBITMQ_DEFAULT_USER 指定用户账号
# -e RABBITMQ_DEFAULT_PASS指定账号密码
# --hostname 主机名(RabbitMQ 的一个重要注意事项是它根据所谓的节点名称存储数据,默认为主机名)
docker run -d -p 15672:15672 -p 5672:5672 -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin --name rabbitmq --hostname=rabbitmqhostone rabbitmq:management

# 不设置账户名密码运行 RabbitMQ
docker run -d -p 5672:5672 --name rabbitmq rabbitmq:management

注意, rabbitMQ 默认的账号密码是:guest/guest

进入正在运行的 RabbitMQ 容器:
5XTw9O.png

# 添加一个新的用户
root@rabbitmqhostone:/# rabbitmqctl add_user 用户名 密码

# 设置用户角色
root@rabbitmqhostone:/# rabbitmqctl set_user_tags 用户名 tags/administrator

# 设置用户和角色
set_permission [-p <vhostpath>] <user> <conf> <write> <read>
rabbitmqctl set_permission -p "/" admin ".*" ".*" ".*"

# 查看当前用户和角色
root@rabbitmqhostone:/# rabbitmqctl list_users
Listing users ...
user    tags
admin   [administrator]

登录成功后的 RabbitMQ主界面:
5XqUqH.png

4、JAVA语言来使用 RabbitMQ

使用JAVA编写两个程序,发送单个消息的生产者和接收消息并打印出来的消费者。

P 是我们的生产者,C是我们的消费者,中间的红色框是一个队列 ==》 代表使用者保留的消息缓冲区。
5XjD0g.png
例如,创建 Maven 项目并导入如下依赖:

<dependencies>
    <!-- https://mvnrepository.com/artifact/com.rabbitmq/amqp-client -->
    <dependency>
      <groupId>com.rabbitmq</groupId>
      <artifactId>amqp-client</artifactId>
      <version>5.13.1</version>
    </dependency>

    <!-- https://mvnrepository.com/artifact/commons-io/commons-io -->
    <dependency>
      <groupId>commons-io</groupId>
      <artifactId>commons-io</artifactId>
      <version>2.11.0</version>
    </dependency>

</dependencies>
<build>
    <plugins>
      <!-- 指定jdk编译版本 -->
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
    </plugins>
</build>

生产者代码构建:

public class Proceducer {
    //队列名称
    public static final String QUEUE_NAME="hello";

    public static void main(String[] args) throws IOException, TimeoutException {
        //发消息
        //创建一个连接工厂
        ConnectionFactory factory=new ConnectionFactory();
        //工厂IP,连接RabbitMQ的队列
        factory.setHost("39.107.103.173");
        //用户名
        factory.setUsername("admin");
        //密码
        factory.setPassword("admin");
        //设置端口号  注意 15672是RabbitMQ是后台管理界面的端口号 应该设置5672端口
        factory.setPort(5672);

        //创建连接
        Connection connection = factory.newConnection();

        //获取信道(Channel)
        Channel channel = connection.createChannel();

        //创建一个队列
        /**
         * queueDeclare(String var1, boolean var2, boolean var3, boolean var4, Map<String, Object> var5)
         * var1:队列名称
         * var2:队列里面的消息是否持久化,默认情况下消息是存储在内存中,持久化即为存储在磁盘中
         * var3:该队列是否支持多个消费者进行消费,是否进行消息共享,true可以多个消费者消费(即消息共享)
         * false表示只能一个消费者消费(即不进行消息共享)
         * var4:是否自动删除 最后一个消费者断开连接以后 该队列是否自动进行删除
         * var5:其他参数,例如:延迟消息等等
         */
        channel.queueDeclare(QUEUE_NAME,false,false,false,null);
        //发消息
        String message="hello rabbitMQ";

        /**
         * 发送一个消息:
         * 1.发送到哪个交换机
         * 2.路由的key值  本次是队列的名称 根据routing key分发消息到队列中
         * 3.其他参数信息
         * 4.发送消息的消息体
         */
        channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
        System.out.println("消息发送完毕!");
    }

}

消费者队列构建:

/**
 * @author wcc
 * @date 2021/11/3 11:07
 * 消费者,接受消息的
 */
public class Consumer {

    //队列的名称,目的是接受此队列的消息
    public static final String QUEUE_NAME = "hello";

    public static void main(String[] args) throws IOException, TimeoutException {
        //接收消息
        //创建连接RabbitMQ的连接工厂
        ConnectionFactory factory=new ConnectionFactory();
        factory.setHost("39.107.103.173");

        factory.setUsername("admin");
        factory.setPassword("admin");
        factory.setPort(5672);

        Connection connection=factory.newConnection();

        Channel channel=connection.createChannel();

        //成功的消费回调
        DeliverCallback deliverCallback = (consumeTag,message)->{
            System.out.println(new String(message.getBody()));
        };

        //取消消息时的回调
        CancelCallback cancelCallback= (consumerTag)->{
            System.out.println("消费消息被中断");
        };

        //消费者接收消息
        /**
         * 消费者消费消息
         * 1.消费哪个队列
         * 2.消费成功之后是否要自动应答 true代表的是自动应答 false代表的是手动应答
         * 3.消费者成功消费的回调
         * 4.消费者取消消费回调
         */
        channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);
    }
}

5、Work Queues(工作队列)

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

5.1、轮训分发消息

启动两个工作线程,一个消息发送线程,我们来看看两个工作线程是如何工作的?

5.1.1、抽取工具类

public class RabbitMQUtils {
    public static Channel getChannel() throws IOException, TimeoutException {
        //接收消息
        //创建连接RabbitMQ的连接工厂
        ConnectionFactory factory=new ConnectionFactory();
        factory.setHost("39.107.103.173");

        factory.setUsername("admin");
        factory.setPassword("admin");
        factory.setPort(5672);

        Connection connection=factory.newConnection();

        Channel channel=connection.createChannel();
        
        return channel;
    }
}

工作线程接收消息代码

/**
 * @author wcc
 * @date 2021/11/4 10:47
 * 这是一个工作线程 相当于之前讲的消费者
 */
public class Worker01 {

    //队列的名称
    public static final String QUEUE_NAME="hello";

    //接收消息
    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        DeliverCallback deliverCallback=(consumeTag,message)->{
            System.out.println("接收到的消息:"+new String(message.getBody()));
        };

        CancelCallback cancelCallback=message ->{
            System.out.println(message + "消费者取消消费的接口回调逻辑");
        };

        //消息的接收
        /**
         * 消费者消费消息
         * 1.消费哪个队列
         * 2.消费成功之后是否要自动应答 true代表的是自动应答,false代表手动应答
         * 3.消费者消费成功的回调函数
         * 4.消费者取消消费的回调
         */
        System.out.println("C2等待接收消息...");
        channel.basicConsume(QUEUE_NAME,true,deliverCallback,cancelCallback);

    }
}

生产者产生代码(控制台输入数据作为消息)

/**
 * @author wcc
 * @date 2021/11/4 11:04
 * @Description 生产者 发送大量的消息
 */
public class Task01 {

    //队列名称
    public static final String QUEUE_NAME="hello";

    //发送大量消息
    public static void main(String[] args) throws Exception{
        Channel channel = RabbitMQUtils.getChannel();
        //队列
        channel.queueDeclare(QUEUE_NAME,false,false,false,null);
        //从控制台当中接收信息
        Scanner scanner=new Scanner(System.in);
        while (scanner.hasNext()){
            String message=scanner.next();
            /**
             * 发送一个消息到队列
             * 1.发送到哪个交换机
             * 2.路由的key值是哪个 本次是队列的名称
             * 3.其他参数信息
             * 4.发送消息的消息体
             */
            channel.basicPublish("",QUEUE_NAME,null,message.getBytes());
            System.out.println("发送消息完成:"+message);
        }
    }
}

通过最后两个工作线程接收消息的结果来看,工作线程是以轮询的方式来接收消息的,一个消息只能被处理一次,不能够被处理多次。

6、消息应答

6.1、概念

消费者完成一个任务可能需要一段时间,如果其中一个消费者处理一个长的任务并且只完成了部分突然它挂掉了,会发生什么情况。RabbitMQ 一旦向消费者传递了一条消息,便立即将消息标记为删除。在这种情况下,突然有个消费者挂掉了,我们将丢失正在处理的消息。以及后续发送给该消费者的消息,因为它无法接收到。

为了保证消息在接收过程中不丢失,RabbitMQ 引入消息应答机制,消息应答就是:消费者在接收到消息并且处理该消息之后,告诉 RabbitMQ 它已经处理了,RabbitMQ 可以把该消息删除了

6.1.1、自动应答

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

6.1.2、手动应答

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

手动应答的好处就是可以 批量应答并且减少网络拥堵

批量处理参数 Multiple Boolean值

  • Multiple 的 true 和 false 代表不同的意思
    • true 代表批量应答Channel 上未应答的消息
      • 比如说 Channel 上有传送 tag 的消息,5,6,7,8 当前 tag是 8,那么此时 5 ~ 8 的这些还未应答的消息都会被确认收到消息应答
    • false 代表不批量应答Channel 上未应答的消息
      • 只会应答当前 tag = 8的消息,5,6,7 这三个消息依然不会被确认收到消息应答
        IZIgmj.png
        IZI6XQ.png

6.2、消息自动重新入队

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

在这里插入图片描述
6.2.1、消息手动应答代码

默认消息采用的是自动应答,所以我们要想实现消息消费过程中不丢失,需要把自动应答改为手动应答

生产者:
/**
 * @author wcc
 * @date 2021/11/4 15:01
 * 消息在手动应答的时候是不丢失的、放回队列中重新消费
 */
public class Task02 {

    //队列名
    public static final String task_queue_name = "ack_queue";

    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        //声明一个队列
        channel.queueDeclare(task_queue_name,false,false,false,null);
        //从控制台中输入
        Scanner scanner=new Scanner(System.in);
        while (scanner.hasNext()){
            String message = scanner.next();
            channel.basicPublish("",task_queue_name,null,message.getBytes("UTF-8"));
        }

    }
}

消费者:
/**
 * @author wcc
 * @date 2021/11/4 15:07
 * 消息在手动应答的时候是不丢失、放回队列中重新消费
 */
public class Worker03 {

    //队列名
    public static final String task_queue_name = "ack_queue";

    //接收消息
    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        System.out.println("C1等待接收消息处理时间较短");

        DeliverCallback deliverCallback=(consumeTag,message)->{
            //沉睡1秒钟
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("接收到的消息:"+new String(message.getBody(),"UTF-8"));
            //手动应答策略
            /**
             * 1.消息的标记 tag 表示应答的是哪一个消息
             * 2.是否批量应答 false:表示不批量应答信道中的消息 true:表示批量
             */
            channel.basicAck(message.getEnvelope().getDeliveryTag(),false);
        };

        //采用手动应答 第二个参数未是否采用自动应答
        channel.basicConsume(task_queue_name,false,deliverCallback,(message->{
            System.out.println(message+"消费者取消消息回调");
        }));
    }
}

IeFxcF.png
在发送者发送消息dd,发出消息之后就把C2消费者停掉,按理说该C2来处理该消息了,但是由于它处理时间较长,在还未处理完,也就是说C2还没有执行ACK代码的时候,C2被停掉了,此时会看到消息被C1接收到了,说明消息dd被重新入队了,然后分配给能处理该消息的C1处理了。

7、RabbitMQ 持久化

7.1、概念

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

7.2、队列如何实现持久化

之前我们创建的队列都是非持久化的,RabbitMQ 如果重启的话,该队列就会被删除掉,如果要队列实现持久化,需要在声明队列的时候把 durable 参数设置为持久化

//让消息队队列持久化
boolean durable = true;
channel.queueDeclare(ACK_QUEUE_NAME,durable,false,false,null);

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

7.3、消息持久化

要想让消息实现持久化需要在消息生产者修改代码,MessageProperties.PERSISTENT_TEXT_PLAIN添加这个属性。

/**
 * 发送一个消息:
 * 1.发送到哪个交换机
 * 2.路由的key值  本次是队列的名称 根据routing key分发消息到队列中
 * 3.其他参数信息
 * 4.发送消息的消息体
 */
channel.basicPublish("",QUEUE_NAME,null,message.getBytes());

channel.basicPublish("",QUEUE_NAME,MessageProperties.PERSISTENT_TEXT_PLAIN,message.getBytes());

将消息标记为持久化并不能完全保证不会丢失消息。尽管它告诉 RabbitMQ 将消息保存到磁盘中,但是这里依然存在当消息刚准备存储在磁盘的时候,但是还没有存储完,消息还在缓存的一个间隔点。此时并没有真正的写入磁盘。持久性保证并不强,但是对于我们的简单任务队列而言,这已经绰绰有余了。如果需要更强有力的持久化策略,参考后边的发布确认章节。

7.4、不公平分发

在最开始的时候我们学习到 RabbitMQ分发消息采用的轮训分发,但是在某种场景下这种策略并不是很好,比方说有两个消费者在处理任务,其中有个消费者1处理任务的速度非常快,而另外一个消费者2处理速度却非常慢,这个时候,我们还是采用轮训分发的话就会了解到处理速度快的这个消费者1很大一部分时间都是处于空闲状态,而处理慢的那个消费者一直在干活,这种分配方式在这种情况下其实就不太好,但是 RabbitMQ 并不知道这种情况,它依然还是很公平的进行分发。

为了避免这种情况(即为了实现能者多劳),我们可以设置参数:channel.basicQos(1);

下面举个例子来证明不公平分发的实现:

生产者

public class Task02 {

    //队列名
    public static final String task_queue_name = "ack_queue";

    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        //声明一个队列
        channel.queueDeclare(task_queue_name,true,false,false,null);
        //从控制台中输入
        Scanner scanner=new Scanner(System.in);
        while (scanner.hasNext()){
            String message = scanner.next();
            channel.basicPublish("",task_queue_name,null,message.getBytes("UTF-8"));
        }

    }
}

消费者

/**
 * @author wcc
 * @date 2021/11/4 15:07
 * 消息在手动应答的时候是不丢失、放回队列中重新消费
 */
public class Worker03 {

    //队列名
    public static final String task_queue_name = "ack_queue";

    //接收消息
    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        System.out.println("C1等待接收消息处理时间较短");

        DeliverCallback deliverCallback = (consumeTag, message) -> {
            //沉睡1秒钟
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("接收到的消息:" + new String(message.getBody(), "UTF-8"));
            //手动应答策略
            /**
             * 1.消息的标记 tag 表示应答的是哪一个消息
             * 2.是否批量应答 false:表示不批量应答信道中的消息 true:表示批量
             */
            channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
        };

        int preCount = 1;
        channel.basicQos(preCount);

        //采用手动应答 第二个参数未是否采用自动应答
        channel.basicConsume(task_queue_name, false, deliverCallback, (message -> {
            System.out.println(message + "消费者取消消息回调");
        }));
    }
}

/**
 * @author wcc
 * @date 2021/11/4 15:07
 * 消息在手动应答的时候是不丢失、放回队列中重新消费
 */
public class Worker04 {

    //队列名
    public static final String task_queue_name = "ack_queue";

    //接收消息
    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        System.out.println("C2等待接收消息处理时间较长");

        DeliverCallback deliverCallback = (consumeTag, message) -> {
            //沉睡1秒钟
            try {
                Thread.sleep(10000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("接收到的消息:" + new String(message.getBody(), "UTF-8"));
            //手动应答策略
            /**
             * 1.消息的标记 tag 表示应答的是哪一个消息
             * 2.是否批量应答 false:表示不批量应答信道中的消息 true:表示批量
             */
            channel.basicAck(message.getEnvelope().getDeliveryTag(), false);
        };

        int preCount = 1;
        channel.basicQos(preCount);

        //采用手动应答 第二个参数未是否采用自动应答
        channel.basicConsume(task_queue_name, false, deliverCallback, (message -> {
            System.out.println(message + "消费者取消消息回调");
        }));
    }
}

测试结果:
IeG3e1.png
IeGYFK.pngIeGaSe.pngRabbitMQ的工作流程:意思就是如果这个任务我还没有处理完或者我还没有应答你,你先别分配给我,我目前只能处理一个任务,然后 RabbitMQ 就会把该任务分配给没有那么忙的那个空闲消费者,当然如果所有的消费者都没有完成手上的任务,队列还在不停的添加新的任务,队列有可能就会遇到队列被撑满的情况,这个时候就只能添加新的 worker 或者改变其他存储任务的策略。

7.4.1、预取值

本身消息的发送就是异步的,所以在任何时候,Channel 上肯定不止只有一个消息,另外,来自消费者的手动确认本质上也是异步的。因此这里本身就存在一个未确认的消息缓冲区,因此希望开发人员能限制此缓冲区的大小,以避免缓冲区里面无限制的未确认消息问题。这个时候就可以通过使用 basic.qos 方法设置预取计数值来完成的。该值定义通道上允许的未确认消息最大数量。一旦数量达到配置的数量,RabbitMQ 将停止在通道上传递更多的消息,除非至少有一个未处理的消息被确认,例如:假设在通道上有未确认的消息5、6、7、8,并且通道的预取计数设置为4,此时 RabbitMQ 将不会在该通道上再传递任何未确认的消息5、6、7、8,并且通道的预取计数设置位4,此时RabbitMQ将不会在该通道上再传递任何消息,除非至少有一个未应答的消息被ACK。比方说, tag = 6 这个消息刚刚被确认ACK,RabbitMQ 将会感知这个情况并再发送一条消息。消息应答和 QoS 预取值对用户吞吐量有重大影响。通常,增加预取将提高向消费者传递消息的速度。虽然自动应答传输效率是最佳的,但是,在这种情况下已传递但尚未处理的消息数量也会增加,从而增加了消费者的 RAM 消耗(随机存取存储器),应该小心使用具有无限预处理的自动确认模式或者手动确认模式,消费者消费了大量的消息如果没有确认的话,会导致消费者连接节点的内存消耗变大,所以找到合适的预取值是一个反复试验的过程,不同的负载取值也不同,100到300之间范围内的值通常可以提供最佳的吞吐量,并且不会给消费者带来太大的风险。预取值为1是最保守的。当然这将使得吞吐量变得很低,特别是消费者连接延迟很严重的情况下,特别是在消费者连接等待时间较长的环境中。对于大多数应用来说,稍微高一点的值将是最佳的。

7.5、发布确认

7.5.1、发布确认原理

生产者将信道设置成 Confirm 模式,一旦信道进入 Confirm 模式,所有在该信道上面发布的消息都将会被指派一个唯一的ID(从1开始),一旦消息被投递到所有匹配的队列之后,broker 就会发送一个确认给生产者(包含消息的唯一 ID),这就使得生产者知道消息已经正确到达目的队列了,如果消息和队列是可持久化的,那么确认消息会在消息写入磁盘之后发出,Broker 回传 basci.ack 的 multiple 域,表示到这个序列号之前的所有消息都已经得到了处理。

Confirm 模式最大的好处在于他是异步的,一旦发布一条消息,生产者应用程序就可以在等信道返回确认的同时继续发送下一条消息,当消息最终得到确认之后,生产者应用便可以通过回调方法来处理该确认消息,如果 RabbitMQ 因为自身内部错误导致消息丢失,就会发送一条 nack 消息,生产者应用程序同样可以在回调方法中处理该 nack 消息。
InqHeK.png

7.5.2、单个发布确认

这是一种简单的确认方式,它是一种同步发布确认的方式,也就是发布一个消息之后只有它被发布确认,后续的消息才能继续发布,waitForConfirmsOrDie(long)这个方法只有在消息被确认的时候才返回,如果在指定时间范围内这个消息没有被确认那么它将抛出异常。

这种确认方式有一个最大的缺点就是:发布速度特别的慢,因为如果没有发布确认的消息就会阻塞所有后续消息的发布,这种方式最多提供每秒不超过数百条发布消息的吞吐量。当然对于某些应用程序来说这可能已经足够了。

//单个发布确认
public static void publishMessageIndividually() throws Exception{
    Channel channel = RabbitMQUtils.getChannel();
    //队列的声明
    String queue_name = UUID.randomUUID().toString();
    channel.queueDeclare(queue_name,true,false,false,null);

    //开启单个发布确认模式
    channel.confirmSelect();
    //开始的时间
    Long  begin=System.currentTimeMillis();

    for (int i = 0; i < MESSAGE_COUNT; i++) {
        String message=i+" ";
        channel.basicPublish("",queue_name,null,message.getBytes());
        //单个消息马上就进行发布确认
        boolean b = channel.waitForConfirms();
        if(b){
            System.out.println("消息发送成功"+(i+1));
        }
    }

    //结束时间
    Long end=System.currentTimeMillis();
    System.out.println("发布"+MESSAGE_COUNT+"条单个确认消息,耗时:"+(end-begin));
}

InxZqI.png

7.5.3 批量发布确认

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

//批量发布确认
public static void publishMessageBatch() throws Exception{
    Channel channel = RabbitMQUtils.getChannel();
    //队列的声明
    String queue_name = UUID.randomUUID().toString();
    channel.queueDeclare(queue_name,true,false,false,null);

    //开启单个发布确认模式
    channel.confirmSelect();
    //开始的时间
    Long  begin=System.currentTimeMillis();

    int batchSize=100;

    for (int i = 1; i <= MESSAGE_COUNT; i++) {
        String message=i+" ";
        if(i%batchSize==0){
            channel.waitForConfirms();
            System.out.println("消息发送成功"+i);
        }
    }

    //结束时间
    Long end=System.currentTimeMillis();
    System.out.println("发布"+MESSAGE_COUNT+"条单个确认消息,批量确认耗时:"+(end-begin));
}

IuAtc6.png

7.5.4、异步发布确认

异步发布确认虽然编程逻辑上比以上两个同步的发布确认要复杂,但是性价比是最高,无论是可靠性还是效率都没得说,它是利用回调函数来达到消息可靠性传递的,这个中间件也是通过函数回调来保证是否投递成功。
IuepCj.png

//异步发布确认
public static void publishMessageAsync() throws Exception{
    Channel channel = RabbitMQUtils.getChannel();
    //队列的声明
    String queue_name = UUID.randomUUID().toString();
    channel.queueDeclare(queue_name,true,false,false,null);

    //开启单个发布确认模式
    channel.confirmSelect();
    //开始的时间
    Long  begin=System.currentTimeMillis();

    //消息确认成功回调
    /**
     * 1.确认的消息标识
     * 2.是否批量处理
     */
    ConfirmCallback var1 = (deliveryTag,multiple) ->{
        System.out.println("确认的消息:"+deliveryTag);
    };

    //消息确认失败回调
    /**
     * 1.消息的标识
     * 2.是否未批量处理
     */
    ConfirmCallback var2 = (deliveryTag,multiple) ->{
        System.out.println("未确认的消息:"+deliveryTag);
    };

    //准备消息的监听器 监听哪些消息成功了,哪些消息失败了
    /**
     * 1.监听哪些消息成功了进行回调
     * 2.监听哪些消息失败了进行回调
     */
    channel.addConfirmListener(var1,var2);

    //批量发送消息
    for (int i = 0; i < MESSAGE_COUNT; i++) {
        String message=i+" ";
        channel.basicPublish("",queue_name,null,message.getBytes());
    }

    //结束时间
    Long end=System.currentTimeMillis();
    System.out.println("发布"+MESSAGE_COUNT+"条异步发布确认消息,耗时:"+(end-begin));
}

IuKZO1.png

这里会出现一些问题,异步发送确认的时候,当消息发送完以后会出现确认还未结束,此时后面就是异步未确认消息,该如何处理呢?

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

//异步发布确认
public static void publishMessageAsync() throws Exception{
    Channel channel = RabbitMQUtils.getChannel();
    //队列的声明
    String queue_name = UUID.randomUUID().toString();
    channel.queueDeclare(queue_name,true,false,false,null);

    //开启单个发布确认模式
    channel.confirmSelect();
    //开始的时间
    Long  begin=System.currentTimeMillis();

    //线程安全有序的一个哈希表,适用于高并发的情况下
    /**
     * 1.轻松的将序号与消息进行关联
     * 2.轻松的批量删除条目 只要给到序号
     * 3.支持高并发操作
     */
    ConcurrentSkipListMap<Long,String> concurrentSkipListMap = new ConcurrentSkipListMap();


    //消息确认成功回调
    /**
     * 1.确认的消息标识
     * 2.是否批量处理
     */
    ConfirmCallback var1 = (deliveryTag,multiple) ->{
        if(multiple){
            //删除掉已经确认的消息,剩下的就是未确认的消息
            //这里对headMap(int) 返回此映射的部分视图,其键值严格小于等于tokey
            ConcurrentNavigableMap<Long, String> confirmed =
                    concurrentSkipListMap.headMap(deliveryTag);
            //clear():从此映射中移除所有映射关系
            confirmed.clear();
        }else{
            concurrentSkipListMap.remove(deliveryTag);
        }
        System.out.println("确认的消息:"+deliveryTag);
    };

    //消息确认失败回调
    /**
     * 1.消息的标识
     * 2.是否未批量处理
     */
    ConfirmCallback var2 = (deliveryTag,multiple) ->{
        String message = concurrentSkipListMap.get(deliveryTag);
        System.out.println("未确认的消息是:"+message+":::未确认的消息tag:"+deliveryTag);
    };

    //准备消息的监听器 监听哪些消息成功了,哪些消息失败了
    /**
     * 1.监听哪些消息成功了进行回调
     * 2.监听哪些消息失败了进行回调
     */
    channel.addConfirmListener(var1,var2);

    //批量发送消息
    for (int i = 0; i < MESSAGE_COUNT; i++) {
        //此处发送消息的时候记录下所有要发送的消息 消息的总和
        String message=i+" ";
        concurrentSkipListMap.put(channel.getNextPublishSeqNo()-1,message);
        channel.basicPublish("",queue_name,null,message.getBytes());
    }

    //结束时间
    Long end=System.currentTimeMillis();
    System.out.println("发布"+MESSAGE_COUNT+"条异步发布确认消息,耗时:"+(end-begin));
}

7.5.5、以上三种发布确认速度对比

  • 单独发布消息
    • 同步等待确认,简单,但是吞吐量非常有限
  • 批量发布消息
    • 批量同步等待确认,简单,合理的吞吐量,一旦出现问题但很难推断出是哪条消息出现了问题。
  • 异步处理
    • 最佳资源和性能使用,在出现错误的情况下可以很好地控制,但是实现i起来稍微复杂。

8、Exchanges(交换机)

我们创建了一个队列,我们假设是工作队列地背后,每个任务都恰好交付给一个消费者(工作进程)。在这一部分中,我们将做一些完全不同地事情 - 我们将消息传达给多个消费者。这种模式称为 “发布 / 订阅”
ItsiPH.png
ItsAxI.png

8.1、概念

RabbitMQ 消息传递模型的核心思想是:生产者生产的消息从不会直接发送到队列。实际上,通常生产者甚至都不知道这些消息传递传递到了哪些队列中。

相反,生产者只能将消息发送到交换机(Exchange),交换机工作的内容非常简单,一方面它接收来自生产者的消息,另一方面将它们推入队列。交换机必须确切的知道如何处理收到的消息。是应该把这些消息放到特定队列还是说把它们放到许多队列中还是说应该丢弃它们。这就由交换机的类型来决定。

8.2、Exchanges 的类型

总共有以下类型:
直接(direct)、主题(topic)、标题(headers)、扇出(fanoyt)

8.2.1、默认交换机

在我们向消费者发送消息的时候不设置交换机的时候,但是仍然能够将消息发送到队列。所使用的交换机就是默认交换机,通过空字符串("")进行标识

channel.basicPublish("",queue_name,null,message.getBytes());

第一个参数是交换机的名称。空字符串表示默认或者无名称交换机:消息能够路由发送到队列中其实是由 **routingKey(bindingKey)**绑定key指定的,如果它存在的话

8.2.2、临时队列

之前的例子中我们使用的是具有特定名称的队列(还记得 hello 和 ack_queue吗?)。队列的名称对我们来说至关重要 – 我们需要指定我们的消费者去消费哪个队列的消息。

每当我们连接到 RabbitMQ 的时候,我们都需要一个全新的空队列,为此我们可以创建一个具有随机名称的队列,或者能让服务器为我们选择一个随机队列名称那就更好了。其次一旦我们断开了消费者的连接,队列将被自动删除

8.2.3、绑定(bindings)

什么是绑定呢?Bindbings,bindings 其实是 exchange 和 queue 之间的桥梁,它告诉我们 exchange 和哪个队列进行了绑定关系。

IUxQfO.png

8.3、Fanout(散出交换机)

Fanout 这种类型非常简单。正如从名称中猜到的那样,它是将接收到的所有消息广播到它知道的所有队列中。系统中默认有些 exchange 类型。
IUzFEt.png

什么叫做消息幂等性?

当出现消费者对某条消息重复消费的情况的时候,重复消费的结果与消费一次的结果是相同的,并且多次消费并未对业务系统产生任何负面影响,那么这整个过程就可实现消息幂等

生产者

/**
 * @author wcc
 * @date 2021/11/10 17:54
 * 发消息给交换机
 */
public class EmitLog {

    //交换机的名称
    public static final String EXCHANGE_NAME="logs";

    public static void main(String[] args) throws IOException, TimeoutException {

        Channel channel = RabbitMQUtils.getChannel();

        channel.exchangeDeclare(EXCHANGE_NAME,"fanout");

        Scanner sc =new Scanner(System.in);
        while (sc.hasNext()){
            String message = sc.next();
            /**
             * 第一个参数:交换机名称
             * 第二个参数:routing key
             * 第三个参数:其他配置信息
             * 第四个参数:消息数据
             */
            channel.basicPublish(EXCHANGE_NAME,"",null,message.getBytes());
            System.out.println("生产者发出的消息为:"+message);
        }
    }
}

消费者01的代码:

/**
 * @author wcc
 * @date 2021/11/10 15:44
 * 消息的接收
 */
public class ReceiveLogs01 {

    //交换机的名称
    public static final String EXCHANGE_NAME="logs";

    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        //声明一个交换机
        channel.exchangeDeclare(EXCHANGE_NAME,"fanout");

        //声明一个队列 临时队列
        /**
         * 生成一个临时的队列、队列的名称是随机的
         * 当消费者断开与队列的连接的时候 队列就自动删除了
         */
        String queue = channel.queueDeclare().getQueue();

        //绑定交换机与队列
        channel.queueBind(queue,EXCHANGE_NAME,"");

        System.out.println("ReceiveLogs01等待接收消息,把接收消息打印在屏幕上....");


        DeliverCallback deliverCallback=(consumeTag,message)->{
            System.out.println("ReceiveLogs01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
        };

        channel.basicConsume(queue,true,deliverCallback,consumeTag->{});
    }
}

消费者02的代码:

/**
 * @author wcc
 * @date 2021/11/10 15:44
 * 消息的接收
 */
public class ReceiveLogs02 {

    //交换机的名称
    public static final String EXCHANGE_NAME="logs";

    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        //声明一个交换机
        channel.exchangeDeclare(EXCHANGE_NAME,"fanout");

        //声明一个队列 临时队列
        /**
         * 生成一个临时的队列、队列的名称是随机的
         * 当消费者断开与队列的连接的时候 队列就自动删除了
         */
        String queue = channel.queueDeclare().getQueue();

        //绑定交换机与队列
        channel.queueBind(queue,EXCHANGE_NAME,"");

        System.out.println("ReceiveLogs02等待接收消息,把接收消息打印在屏幕上....");


        DeliverCallback deliverCallback=(consumeTag,message)->{
            System.out.println("ReceiveLogs02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
        };

        channel.basicConsume(queue,true,deliverCallback,consumeTag->{});
    }
}

结果如下:
IajPdx.pngIajAJO.pngIajEWD.png](https://imgtu.com/i/IajEWD)

8.4、Direct exchange (直接交换机)

上一个我们的日志系统将所有的消息广播给所有消费者,对此我们想做出一些改变,例如我们希望将日志消息写入磁盘的程序仅仅接收严重错误(errors),而不存储哪些警告(warning)或者信息(info)日志消息避免浪费磁盘空间。Fanout这种交换类型并不能给我们带来很大的灵活性,它只能进行无意识的广播,在这里我们将使用 direct 这种类型来进行替换,这种类型的工作方式是,消息只能去到它绑定的 routingKey 队列中去。

IaxEKH.png

在上面这种图中,我们可以看到 交换机X 绑定了两个队列,绑定类型是 direct 。队列 Q1 绑定键为 orange,队列Q2绑定键有两个:一个绑定键位 black,另一个绑定键为 green。

在这种绑定情况下,生产者发布消息到 exchange 上,绑定键为 orange 的消息会被发布到队列Q1,绑定键为 black 和 green 的消息会被发布到队列 Q2,其他消息类型的消息将被丢弃。

直接交换机还支持多重绑定

IaxosH.png

当然如果 exchange 的绑定类型是 direct ,但是它绑定的多个队列的 key 如果都相同,在这种情况下虽然绑定类型是 direct 但是它所表现的就和 fanout(散出)有点类似了,就跟广播差不多了。

代码演示:

/**
 * @author wcc
 * @date 2021/11/11 10:16
 * 生产者
 */
public class DirectLogs {

    //交换机的名称
    public static final String EXCHANGE_NAME = "direct_logs";

    public static void main(String[] args) throws IOException, TimeoutException {

        Channel channel = RabbitMQUtils.getChannel();

        Scanner scanner=new Scanner(System.in);

        while (scanner.hasNext()){
            String message=scanner.next();
            /**
             * 第一个参数:交换机的名称
             * 第二个参数:routing key
             * 第三个参数:其他配置信息
             * 第四个参数:消息数据
             */
            channel.basicPublish(EXCHANGE_NAME,"error",null,message.getBytes("UTF-8"));
            System.out.println("生产者发送消息:"+message);
        }

    }
}

注意,这里要想实现直接发送的特征,只需要更改 生产者发送消息的 routingKey 即可,以此来对应不同的消费者。(一个消费者还可以支持多重绑定,即一个消费者的可以多次绑定同一个队列并设置不同的 routingKey 以此来达到多重绑定的效果)。

/**
 * @author wcc
 * @date 2021/11/10 21:30
 * 消费者1
 */
public class ReceiveLogsDirect01 {

    public static final String EXCHANGE_NAME="direct_logs";

    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        //声明一个交换机
        channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);

        //声明一个队列
        channel.queueDeclare("console", false, false, false, null);

        /**
         * 绑定交换机与队列
         */
        channel.queueBind("console",EXCHANGE_NAME,"info");
        channel.queueBind("console",EXCHANGE_NAME,"warning");

        DeliverCallback deliverCallback=(consumeTag, message)->{
            System.out.println("ReceiveLogsDirect01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
        };

        //第二个参数代表是否自动应答
        channel.basicConsume("console",true,deliverCallback,consumeTag->{});

    }
}
/**
 * @author wcc
 * @date 2021/11/10 21:30
 * 消费者2
 */
public class ReceiveLogsDirect02 {

    public static final String EXCHANGE_NAME="direct_logs";

    public static void main(String[] args) throws IOException, TimeoutException {
        Channel channel = RabbitMQUtils.getChannel();

        //声明一个交换机
        channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT);

        //声明一个队列
        channel.queueDeclare("disk", false, false, false, null);

        /**
         * 绑定交换机与队列
         */
        channel.queueBind("disk",EXCHANGE_NAME,"error");

        DeliverCallback deliverCallback=(consumeTag, message)->{
            System.out.println("ReceiveLogsDirect02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
        };

        //第二个参数代表是否自动应答
        channel.basicConsume("disk",true,deliverCallback,consumeTag->{});

    }
}

8.5、主题交换机(Topic)

在上一个例子中,我们改进了日志记录系统。我们没有使用只能进行随意广播的 fanout 交换机,而是使用了 direct 交换机,从而能实现有选择性的接受日志。

尽管使用 direct 交换机改进了我们的系统,但是它仍然存在局限性 - 比方说我们想接收的日子类型有 info.baseinfo.advantage,某个队列只想要接收 info.base 的消息,那这个时候 direct 就办不到了。这个时候就出现了 topic类型 的交换机。

发送到类型是 topic 交换机的消息的 routingKey 不能随意写,必须满足一定的要求,它必须是一个单词列表,以点号分隔开。这些单词可以是任意单词,比如说:stock.usd.nysenyse.vmw当然注意这个单词列表最多不能超过 255 个字节

在这个规则列表中,其中有两个替换符是大家需要注意的:

  • *(星号)可以代替一个单词
  • #(井号)可以代替零个或者多个单词

当队列绑定关系是下列这种情况的时候需要引起注意:

  • 当一个队列绑定键是 # ,那么这个队列将接收所有的数据,就有点像 fanout 了
  • 如果队列绑定键当中没有 # 和 * 出现,那么该队列绑定类型就是 direct 了

IdjOZn.png

生产者代码

/**
 * @author wcc
 * @date 2021/11/11 11:27
 * 生产者
 */
public class EmitLogsTopic {

    //交换机的名称
    public static final String EXCHANGE_NAME = "topic_logs";

    public static void main(String[] args) throws IOException, TimeoutException {

        Channel channel = RabbitMQUtils.getChannel();

        /**
         * 与消费者的绑定关系为:
         * Q1 --> 绑定的是
         *  中间带 orange 带3个单词的字符串(*.orange.*)
         * Q2 --> 绑定的是
         *  最后一个单词是 rabbit 的3个单词(*.*.rabbit)
         *  第一个单词是 lazy 的多个单词(lazy.#)
         */
        Map<String,String> bindingMap = new HashMap<>();
        bindingMap.put("quick.orange.rabbit","被队列Q1Q2接收到");
        bindingMap.put("lazy.orange.elephant","被队列Q1Q2接收到");
        bindingMap.put("quick.orange.fox","被队列Q1接收到");
        bindingMap.put("lazy.brown.fox","被队列Q2接收到");
        bindingMap.put("lazy.pink.rabbit","虽然满足两个绑定但只被队列Q2接收一次");
        bindingMap.put("quick.brown.fox","不匹配任何绑定不会被任何队列接收到会被丢弃");
        bindingMap.put("quick.orange.male.rabbit","是四个单词但不匹配任何绑定会被丢弃");
        bindingMap.put("lazy.orange.male.rabbit","是四个单词但匹配Q2");

        for (Map.Entry<String, String> entry : bindingMap.entrySet()) {
            String key = entry.getKey();
            String message = entry.getValue();
            channel.basicPublish(EXCHANGE_NAME,key,null,message.getBytes("UTF-8"));
            System.out.println("生产者发出消息:"+key+":"+message);
        }
    }
}

消费者01代码

/**
 * @author wcc
 * @date 2021/11/11 11:15
 * 声明主题交换机以及相关队列
 * 消费者1
 */
public class ReceiveLogsTopic01 {

    //交换机名称
    public static final String EXCHANGE_NAME = "topic_logs";

    public static void main(String[] args) throws IOException, TimeoutException {

        //接收消息
        Channel channel = RabbitMQUtils.getChannel();

        //声明交换机
        channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.TOPIC);

        //声明队列
        channel.queueDeclare("Q1",false,false,false,null);

        /**
         * 第一个参数:队列名
         * 第二个参数:交换机名字
         * 第三个参数:routingKey
         */
        channel.queueBind("Q1",EXCHANGE_NAME,"*.orange.*");

        System.out.println("ReceiveLogsTopic01等待接收消息...");

        DeliverCallback deliverCallback=(consumeTag, message)->{
            System.out.println("ReceiveLogsTopic01控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
            System.out.println("接收队列:"+"Q1"+" 绑定键:"+message.getEnvelope().getRoutingKey());
        };

        //第二个参数代表是否自动应答
        channel.basicConsume("Q1",true,deliverCallback,consumeTag->{});
    }
}

消费者02代码

/**
 * @author wcc
 * @date 2021/11/11 11:15
 * 声明主题交换机以及相关队列
 * 消费者2
 */
public class ReceiveLogsTopic02 {

    //交换机名称
    public static final String EXCHANGE_NAME = "topic_logs";

    public static void main(String[] args) throws IOException, TimeoutException {

        //接收消息
        Channel channel = RabbitMQUtils.getChannel();

        //声明交换机
        channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.TOPIC);

        //声明队列
        channel.queueDeclare("Q2",false,false,false,null);

        /**
         * 第一个参数:队列名
         * 第二个参数:交换机名字
         * 第三个参数:routingKey
         */
        channel.queueBind("Q2",EXCHANGE_NAME,"*.*.rabbit");
        channel.queueBind("Q2",EXCHANGE_NAME,"lazy.#");

        System.out.println("ReceiveLogsTopic02等待接收消息...");

        DeliverCallback deliverCallback=(consumeTag, message)->{
            System.out.println("ReceiveLogsTopic02控制台打印接收到的消息:"+new String(message.getBody(),"UTF-8"));
            System.out.println("接收队列:"+"Q2"+" 绑定键:"+message.getEnvelope().getRoutingKey());
        };

        //第二个参数代表是否自动应答
        channel.basicConsume("Q2",true,deliverCallback,consumeTag->{});
    }
}

测试结果如下:
Iwkxvq.png
IwASK0.pngIwAF54.png至此,算是 RabbitMQ 入门结束,高级部分再一篇文章中会更新。

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值