MQ消息中间件常见面试题

最新推荐文章于 2024-08-20 16:28:27 发布

白夜行515

最新推荐文章于 2024-08-20 16:28:27 发布

阅读量1.3k

点赞数 1

分类专栏： mq 文章标签： kafka rabbitma 面试题

原文链接：https://blog.csdn.net/qq_29676623/article/details/85108070

版权

mq 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

对原文章部分知识点做了补充

1. 为什么使用消息队列

面试官问这个问题的期望之一的回答是，你们公司有什么业务场景，这个业务场景有什么技术挑战，如果不用MQ可能会很麻烦，但是再用了之后带来了很多好处。
消息队列的常见使用场景有很多但是核心的有三个：解耦、异步、削峰

1.1 解耦

场景描述：A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人崩溃中…再来点崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了怎么办？那我要不要重发？我要不要把消息存起来？头发都白了啊…
使用了MQ之后的解耦场景
面试技巧：你需要考虑下，你负责的系统中是否有类似的场景，就是一个系统或者一个模块，调用了多个系统或者模块，相互之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果MQ给他异步化解耦也是可以的，你就需要去考虑在你的项目里是不是可以运用这个MQ去进行系统解耦。

1.2 异步

场景描述：系统A接受一个请求，需要在自己本地写库，还需要在系统BCD三个系统写库，自己本地写库需要3ms。BCD分别需要300ms、450ms、200ms。最终总好时长：953ms，接近1s。给用户的体验感觉一点也不好。
不用MQ的同步高延时请求场景
使用MQ异步化之后的接口性能优化

1.3 削峰

场景描述：每天 0 点到 11 点，系统A风平浪静，每秒并发请求数量就 100 个。结果每一一到11点到1点，每秒并发请求数量就会暴增大1万条。但是系统最大的处理能力就只能每秒钟处理1000个请求。
没有用MQ的时候高峰期系统被打死的场景
使用MQ来进行削峰的场景

2. 消息队列的优缺点

2.1 优点

特殊场景下解耦、异步、削峰。

2.2 缺点

系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的没什么问题，你偏加个MQ进来，万一MQ挂了怎么办，整套系统崩溃了，就完蛋了
系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
一致性问题：系统A处理完了直接返回成功了，人家都认为你这个请求成功了；但问题是，要是BCD三个系统哪里BD系统成功了，结果C系统写库失败了，咋整？数据就不一致了，
所以消息队列是一种非常复杂的架构，引入它有很多好处，但是也得针对他带来的坏处做各种额外的技术方案和架构来规避掉。做好之后你会发现系统复杂度提升了一个数量积，但是关键时刻，用，还是要用的。

3. kafka、rabbitmq、rocketmq的优缺点

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	万级，吞吐量比RocketMQ和Kafka要低了一个数量级	10万级，RocketMQ也是可以支撑高吞吐的一种MQ	10万级别，这是kafka最大的优点，就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic数量对吞吐量的影响	-	-	topic可以达到几百，几千个的级别，吞吐量会有较小幅度的下降。这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic	topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源
时效性	ms级	微秒级，这是rabbitmq的一大特点，延迟是最低的	ms级	延迟在ms级以内
可用性	高，基于主从架构实现高可用性	高，基于主从架构实现高可用性	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	经过参数优化配置，可以做到0丢失	经过参数优化配置，可以做到0丢失	经过参数优化配置，可以做到0丢失
特点	MQ领域的功能极其完备	基于erlang开发，所以并发能力很强，性能极其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是事实上的标准
优点	非常成熟，功能强大，在业内大量的公司以及项目中都有应用	erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备；而且开源提供的管理界面非常棒，用起来很好用；社区相对比较活跃，版本更新快；使用公司多	接口简单易用；大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性高，还可以支撑大规模的topic数量，支持复杂MQ业务场景；源码是Java方便定制。	提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展；同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量
缺点	偶尔会有较低概率丢失消息。社区不活跃，版本更新慢。基于解耦和异步来用的，较少在大规模吞吐的场景中使用	吞吐量较低；rabbitmq集群动态扩展较复杂；erlang开发人员少，不易于定制	社区活跃度一般	有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略

4. 引入消息队列之后如何保证其高可用性

4.1 RabbitMQ的高可用性

RabbitMQ是比较有代表性的，因为是基于主从做高可用性的，我们就以他为例子讲解第一种MQ的高可用性怎么实现。
Rabbitmq有三种模式：单机模式，普通集群模式，镜像集群模式

单机模式

demo级别，一般就是你本地启动了玩玩儿的，没人生产用单机模式

普通集群模式

在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbtimq实例上，但是每个实例都同步queue的元数据。完了你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从queue所在实例上拉取数据过来。
非分布式，就是个普通集群。因为这导致你要么消费者每次随机连接一个实例然后拉取数据，要么固定连接那个queue所在实例消费数据，前者有数据拉取的开销，后者导致单实例性能瓶颈。
如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取，如果你开启了消息持久化，让rabbitmq落地存储消息的话，消息不一定会丢，得等这个实例恢复了，然后才可以继续从这个queue拉取数据。
主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。

镜像集群模式

是高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息到多个实例的queue里进行消息同步。
优点：任何一个机器宕机了，没事儿，别的机器都可以用。
缺点：
- 第一：性能开销大，消息同步所有机器，导致网络带宽压力和消耗很重！
- 第二，扩展性低，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue
可以通过管理控制台开启这个镜像集群模式，在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。

镜像集群模式

4.2 Kafka的高可用性

kafka一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。
这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。
实际上rabbitmq之类的，并不是分布式消息队列，他就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据。
kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
kafka 0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到吉他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。只能读写leader？很简单，要是你可以随意读写每个follower，那么就要care数据一致性的问题，系统复杂度太高，很容易出问题。kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样才可以提高容错性。
这么搞，就有所谓的高可用性了，因为如果某个broker宕机了，没事儿，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。这就有所谓的高可用性了。
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据。一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从leader去读，但是只有一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。
实际上这块机制，讲深了，是可以非常之深入的，但是我还是回到我们这个课程的主题和定位，聚焦面试，至少你听到这里大致明白了kafka是如何保证高可用机制的了，对吧？不至于一无所知，现场还能给面试官画画图。要遇上面试官确实是kafka高手，深挖了问，那你只能说不好意思，太深入的你没研究过。
但是大家一定要明白，这个事情是要权衡的，你现在是要快速突击常见面试题体系，而不是要深入学习kafka，要深入学习kafka，你是没那么多时间的。你只能确保，你之前也许压根儿不知道这块，但是现在你知道了，面试被问到，你大概可以说一说。然后很多其他的候选人，也许还不如你，没看过这个，被问到了压根儿答不出来，相比之下，你还能说点出来，大概就是这个意思了。

5. 如何保证消息消费时的幂等性

幂等性：一个请求重复请求多次，需要确保对应的数据是不会改变的，多次请求结果相同。
如何保证消费不被重复消费
如何保证消息的幂等性

6. 如何保证消息的可靠传输

用mq有个基本原则，就是数据不能多一条，也不能少一条，不能多，就是刚才说的重复消费和幂等性问题。不能少，就是说这数据别搞丢了。那这个问题你必须得考虑一下。

6.1 Rabbitmq

6.1.1 生产者丢数据

生产者将数据发送到rabbitmq的时候，可能数据就在半路给搞丢了，因为网络啥的问题，都有可能。

解决方案

1.事务机制（不推荐，异步方式）
对于 RabbitMQ 来说，生产者发送数据之前开启 RabbitMQ 的事务机制channel.txselect ，如果消息没有进队列，则生产者受到异常报错，并进行回滚 channel.txRollback，然后重试发送消息；如果收到了消息，则可以提交事务 channel.txCommit。但这是一个同步的操作，会影响性能。
2.confirm 机制（推荐，异步方式）
每次生产者发送的消息都会分配一个唯一的 id，如果写入到了 RabbitMQ 队列中，则 RabbitMQ 会回传一个 ack 消息，说明这个消息接收成功。如果 RabbitMQ 没能处理这个消息，则回调 nack 接口。说明需要重试发送消息。
事务模式和 confirm 模式的区别：
- 事务机制是同步的，提交事务后悔被阻塞直到提交事务完成后。
- confirm 模式异步接收通知，但可能接收不到通知。需要考虑接收不到通知的场景。

6.1.2 rabbitmq自己丢数据

解决方案：创建 Queue 的时候将其设置为持久化。
设置持久化有两个步骤
- 第一：创建queue的时候将其设置为持久化的，这样就可以保证rabbitmq持久化queue的元数据，但是不会持久化queue里的数据；
- 第二：发送消息的时候将消息的deliveryMode设置为2，就是将消息设置为持久化的，此时rabbitmq就会将消息持久化到磁盘上去。必须要同时设置这两个持久化才行，rabbitmq哪怕是挂了，再次重启，也会从磁盘上重启恢复queue，恢复这个queue里的数据。
- 持久化可以跟生产者那边的confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者ack了，所以哪怕是在持久化到磁盘之前，rabbitmq挂了，数据丢了，生产者收不到ack，你也是可以自己重发的。
哪怕是你给rabbitmq开启了持久化机制，也有一种可能，就是这个消息写到了rabbitmq中，但是还没来得及持久化到磁盘上，结果不巧，此时rabbitmq挂了，就会导致内存里的一点点数据会丢失。

6.1.3 消费者丢数据

rabbitmq如果丢失了数据，主要是因为你消费的时候，刚消费到，还没处理，结果进程挂了，比如重启了，那么就尴尬了，rabbitmq认为你都消费了，这数据就丢了。
这个时候得用rabbitmq提供的ack机制，简单来说，就是你关闭rabbitmq自动ack，可以通过一个api来调用就行，然后每次你自己代码里确保处理完的时候，再程序里ack一把。这样的话，如果你还没处理完，不就没有ack？那rabbitmq就认为你还没处理完，这个时候rabbitmq会把这个消费分配给别的consumer去处理，消息是不会丢的。

6.2 kafka

6.2.1 生产者会不会弄丢数据

如果producer端设置acks=all，一定不会丢，即要求leader接收到消息，所有的follower都同步到了消息之后，才认为本次写成功了。如果没满足这个条件，生产者会自动不断的重试，重试无限次。

6.2.2 kafka自己弄丢数据

常见的一个场景，就是kafka某个broker宕机，然后重新选举partiton的leader时。
要是此时其他的follower刚好还有些数据没有同步，结果此时leader挂了，然后选举某个follower成leader之后，他不就少了一些数据？这就丢了一些数据啊。
保证在leader所在broker发生故障，进行leader切换时，数据不会丢失，一般是要求设置如下4个参数：
- topic设置replication.factor参数：这个值必须大于1，要求每个partition必须有至少2个副本
- kafka服务端设置min.insync.replicas参数：这个值必须大于1，这个是要求一个leader至少感知到有至少一个follower还跟自己保持联系，没掉队，这样才能确保leader挂了还有一个follower吧
- producer端设置acks=all：这个是要求每条数据，必须是写入所有replica之后，才能认为是写成功了
- producer端设置retries=MAX（很大很大很大的一个值，无限次重试的意思）：这个是要求一旦写入失败，就无限重试，卡在这里了

6.2.3 消费者弄丢数据

唯一可能导致消费者弄丢数据的情况，就是说，你那个消费到了这个消息，然后消费者那边自动提交了offset，让kafka以为你已经消费好了这个消息，其实你刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢咯。
这不是一样么，大家都知道kafka会自动提交offset，那么只要关闭自动提交offset，在处理完之后自己手动提交offset，就可以保证数据不会丢。但是此时确实还是会重复消费，比如你刚处理完，还没提交offset，结果自己挂了，此时肯定会重复消费一次，自己保证幂等性就好了。
生产环境碰到的一个问题，就是说我们的kafka消费者消费到了数据之后是写到一个内存的queue里先缓冲一下，结果有的时候，你刚把消息写入内存queue，然后消费者会自动提交offset。
然后此时我们重启了系统，就会导致内存queue里还没来得及处理的数据就丢失了

7. 如何保证消息的顺序性

7.1 Rabbitmq

数据错乱的场景：一个queue，多个consumer，这不明显乱了
保证消息顺序性的方案：拆分多个queue，每个queue一个consumer，就是多一些queue而已，或者一个queue但是对应一个consumer，然后这个consumer内部用内存队列做排队，然后分发给底层不同的worker来处理

7.2 kafka

数据错乱的场景：一个topic，一个partition，一个consumer，内部多线程，这不也明显乱了
保证消息顺序性的方案：一个topic，一个partition，一个consumer，内部单线程消费，写N个内存queue，然后N个线程分别消费一个内存queue即可

8. 消息队列积压或满了该怎么处理

8.1 kafka消费积压

解决方案：临时紧急扩容，具体操作步骤和思路如下：
1）先修复consumer的问题，确保其恢复消费速度，然后将现有cnosumer都停掉
2）新建一个topic，partition是原来的10倍，临时建立好原先10倍或者20倍的queue数量
3）然后写一个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的10倍数量的queue
4）接着临时征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的数据
5）这种做法相当于是临时将queue资源和consumer资源扩大10倍，以正常的10倍速度来消费数据
6）等快速消费完积压数据之后，得恢复原先部署架构，重新用原先的consumer机器来消费消息

8.2 Rabbitmq消息积压

解决方案

修复代码层面消费者的问题，确保后续消费速度恢复或尽可能加快消费的速度。
停掉现有的消费者。
临时建立好原先 5 倍的 Queue 数量。
临时建立好原先 5 倍数量的消费者。
将堆积的消息全部转入临时的 Queue，消费者来消费这些 Queue。

8.3 队列写满

解决方案：

判断哪些是无用的消息，RabbitMQ 可以进行 Purge Message 操作。
如果是有用的消息，则需要将消息快速消费，将消息里面的内容转存到数据库。
准备好程序将转存在数据库中的消息再次重导到消息队列。
闲时重导消息到消息队列。

9. 如何设计一个消息队列

（1）首先这个mq得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka的设计理念，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？

（2）其次你得考虑一下这个mq的数据要不要落地磁盘吧？那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。

（3）其次你考虑一下你的mq的可用性啊？这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。

（4）能不能支持数据0丢失啊？可以的，参考我们之前说的那个kafka数据零丢失方案