方亮的专栏

Stream队列保存了发布到其上所有未过期（时间或Size判断）的消息。消费者只可以读取该队列，但是不能让队列将已读消息删除。这样就可以保证相同配置的消费者可以读取到相同的消息。鉴于它保留了未过期消息，所以非常适合需要读取历史消息的场景。鉴于消费者不能让其删除已读消息，所以对于需要“扇出”大量相同消息的场景，可以使用一个Stream来替代Fanout交换器绑定多个相同消息队列的方案。这样即可以降低系统设计的复杂度，也会提升Rabbitmq服务效率。

在一文中，我们搭建了Tom和Jerry两人的聊天服务。在这个服务中，它们都向Fanout交换器发送消息。而Fanout会将消息路由到它们两各自监听的队列。这样它们就可以得到全部消息。如果是多人聊天，比如10个人聊天，按上述方案，需要Fanout交换器绑定10个队列。这就会使得结构变得非常复杂。这是因为Classic类型队列在消费者确认读取消息后，会将消息从队列中删除。这样就需要我们使用fanout向多个队列路由消息，以供不同消费者消费。

direct交换器以及其绑定规则fanout交换器自动删除的交换器自动删除的队列只有一个消费者的队列WebFlux响应式编程。

在之前的案例中，我们在管理后台收发消息都是通过短连接的形式。本文我们将探索对队列中消息的实时读取，并通过流式数据返回给客户端。webflux是反应式Web框架，客户端可以通过一个长连接和服务端相连，后续服务端可以通过该连接持续给客户端发送消息。可以达到：发送一次，多次接收的效果。

临时队列是一种自动删除队列。当这个队列被创建后，如果没有消费者监听，则会一直存在，还可以不断向其发布消息。但是一旦的消费者开始监听，然后断开监听后，它就会被自动删除。

如果队列指定TTL，消息也设置了TTL，取最接近当前时间的TTL。即用最短的那一个。

在一些业务场景中，我们只需要保存最近的若干条消息，这个时候我们就可以使用“最大长度队列”来满足这个需求。该队列在收到消息后，如果达到长度上限，会将队列头部（最早的）的信息从队列中移除。在进行实验之前，我们先创建一个交换器direct.max.length，用于接收消息。

但是现实中，可能存在这样的场景：一些队列所在的机器配置较好，一些队列所在的机器配置较差。这个时候，我们希望配置较好的机器可以分发更多的消息，而配置较差的队列分发相对较少的消息。这样我们就需要让转换器，将消息更多的路由到配置好的机器所在的队列上。中实操的基础上，我们修改了绑定关系（Banding）中路由到named_queue_b队列的权重——9。现在我们假设队列named_queue_b所在的机器配置较好，希望它承载更多的消息。我们在队列页面可以看到named_queue_b被路由了80%消息。

我们可以把交换器看成消息发布的入口，而消息投递规则则是由“绑定关系”（Banding）来定义，最终消息会被路由到“绑定关系”指定的队列中。我们可以把队列看成这个过程的出口。RabbitMQ还实现了一种非常有意思的“绑定关系”（Banding），我们可以让其出口不再是队列，而是另外一个交换器。这样，如果给amq.direct交换器发送的的消息的Routing key是to_all，则消息会被路由到amq.fanout交换器，然后通过它扇出。一文的案例，给amq.direct交换器新增一个绑定关系。

在中，我们熟悉了Direct、Fanout、Topic和Header这4种系统默认支持的交换器。这些交换器基本可以满足我们日常的需求。我们还可以添加一些设计，让其支持更加丰富的功能。比如我们可以通过Topic的设计，达到“负载均衡”的功能。如果不想做这样的设计，可以使用RabbitMQ自身携带，只是未开启的一致性Hash交换器，来实现对队列的平均分流。这样我们让更多消费者订阅不同的队列，来增加整理系统的处理能力。

在一文中，我们使用备用交换器来处理当前交换器不可路由的消息。这类消息的异常往往出现在Routing key这类会影响路由的字段上，而如果消息体自身有问题——结构不符合业务约定、某个字段值不合法，则怎么处理呢？是抛弃还是让其继续保留在队列中？上述两种方式都不太好：如果抛弃则会让我们丧失分析异常的机会；如果保留在队列中则会堆积，影响后续处理效率。RabbitMQ提供了死信机制来辅助我们处理这类消息。其基本原理就是在业务逻辑判断这些消息存在异常的情况下，让这些消息路由到另外一个独立的队列中。

在实际工作中，我们往往可能因为代码逻辑的一些问题导致发布的消息无法被路由，比如写错了Routing key。那么这个时候，RabbitMQ可能会拒绝接收，还可以通过其他机制把它收集起来。本文我们将探讨这类问题的处理方法。一般我们默认创建的交换器都是没有备用（Alternate）交换器的。我们给新建的交换器取名：direct.without.alternate。然后创建一个名字叫direct_queue的队列最后创建它们的绑定关系。Routing key是to.direct.queue。Rabbit

在之前的章节中，我们基本都是在管理后台创建“队列”（Queue）、“交换器”（Exchange）和“绑定关系”（Banding）。实际上，我们还可以在代码中完成这些功能。这些行为我们可以通过RabbitMQ提供的“事件交换器”（Event Exchange）来监控这些行为。事件交换器（Event Exchange）是一个Topic类型的交换器。向它发送消息的是RabbitMQ服务。我们可以定义一个队列来接收这些消息，然后定义一个消费者来读取该队列，完成监控功能。

在中，我们使用了Consistent Hash Exchange实践了消息路由的负载均衡。本文我们将使用一种更简单的交换器来实现该功能，这就是“随机交换器”（Random Exchange）。

在一文中，我们熟悉了一致性Hash交换器的使用方法。默认的，它使用Routing key来做Hash的判断源。但是有些时候，Routing key会有其他作用。比如在Exchange绑定Exchange时，部分Exchange就对Routing key有很强的限制。这种时候，我们就可以通过自定义路由字段来避开对Routing key的依赖。

在队列页面，我们看到named_queue_a、named_queue_c各有一条消息，而named_queue_b则没有，因为我们没有发送Routing key为named_queue_b的消息到默认交换器。比如Routing key是a.a.a的消息，它匹配了a.#、#.a.#和#.a这些规则。由于named_queue_a、named_queue_c这两个队列存在，所以在发送Routing key为named_queue_a、named_queue_c的消息时，会看到如下提示。

在中，我们在管理后台实践了消息的生产、发送和接收功能。本文我们将使用Springboot框架，实现RabbitMQ消息的收发功能。

我们搭建完RabbitMQ服务以及管理后台。本文我们将管理后台，进行一次简单的消息收发实验。

在中我们已经安装成功RabbitMQ及其管理后台。在此基础上，我们将打通它和Prometheus、Grafana的通信，完成对RabbitMQ的可视化监控。

RabbitMQ是一款功能强大、灵活可靠的消息代理软件，为分布式系统中的通信问题提供了优秀的解决方案。无论是在大规模数据处理、实时分析还是微服务架构中，RabbitMQ都能发挥出色的性能，帮助开发者构建高效、稳定的系统。本系列我们将基于Java技术栈，探索RabbitMQ的一些使用。