RabbitMQ——1、基础概念

1.1 基础概念

1.1.1 RabbitMQ是什么？

使用队列来通信的组件

RabbitMQ是实现了高级消息队列协议（AMQP）的开源消息代理软件（亦称面向消息的中间件）。RabbitMQ服务器是用Erlang语言编写的，而群集和故障转移是构建在开放电信平台框架上的。所有主要的编程语言均有与代理接口通讯的客户端库。

PS:也可能直接问什么是消息队列？消息队列就是一个使用队列来通信的组件

RabbitMQ 是一个由 Erlang 语言开发的 AMQP 的开源实现。

AMQP ：Advanced Message Queue，高级消息队列协议。它是应用层协议的一个开放标准，为面向消息的中间件设计，基于此协议的客户端与消息中间件可传递消息，并不受产品、开发语言等条件的限制。

RabbitMQ 最初起源于金融系统，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。具体特点包括：

\1. 可靠性（Reliability）：RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认、发布确认。

\2. 灵活的路由（Flexible Routing）：在消息进入队列之前，通过 Exchange 来路由消息的。对于典型的路由功能，RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能，可以将多个 Exchange 绑定在一起，也通过插件机制实现自己的 Exchange 。

\3. 消息集群（Clustering）：多个 RabbitMQ 服务器可以组成一个集群，形成一个逻辑 Broker 。

\4. 高可用（Highly Available Queues）：队列可以在集群中的机器上进行镜像，使得在部分节点出问题的情况下队列仍然可用。

\5. 多种协议（Multi-protocol）：RabbitMQ 支持多种消息队列协议，比如 STOMP、MQTT

等等。

\6. 多语言客户端（Many Clients）：RabbitMQ 几乎支持所有常用语言，比如 Java、.NET、 Ruby 等等。

\7. 管理界面（Management UI）:RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息 Broker 的许多方面。

\8. 跟踪机制（Tracing）:如果消息异常，RabbitMQ 提供了消息跟踪机制，使用者可以找出发生了什么。

\9. 插件机制（Plugin System）:RabbitMQ 提供了许多插件，来从多方面进行扩展，也可以编写自己的插件。

1.1.2 RabbitMQ特点

\1) 可靠性: RabbitMQ使用一些机制来保证可靠性， 如持久化、传输确认及发布确认等。

\2) 灵活的路由 : 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能， RabbitMQ 己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个 交换器绑定在一起， 也可以通过插件机制来实现自己的交换器。

\3) 扩展性: 多个RabbitMQ节点可以组成一个集群，也可以根据实际业务情况动态地扩展 集群中节点。

\4) 高可用性 : 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队 列仍然可用。

\5) 多种协议: RabbitMQ除了原生支持AMQP协议，还支持STOMP， MQTT等多种消息 中间件协议。

\6) 多语言客户端 :RabbitMQ 几乎支持所有常用语言，比如 Java、 Python、 Ruby、 PHP、 C#、 JavaScript 等。

\7) 管理界面 : RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集 群中的节点等。

\8) 插件机制 : RabbitMQ 提供了许多插件 ， 以实现从多方面进行扩展，当然也可以编写自 己的插件。

1.1.3 为什么需要消息队列？

异步处理、服务解耦、流量控制（削峰）

主要是可以异步处理大量请求，缓解系统压力，同时也避免大量同步请求，导致数据库行锁，表锁的情况

在高并发场景下，由于服务端来不及同步处理数量过多的请求，可能导致请求堵塞。例如，大量的 INSERT、UPDATE 之类的请求同时到达 MySQL 服务端，在执行这些请求的过程中，会出现大量的行锁、表锁，甚至到最后，由于请求堆积过多，触发“too many connections”错误。在这类高并发场景下，通过使用消息队列，我们就可以异步处理这些请求，从而缓解系统的压力。

从本质上来说是因为互联网的快速发展，业务不断扩张，促使技术架构需要不断的演进。

从以前的单体架构到现在的微服务架构，成百上千的服务之间相互调用和依赖。从互联网初期一个服务器上有 100 个在线用户已经很了不得，到现在坐拥10亿日活的微信。此时，我们需要有一个「工具」来解耦服务之间的关系、控制资源合理、合时的使用，以及缓冲流量洪峰等等。因此，消息队列就应运而生了。

它常用来实现：异步处理、服务解耦、流量控制（削峰）。

1.1.4 消息队列有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处：解耦、异步、削峰。

缺点有以下几个：

i. 系统可用性降低：系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩溃，你不就完了？

ii. 系统复杂度提高：硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？

iii. 怎么保证消息传递的顺序性？问题一大堆。

一致性问题 A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致 了。

1.1.5 在何种场景下使用了消息中间件？

\1) 接口之间耦合比较严重

\2) 面对大流量并发时，容易被冲垮

\3) 存在性能问题