RabbitMQ学习

什么是MQ？

MQ（message queue，消息队列），从字面意思上看，本质是个队列，特点是FIFO （先入先出），只不过队列中存放的内容是 message 而已，还是一种跨进程的通信机制，用于上下游传递消息。在互联网架构中，MQ是一种非常常见的上下游「逻辑解耦 + 物理解耦」的消息通信服务。使用了 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。 o 综上所诉，MQ（Message Queue）是一种用于消息传输的软件架构，通常用于在分布式系统中传输数据或消息，解决系统间的异步通信问题。 o 个人理解：MQ是一个存放消息的容器，这个容器符合FIFO的特点，即生产者生产消息，将消息放入MQ中，然后消费者从MQ中取消息，存和取满足先进先出原则

RabbitMQ的特点

可靠性。支持持久化，传输确认，发布确认等保证了MQ的可靠性。

o 灵活的分发消息策略。这应该是RabbitMQ的一大特点。在消息进入MQ前由Exchange(交换机)进行路由消息。分发消息策略有：简单模式、工作队列模式、发布订阅模式、路由模式、通配符模式。

o 支持集群。多台RabbitMQ服务器可以组成一个集群，形成一个逻辑Broker。

o 多种协议。RabbitMQ支持多种消息队列协议，比如 STOMP、MQTT 等等。

o 支持多种语言客户端。RabbitMQ几乎支持所有常用编程语言，包括 Java、.NET、Ruby 等等。 o 可视化管理界面。RabbitMQ提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker。

o 插件机制。RabbitMQ提供了许多插件，可以通过插件进行扩展，也可以编写自己的插件。

RabbitMQ的整体架构是怎么样的？

RabbitMQ是一个开源的消息中间件，用于在应用程序之间传递消息。它实现了AMQP（高级消息队列协议）并支持其他消息传递协议，例如STOMP（简单文本定向消息协议）和MQTT（物联网协议）。

他的整体架构大致如下：

• 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-subscribe) and fanout (multicast)
• Queue：队列。消息最终被送到这里等待 consumer 取走
• Binding：绑定。exchange 和 queue 之间的虚拟连接，binding 中可以包含 routing key，Binding 信息被保 存到 exchange 中的查询表中，用于 message 的分发依据

RabbitMQ是怎么做消息分发的？

典型回答 rabbitMQ一共有6种工作模式（消息分发方式）分别是简单模式、工作队列模式、发布订阅模式、路由模式、主题模式以及RPC模式。

简单模式（Simplest Mode）：也称为基本模式（Basic Mode），是最简单的模式。它只包含一个生产者、一个消费者和一个队列。生产者将消息发送到队列，消费者从队列中接收消息。

工作队列模式（Work Queues Mode）：也称为任务分发模式（Task Distribution Mode），它包含多个消费者和一个共享队列。生产者将消息发送到共享队列，多个消费者从队列中接收消息并进行处理。工作队列模式可以用于在分布式系统中进行任务分发和负载均衡。

发布/订阅模式（Publish/Subscribe Mode）：也称为广播模式（Broadcasting Mode），它包含一个生产者、多个消费者和一个交换机（Exchange）。生产者将消息发送到交换机，交换机将消息广播给所有已经绑定（Bind）到该交换机上的队列。发布/订阅模式可以用于实现广播消息和通知机制。

路由模式（Routing Mode）：它包含一个生产者、多个消费者、一个交换机和多个队列。生产者将消息发送到交换机，交换机根据消息的路由键（Routing Key）将消息路由到匹配的队列。路由模式可以用于实现消息的有选择性地传输和过滤。

主题模式（Topic Mode）：也称为通配符模式（Wildcard Mode），它包含一个生产者、多个消费者、一个交换机和多个队列。生产者将消息发送到交换机，交换机根据消息的主题（Topic）将消息路由到匹配的队列。主题模式可以用于实现消息的复杂路由和匹配。

RPC模式（Remote Procedure Call Mode）：它是一种高级模式，可以用于实现远程过程调用。它包含一个客户端、一个服务器和一个队列。客户端将请求消息发送到队列，服务器从队列中接收消息并进行处理，然后将响应消息发送回客户端。RPC模式可以用于实现分布式系统中的服务调用。

这几种模式，根据不同的场景可以用不同的模式，每种模式的发送方及接收方的代码都不太一样，有的简单，有的复杂， 具体实现可以参考：https://www.rabbitmq.com/getstarted.html

RabbitMQ的消息应答机制

消息应答

• 自动应答：是RabbitMQ默认的配置，消息发送后立即被认为已经传送成功，这种模式需要在高吞吐量和数据传输安全性方面做权衡。它没有额外的工作量，有更高的吞吐量（只要消费者能够跟上），但是存在消息丢失和消息积压的问题。如果消息队列一段时间突然接收大大量的消息，由于消费者消费不及时，以致于大量消息在消息队列中的堆积，从而导致内存耗尽；如果消息在传递到消息队列后发生了阻塞，此时由于消息发送后会被立即认为是发送成功，所以消费者中的连接或信道可能发生关闭，此时消息就无法被真正地消费，从而导致消息的丢失。 综上所诉，使用自动应答只适合在消费者消费消息高效，且消费者能保持稳定的消费速率 的情况下使用
• 手动应答：需要自己配置，需要在消费者捕获异常，并手动确认应答状态，是ack还是nack，但是不存在消息丢失和消息积压的问题

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

批量应答虽然效率很高，但不建议使用批量应答（也就是建议multiple设置为false），因为在批量应答的过程中容易发生消息丢失，在传输一些不太重要的但数量特别多消息时，可以使用批量应答 Channel.basicRecover：是否恢复消息到队列

// requeue是否重新加入队列，true 则重新入队列，并且尽可能的将之前 recover 的消息投递给其他消费者消费，而不是自己再次消费。false 则消息会重新被投递给自己 basicRecover(boolean requeue);

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

RabbitMQ如何实现延迟消息？

典型回答 RabbitMQ中是可以实现延迟消息的，一般有两种方式，分别是通过死信队列以及通过延迟消息插件来实现。

扩展知识

死信队列

当RabbitMQ中的一条正常的消息，因为过了存活时间（TTL过期）、队列长度超限、被消费者拒绝等原因无法被消费时，就会变成Dead Message，即死信。

当一个消息变成死信之后，他就能被重新