你能说说你对RabbitMQ的认识吗？

1、什么是消息队列中间件

是指利用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传和消息排队模型，它可以在分布式环境下扩展进程间的通信。

1.1、消息队列中间件一般有两种传递模式：

• 点对点模式：点对点模式是基于队列的，消息生产者发送消息到队列，消息消费者从队列中接收消息，队列的存在使得消息的异步传输成为可能。
• 发布/订阅模式：就是一对多的模式。消息发布者将消息发布到某个主题(中介)上，而消息订阅者则从主题中订阅消息，主题的存在使得消息发布者和消息订阅者保持相互独立，发布/订阅模式在消息的一对多广播时采用

1.2、消息队列中间件的作用：

• 解耦：在消息中间件插入接口，两边的应用实现这一接口，然后又可以独立修改或者扩展自己的处理过程，这样就在一定程度上实现了应用程序之间的解耦。
• 顺序保证: 在大多数使用场景下，数据处理的顺序很重要，大部分消息中间件支持 定程度上的顺序性。
• 缓冲: 在任何重要的系统中，都会存在需要不同处理时间的元素。消息中间件通过 个缓冲层来帮助任务最高效率地执行，写入消息中间件的处理会尽可能快速， 该缓冲层有助于控制和优化数据流经过系统的速度。
• 可恢复性: 当系统一部分组件失效时，不会影响到整个系统 消息中间件降低了进程间的稿合度，所以即使 个处理消息的进程挂掉，加入消息中间件中的消息仍然可以在系统恢复后进行处理
• 冗余〈存储) ：有些情况下，处理数据的过程会失败。消息中间件可以把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。但是这个消息在被消费之前一直会占用资源。

2、RabbitMQ的原理简介

2.1、RabbitMQ运转过程

消息流转的过程如下：

由上述流程图可以知道，生产者先数据进行封装处理（如序列化）、然后给数据贴上标签，如Routingkey(路由键：用来指定交换机(Exchange))、Bindingkey(绑定键：用于交换机和队列进行绑定)等，然后数据和标签结合就是消息了，然后将这个消息通过AMQP协议发送给Broker中，Broker根据相应的Routingkey和Bindingkey将消息绑定到相应的交换机和队列。然后消费者通过AMQP协议订阅并接收消息，当然也是根据Bindingkey去获取具体队列的消息。然后通过解包等操作得到原数据后就可以进行业务逻辑处理了。这个业务处理逻辑并不 定需要和接收消息的逻辑使用同 个线程。

2.2、RabbitMQ整体模型架构

从2.1节我们知道了，Broker通过Routingkey和Bindingkey将消息绑定到相应的交换机和队列，而消费者也是根据Bindingkey去获取具体队列的消息，这就意味着整个消息一个处理流程我们大致知道了。
其中交换机共有四种不同的消息处理模式：

• fanout ：它会把所有发送到该交换器的消息路由到所有与该交换器绑定的队列中。
• direct ：direct 类型的交换器路由规则也很简单，它会把消息路由到那些 BindingKey RoutingKey完全匹配的队列中。
• topic ：它和direct 类型的交换器路由规则相似，但是它是根据BindingKey RoutingKey进行模糊匹配的。
• headers ：根据发送的消息内容中的headers 属性进行匹配。

队列也有六种模式：

• 简单队列模式：最简单的工作队列，其中一个消息生产者，一个消息消费者，一个队列。也称为点对点模式
• 工作模式：一个消息生产者，一个交换器，一个消息队列，多个消费者。同样也称为点对点模式
• 发布/订阅模式：无选择接收消息，一个消息生产者，一个交换器，多个消息队列，多个消费者。称为发布/订阅模式
• 路由模式：在发布/订阅模式的基础上，有选择的接收消息，也就是通过 routing 路由进行匹配条件是否满足接收消息。
• 主题模式：同样是在发布/订阅模式的基础上，根据主题匹配进行筛选是否接收消息，比第四类更灵活。
• RPC模式：与上面其他5种所不同之处，类模式是拥有请求/回复的。也就是有响应的，上面5种都没有。

队列共有两种消息分发方式：

• 轮询分发：队列中的消息会被平均分摊给多个消费者进行处理。每个消息只发送给一个消费者。
• 公平分发：队列优先给闲置的消费者分发消息，这样就导致处理速度快的消费者可以处理更多的消息。但是需要的注意是公平分发模式下，消息的应答方式应该改为手动。

消费者也有两种获取消息的方式：

• 推模式：消费者可以通过持续订阅的方式来消费消息
• 拉模式：消费者单条获取消息。

有一个疑问，消费者和生成者是怎么样与Broker进行通信的呢？对，就是AMQP协议。那如果把AMQP协议弄懂了，就意味着把RabbitMQ整个一套消息流转过程就搞懂了。

2.3、AMQP协议简介

AMQP协议是基于TCP协议的，它先基于TCP协议让客户端和Broker建立一个连接（connection），客户端紧接着可以创建一个 AMQP 信道 (Channel) ，每个信道都会被指派一个唯一的ID 。信道是建立在 Connection 之上的虚拟连接， RabbitMQ 处理的每条 AMQP 指令都是通过信道完成的。
那么就会有一个疑惑，为什么不直接用TCP协议进行数据传输呢？为什么要引入这么多虚拟信道呢？

• 因为每一个TCP连接都需要进行三次握手四次挥手的操作，而一个应用程序中有很多个线程需要从 RabbitMQ 中消费消息，或者生产消息，那就意味需要建立很多连接，而每一个TCP连接和销毁都是极昂贵的资源浪费。因此不直接用TCP传输数据
• 至于为什么要引入这么多虚拟信道？这是采用NIO的思想，多路信道复用一个TCP连接，极大的减少了TCP的连接和销毁的开销。同时一个线程负责一个信道，也提高了应用的性能。当然在流量很大时，可以建立多个TCP连接，这个时候就需要将建立的信道均衡的建立在这些TCP中。

看到这里，相信你已经对整个RabbitMQ消息的流转过程原理有了一个清晰的认识了。

如侵权，请告知，立删！

欢迎各位关注我的JAVAERS公众号，陪你一起学习，一起成长，一起分享JAVA路上的诗和远方。在公众号里面都是JAVA这个世界的朋友，公众号每天会有技术类文章，面经干货，也有进阶架构的电子书籍，如Spring实战、SpringBoot实战、高性能MySQL、深入理解JVM、RabbitMQ实战、Redis设计与实现等等一些高质量书籍，关注公众号即可领取哦。