目录
一、消息中间件介绍
1.1 消息中间件的作用
二、RabbitMQ
2.1 核心概念
2.2 生产者发送消息过程
2.3 消费者接收消息过程
2.4 RabbitMQ 为何要引入信道(channel)
2.5 消费模式
一、消息中间件介绍
消息队列中间件（message queue middleWare, MQ）指利用高效可靠消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程通信。
一般有两种传递模式：点对点模式和发布订阅模式。点对点的模式是基于队列的，消息生产者发送消息到队列，消费者从队列中接收消息，队列的存在使得消息的异步传输成为可能。发布订阅模式定义了如何向一个内容节点发布和订阅，这个内容节点称为主题（topic），主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，消息订阅者从主题中订阅消息。
消息中间件将消息路由给应用程序B，这样消息可以完全存在于两台不同的计算机上。消息中间件负责网络通信，如果网络不可用，消息中间件会存储消息直到连接可用。
1.1 消息中间件的作用
解耦：生产者和消费者完全解耦，双方都感知不到对方的存在。
冗余（存储）：有些情况数据处理会失败，消息中间件可以把数据进行持久化，直到他们已经被完全处理。通过这种方式规避数据丢失的风险。
扩展性：因为消息中间件解藕了应用的处理过程，所以提高消息入队和处理的效率很容易。
削峰：在访问剧增的情况下，应用仍然需要继续发挥作用，但这种突发的流量并不常见，如果以处理峰值的标准来投入资源，无疑是巨大的浪费，使用消息中间件支撑突发的流量，不会因为超负荷请求而完全奔溃。
可恢复性：当系统的一部分组件失效时不影响整个系统。降低了应用间的耦合性，系统恢复后还能继续处理消息。
顺序保证：大多数场景下，顺序处理数据很重要，大部分消息中间件支持一定程度上的顺序性。
缓冲：在任何重要的系统中，都会存在需要不同处理时间的元素，消息中间件通过一个缓冲层来帮助任务最高效率的执行，写入消息中间件的处理尽可能的快。该缓冲层有助于控制和优化数据流经过系统的速度。
异步通信：很多时候不需要立即处理消息，消息中间件提供了异步处理机制。
二、RabbitMQ
RabbitMQ 是一个开源的消息中间件（Message Broker），遵循 Advanced Message Queuing Protocol (AMQP) 标准协议。它允许应用程序通过发送和接收消息来进行异步通信，从而实现系统之间的松耦合和解耦合。RabbitMQ 支持多种操作系统，广泛应用于分布式系统架构中，尤其是在微服务、异步处理、负载均衡、峰值负载处理、消息队列、事件驱动架构等领域。
rabbitMQ整体上是一个生产者与消费者模型，主要负责接收、存储和转发消息。整体结构架构图如下：
生产者：投递消息的一方。创建消息，然后投递到 RabbitMQ 中。消息一般包含两部分：消息体和标签（label）。消息体称为 payload，标签用来表述这条消息，比如一个交换器的名称和一个路由键。生产者把消息给 RabbitMQ，RabbitMQ 根据标签把消息发送给感兴趣的消费者。
消费者：接收消息的一方。消费者消费一条消息的时候，只是消费消息的消息体（payload）。在消息路由的过程中，消息的标签会丢弃，存入到队列中的消息只有消息体，消费者也只会消费消息体。
Broker：消息中间件的服务节点。一个 RabbitMQ Broker 可以简单地看作一个 RabbitMQ 服务节点，或者 RabbitMQ 服务实例。
2.1 核心概念
队列：用来存储消息，RabbitMQ 中消息只能存储在队列中。多个消费者可以订阅同一个队列，这时队列中的消息会被平均分摊（轮询）。
交换器：生产者将消息发送给交换器，由交换器将消息路由到一个或者多个队列中。如果路由不到，会返给消费者，或者直接丢弃。
RoutingKey：路由键，生产者将消息发送给交换器的时候，一般会指定一个 RoutingKey，用来指定这个消息的路由规则，而这个 RoutingKey 需要与交换器类型和绑定键（bindingKey）联合使用才能生效。RoutingKey 与 bindingKey 的值其实是同一个，但代表的意义不同
BindingKey：通过绑定将交换器和队列关联起来，在绑定的时候一般会指定一个绑定键（BindingKey），这样 RabbitMQ 就知道如何正确将消息路由到队列了。
RabbitMQ 中常用的交换器有四种，fanout、direct、topic、headers 这四种。AMQP 协议中还提到另外两种：system 和自定义。四种常用交换器如下：
fanout交换器：把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
direct交换器：把消息路由到那些 BindingKey 和 RoutingKey 完全匹配的队列中。
topic交换器：与 direct 相似，也是将消息路由到 BindingKey 和 RoutingKey 相匹配的队列中，但这里的匹配规则有些不同。有. * # 三个符号。
headers交换器：交换器不依赖于路由键的匹配规则，而是根据发送的消息内容中的 headers 属性进行匹配。性能较差，应用不多。
2.2 生产者发送消息过程
RabbitMQ 中生产者（Producer）发送消息的过程可以概括为以下几个步骤：
- 生产者连接到 broker，建立一个连接（connection），开启一个信道（channel）
- 生产者声明一个交换器，并设置相关属性，如交换器类型、是否持久化。
- 生产者声明一个队列并设置相关属性
- 生产者通过路由键将交换器和队列绑定起来
- 生产者发送消息至 broker，其中包括路由键交换器等信息
- 相应的交换器根据接收到的路由键查找匹配的队列
- 如果找到，则将从生产者发来的消息存入相应的队列中。
- 如果没找到，则根据生产者的配置选择丢弃还是回退给生产者
- 关闭信道
- 关闭连接
2.3 消费者接收消息过程
消费者消费消息的过程如下：
- 消费者连接到 broker，建立一个连接（connection）,开启一个信道（channel）
- 消费者向 broker 请求消费相应的队列中的消息，可能会设置相应的回调函数及一些准备工作。
- 等待 broker 回应并投递相应队列中的消息，消费者接收消息
- 消费者确认（ack）接收到的消息。
- RabbitMQ 从队列中删除相应已经被确认的消息
- 关闭信道，关闭连接。
2.4 RabbitMQ 为何要引入信道(channel)
客户端和 broker 建立的连接是 TCP 连接，一旦连接建立起来，客户端紧接着可以创建一个AMQP 信道，RabbitMQ 处理的每条 AMQP 指令都是通过信道完成的。
我们可以完全通过 connection 来完成工作，为什么要引入信道呢？一个应用程序中有很多线程需要从 RabbitMQ 中消费，或者生产消息，那么必然需要建立很多连接。然而对于操作系统而言，建立和销毁 TCP 连接是非常昂贵的开销，如果遇到业务高峰，性能随之显现。RabbitMQ采用类似 NIO 的做法，选择 TCP 复用，不仅可以减少性能开销，同时也便于管理。
每个线程把持一个信道，所以信道复用 connection 的 TCP 连接。同时 RabbitMQ 可以确保每个线程的私密性。就像拥有独立的连接一样。当每个信道流量不是很大时，复用单一的connection 可以在产生性能瓶颈情况下有效节省 TCP 资源。但是当信道本身的流量很大时，这时多个信道复用一个 connection 就会产生性能瓶颈，进而使整体的流量被限制。此时就需要开辟多个 connection，将这些信道均摊到这些 connection 中。
2.5 消费模式
RabbitMQ 的消费方式分为两种：推模式和拉模式。
在推模式中，可以通过持续订阅的方式来消费消息。在投递模期间，RabbitMQ 会不断的推送消息给消费者，当然推送的个数还是会受到 Basic.Qos 的限制。如果只是想从队列获得单条消息而不是持续订阅可以选择拉模式。如果要实现高吞吐量，消费者应使用推模式。
关于 RabbitMQ 的基础支持就介绍到这里，下篇文章将带你了解其高阶应用，欢迎关注。
往期经典推荐
走进 Mybatis 内核世界：理解原理，释放更多生产力-CSDN博客
一文掌握Java动态代理的奥秘与应用场景-CSDN博客
领航分布式消息系统：一起探索Apache Kafka的核心术语及其应用场景-CSDN博客
深入剖析Kafka生产者：揭秘消息从发送到落地的全过程-CSDN博客
Kafka消息流转的挑战与对策：消息丢失与重复消费问题_kafka发送消息生产者关闭了-CSDN博客
还没有评论，来说两句吧...