关于消息队列的那些事_linux消息队列会消失吗，2024年最新2024百度Linux运维岗面试真题收录解析

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新Linux运维全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上运维知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip1024b （备注运维）

正文

在过去业务量小的时候，企业用的都是单机架构，直接一台单机就能满足日常业务的需求了

随着互联网的不断发展，公司的业务体量不断扩大，老旧的单机架构已经不能满足日常需求了，于是分布式、微服务这些新架构新方法不断涌现出来

这也意味着成千上百服务之间的依赖、调用关系越来越复杂，这时候我们迫切的需要一个【中间件】来解耦服务之间的关系，控制资源的合理合时分配以及缓冲流量高峰等等

消息队列应运而生，消息队列的三大经典场景——异步处理、服务解耦、流量控制

1.异步处理

你负责公司的一个电商项目，业务初期只是一个很简单的流程：用户下单支付—>扣库存—>下单成功

后面来了个产品经理跟你说要搞个积分系统，问题不大，流程里多加一步就行了

结果你发现产品经理并不满足于此，又来找你说要搞个优惠券系统，你咬咬牙说：行！整就完事了

再后来产品经理一脸邪笑的找到你，下单成功之后我们需要给用户发送短信，再搞个短信服务吧嘿嘿嘿

你薅了薅自己日渐稀疏的发顶，不禁感叹世事无常大肠包小肠…

到后面你的项目流程就如下图右边所示（在现实的电商项目中，涉及到的流程可比这个复杂多了）

如果按照这个流程来执行，时间可不是一般的长，用户到时候就会发现我在你这买个东西要花几十秒，什么垃圾软件，爬！

既然流程长了会导致时间变长，但我们可以将其中一些流程同时做呀——用户下单成功之后，我去检验优惠券的同时还能去增减积分，还能发个短信

怎么实现异步呢？消息队列！

相对于扣库存和下单，积分和短信是没有必要这么的“及时”，因此你只需要在支付后的那个流程，扔个消息到消息队列当中就可以直接返回响应给客户端了，不需要再等待积分、优惠券、短信服务

而积分、优惠券、短信服务就可以去消费这条消息，执行之后的流程

有了消息队列，用户只需要很短时间内就知道自己支付成功了，至于短信和积分这些非必要服务，迟几秒并不会特别影响用户的使用体验

2.服务解耦

上面的电商场景中已经有了——积分服务、优惠券服务、短信服务

万一后面可能又来个营销服务、活动期间再弄个促销服务等等等等…

随着服务越来越多，就需要经常的修改支付服务的下游接口，任何一个下游服务接口的变更都可能会影响到订单服务的代码

为了解决服务之间的依赖关系，降低服务间的耦合度，我们可以在支付服务和下游的服务中间加一个消息队列

支付服务只需要把订单、支付相关消息塞到消息队列当中，下游的服务谁需要这个消息自己去获取就行了

这样无论下游添加了什么服务，都不会影响上游的订单服务

3.流量控制

在平常的业务场景中，你的流量很低，但是一旦遇到秒杀活动、双十一活动这些大流量的场景

尤其是在某一时刻（例如 00:00）流量如洪水猛兽一样疯狂怼进来，你的服务器、MySQL、Redis各自的性能都是不一样的

你肯定不能将全部的流量请求照单全收，很容易会将性能低的服务器直接打挂

所以需要引入一个中间件来做缓冲，消息队列是一个很好的选择

先将请求放到消息队列当中，后端服务就尽自己最大的能力去消息队列中消费请求，对于超时的请求，可以直接返回错误。这样可以防止在高峰期大量的请求直接导致后端服务器崩溃

总结：

• 消息队列通常指的是消息队列中间件，它负责存放消息，便于应用之间的消息通信（可以理解为情报中转站）
• 消息队列三大应用场景：异步、削峰、解耦

消息队列

看看维基百科是怎么描述的

In computer science, message queues and mailboxes are software-engineering components typically used for inter-process communication (IPC), or for inter-thread communication within the same process. They use a queue for messaging – the passing of control or of content. Group communication systems provide similar kinds of functionality.

消息是指两个应用间传递的数据，数据的类型有很多种，可能只是文本、也有可能是对象

消息队列指的是在消息传输的过程中用来保存消息的容器（组件）

消息队列中，有下面两个角色：

• 生产者（producer）：负责生产数据并传输到消息队列，至于谁去取消息，生产者并不关心
• 消费者（consumer）：负责从消息队列中取出数据，至于数据是谁生产的，消费者并不关心

市面上主流的消息队列中间件

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级；比RaabitMQ、Kafka低一个数量级	同ActiveMQ	十万级；支持高吞吐	十万级、高吞吐；一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响	\	\	topic可以达到几百/几千级别，吞吐量会有较小幅度的下降	topic从几十到几百的时候，吞吐量会大幅度下降；同等机器下尽量保证topic 数量不要过多
时效性	毫秒级	微秒级、延迟最低 RabbitMQ特性	毫秒级	毫秒级以内
可用性	高，基于主从架构	高，基于主从架构	非常高 分布式架构	非常高、分布式、一个数据多个副本
消息可靠性	有较低的概率丢失数据	基本不丢	可以通过参数优化做到零丢失	基本不丢
功能支持	功能完备	性能好，延时低	功能完善	功能简单
社区活跃度	低	中	高	高

1.两种模型

• 队列模型

生产者往某个队列里发送消息，一个队列可以存储多个生产者的消息，一个队列也可以有多个消费者

但是消费者之间是竞争关系，即每条消息只能被一个消费者消费

• 发布/订阅模型

在队列模型中，每条消息只能被一个消费者所消费，为了解决这一问题，让一条消息能被多个消费者消费，发布/订阅模型诞生了

在发布/订阅模型当中，会将消息发送到一个 topic（主题）中，所有订阅了这个 topic 的消费者都能消费到这条消息

就好比队列模型就是你在微信上跟别人私聊，你发送的消息只能被你私聊的那个人收到；发布/订阅模型就相当于你创建了一个群聊，把大家都拉进群里，只要是在群里的（订阅了 topic）都能收到你发的消息

那有的人就会想，我对好多人私聊，并且发的都是相同的信息，不是也能够实现一条消息被多个消费者消费的功能吗

很聪明！在队列模型里，可以使用多队列来全量存储相同的消息，然后不同的消费者去不同的队列里消费

通过数据的冗余实现一条消息被多个消费者消费的功能

RabbitMQ 中通过 exchange 模块将消息发送到多个队列，解决一条消息能被多个消费者消费的问题

总结：

• 队列模型中，一条消息只能被一个消费者消费；发布/订阅模型中，一条消息可以被多个消费者消费
• 队列模型中，可以通过数据冗余（一条消息存储到多个队列当中）来实现一条消息可以被多个消费者消费（RabbitMQ就是采用这种模式）
• RabbitMQ 采用队列模型、RocketMQ 和 Kafka 采用发布/订阅模型

2.基本原理

生产者：Producer

消费者：Consumer

消息队列服务端：Broker

消息由 Producer 发往 Broker，Broker 将消息存储至本地，然后 Consumer 从 Broker拉取消息，或者由 Broker 推送消息给 Consumer，最后实现消费

在发布/订阅模型中，为了提高并发，还会引入队列或者分区的概念——将消息发往一个 topic 中的某个队列或者某个分区（队列和分区本质一样，叫法不一样）

例如某个 topic 下有 n 个队列，那么这个主题的并发度就提高 n，同时可以支持 n 个消费者并行消费该 topic 中的消息

通常采用轮询 或者 key hash 取余等策略来将同一个 topic 的消息分配到不同的队列当中

既然是一对多的关系，那么消费者一般都有组的概念（Consumer group），即一条消息会发送到订阅了这个 topic 的消费组

例如现在有 Group1 和 Group 2 两个消费组，都订阅了 topic1 ，如果有一条消息发送到 topic1，那么这两个消费组都能接收到这条消息；消息其实是存储到了 topic1 中的某个队列当中，消费组的某个消费者对应消费一个队列的消息

实际上，一条消息在 Broker 中只会有一份，每个 Consumer group 会有自己的 offset （偏移量）来标识消费到的位置

在 offset 前的消息表示已经消费过了，每个 Consumer group 都会维订阅的 topic 下的每个队列的 offset

3.常见问题

如何保证消息不丢失

我们知道，从生产者生产消息到消费者消费消息，会经历三个阶段——生产消息、存储消息、消费消息。为了让消息不丢失，我们需要从这三个阶段进行考虑

• 生产消息

producer 发送消息到 broker ，需要处理 broker 的响应，无论是同步还是异步发送消息，都需要处理好 broker 的响应

如果 broker 返回写入失败等错误消息，需重新发送，当多次发送失败后需要进行故障处理

• 存储消息

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
后需要进行故障处理

• 存储消息

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加V获取：vip1024b （备注运维）
[外链图片转存中…(img-YsOq0kel-1713223159354)]

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！