RabbitMQ 简介

最新推荐文章于 2025-03-26 16:48:03 发布

@日月空@

最新推荐文章于 2025-03-26 16:48:03 发布

阅读量3.3k

点赞数

分类专栏： RabbitMQ 文章标签： rabbitmq mq

本文链接：https://blog.csdn.net/qq_41993206/article/details/124273765

版权

RabbitMQ 专栏收录该内容

1 篇文章

订阅专栏

RabbitMQ是一款开源消息中间件，基于Erlang编写，支持多种协议。其特点是可靠性、灵活的路由、集群和高可用性队列。消息中间件的主要作用包括解耦、异步通信和流量削峰。点对点模式和发布订阅模式是其两种主要的通信模式。通过引入消息队列，系统可以在不影响用户体验的情况下处理高并发和解耦各个组件。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

RabbitMQ是目前非常热门的一款消息中间件，凭借其高可靠、易扩展、高可用及丰富的功能特性受到越来越多公司的青睐。

什么是消息中间件

消息(Message)是指在应用间传送的数据。消息可以非常简单，比如只包含文本字符串、 JSON 等，也可以很复杂，比如内嵌对象。

消息队列中间件，也可以称为消息队列或者消息中间件。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。

它一般有两种传递模式：点对点(P2P，Point-to-Point)模式和发布/订阅(Pub/Sub)模式。

点对点模式

点对点模式是基于队列的，消息生产者发送消息到队列，消息消费者从队列中接收消息，队列的存在使得消息的异步传输成为可能。

发布订阅模式

发布订阅模式定义了如何向一个内容节点发布和订阅消息，这个内容节点称为主题(topic)，主题可以认为是消息传递的中介，消息发布者将消息发布到某个主题，

而消息订阅者则从主题中订阅消息。主题使得消息的订阅者与消息的发布者互相保持独立，不需要进行接触即可保证消息的传递，发布/订阅模式在消息的一对多

广播时采用。

目前开源的消息中间件有很多，比较主流的有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。

消息中间件的作用

解耦

场景说明：

用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。

传统模式的缺点：

假如库存系统无法访问，则订单减库存将失败，从而导致订单失败订单系统与库存系统耦合。

引入消息队列：

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功

库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作

优点：

实现订单系统与库存系统的应用解耦。

假如在下单时库存系统不能正常使用，那也不会影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。

为了保证库存肯定有，可以将队列大小设置成库存数量，或者采用其他方式解决。

异步通信

场景说明：

用户注册后，需要发注册邮件和注册短信。传统的做法有两种串行的方式；并行方式。

**(1) 串行方式：**将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。以上三个任务全部完成后，返回给客户端。

**(2) 并行方式：**将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信。以上三个任务完成后，返回给客户端。与串行的差别是，并行的方式可以提

高处理的效率。

引入消息队列：

将注册信息写入数据库成功后，将消息分别写入短信队列和邮件队列，然后返回客户端。

同时短信和邮件队列对应的消费者，消费队列中的消息，给对应的用户发送短信或者邮件。

优点：

将不是必须的业务逻辑，放到消息队列中异步处理，提高系统吞吐效率。

流量削峰

应用场景：

系统其他时间A系统每秒请求量就100个，系统可以稳定运行。系统每天晚间八点有秒杀活动，每秒并发请求量增至1万条，但是系统最大的处理能力只能每秒处理1000个请求，于是系统崩溃，服务器宕机。

之前架构：

大量用户（100万用户）通过浏览器在晚上八点高峰期同时参与秒杀活动。大量的请求涌入我们的系统中，高峰期达到每秒钟5000个请求，大量的请求打到MySQL上，每秒钟预计执行3000条SQL。但是一般的MySQL每秒钟扛住2000个请求就不错了，如果达到3000个请求的话可能MySQL直接就瘫痪了，从而系统无法被使用。但是高峰期过了之后，就成了低峰期，可能也就1万用户访问系统，每秒的请求数量也就50个左右，整个系统几乎没有任何压力。

**引入MQ：**100万用户在高峰期的时候，每秒请求有5000个请求左右，将这5000请求写入MQ里面，系统A每秒最多只能处理2000请求，因为MySQL每秒只能处理2000个请求。系统A从MQ中慢慢拉取请求，每秒就拉取2000个请求，不要超过自己每秒能处理的请求数量即可。MQ，每秒5000个请求进来，结果只有2000个请求出去，所以在秒杀期间（将近一小时）可能会有几十万或者几百万的请求积压在MQ中。

关于流量削峰：秒杀系统流量削峰这事儿应该怎么做？

这个短暂的高峰期积压是没问题的，因为高峰期过了之后，每秒就只有50个请求进入MQ了，但是系统还是按照每秒2000个请求的速度在处理，所以说，只要高峰期一过，系统就会快速将积压的消息消费掉。我们在此计算一下，每秒在MQ积压3000条消息，1分钟会积压18万，1小时积压1000万条消息，高峰期过后，1个多小时就可以将积压的1000万消息消费掉。

注意：中间件的在不同的应用场景可能会有不同的作用，具体看怎么应用，并不局限于上述场景。