消息队列面试题详解

消息队列面试题详解

1.为什么要使用消息队列？(消息队列的应用场景)

解耦，异步(可以提高响应请求)，削峰（经济实用性的考量）

2.各种消息产品的比较

1. ActiveMQ，早起使用的较多，没经过大规模吞吐量场景的验证，社区也不是很活跃，但是现在确实大家用的不多了，不推荐。
2. RabbitMQ，开发语言 erlang 阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是RabbitMQ是开源的，比较稳定的支持，活跃度也高，如不考虑二次开发，追求性能和稳定性，推荐使用。
3. RocketMQ，开发语言是Java，在阿里内部经受过高并发业务的考验，稳定性和性能均不错，考虑后期可能二次开发，推荐使用。
4. Kafka ，大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，社区活跃度很高，推荐使用。大数据领域日志采集等业务推荐使用

3.消息对列的优点和缺点

优点：解耦，异步，削峰

缺点：系统的可用性降低，系统的复杂性提高，数据的一致性问题。

4.如何保证消息队列的高可用？

RabbitMQ高可用-镜像集群

1. 在多台机器上分别启动RabbitMQ实例。

2. 多个实例之间可以相互通信。

3. 每次生产者写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。每个RabbitMQ节点上都有Queue的消息数据和元数据。

4. 某一个节点宕机，其他节点依然保存完整数据，不影响客户端消费。

RocketMQ高可用-双主双从

1. 生产者通过Name Server发现Broker

2. 生产者发送队列消息到2个Broker主节点

3. Broker主节点分别和各自从节点同步数据

4. 消费者从主或者从节点订阅消息

   nameserver:相当于一个管理中心，它和Broker 之间通过心跳机制进行沟通。

5.如何保证消息不丢失？

消息丢失的场景：

情况一：消息生产者没有成功发送到MQ Broker
情况二：消息发送给MQ Broker后，Broker宕机导致内存中的消息数据丢失
情况三：消费者获取到消息，但消费者还没有来得及处理宕机了，但此时MQ中消息已经删除，消费者重启后不能再消费之前的消息

解决方案：

1. 消息发送者发送给MQ Broker后，MQ Broker给生产者确认收到

2. MQ收到消息后进行消息持久化

3. 消费者收到消息处理完毕后手动进行ack确认

4. MQ收到消费者ack确认后删除持久化的消息

6.如何保证消息消费的幂等性（如何保证消息不被重复消费）？

发送时消息重复
当一条消息已被成功发送到服务端，此时出现了网络闪断，导致服务端对客户端应答失败。 如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同的消息。

消费时消息重复
消息消费的场景下，消息已投递到消费者并完成业务处理，当消费方给MQ服务端反馈应答的时候网络闪断。 为了保证消息至少被消费一次，MQ服务端将在网络恢复后再次尝试投递之前已被消费方处理过的消息，此时消费者就会收到两条内容相同的消息。

解决方案：（借助redis）

1. 消息发送者发送消息时携带一个全局唯一的消息id
2. 消费者获取消费后先根据id在redis/db中查询是否存在消费记录
3. 如果没有消费过就正常消费，消费完毕后写入redis/db
4. 如果消息消费过就直接舍弃

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

如图，在 MQ 里面创建多个 queue，同一规则的数据（对唯一标识进行 hash），有顺序的放入 MQ 的 queue 里面，消费者只取一个 queue 里面获取数据消费，这样执行的顺序是有序的。或者还是只有一个 queue 但是对应一个消费者，然后这个消费者内部用内存队列做排队，然后分发给底层不同的 worker 来处理

8.如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时呢？

你看这问法，其实本质针对的场景，都是说，可能你的消费端出了问题，不消费了；或者消费的速度极其慢。接着就坑爹了，可能你的消息队列集群的磁盘都快写满了，都没人消费，这个时候怎么办？或者是这整个就积压了几个小时，你这个时候怎么办？或者是你积压的时间太长了，导致比如 RabbitMQ 设置了消息过期时间后就没了怎么办？

所以就这事儿，其实线上挺常见的，一般不出，一出就是大 case。一般常见于，举个例子，消费端每次消费之后要写 mysql，结果 mysql 挂了，消费端 hang 那儿了，不动了；或者是消费端出了个什么岔子，导致消费速度极其慢。
关于这个事儿，我们一个一个来梳理吧，先假设一个场景，我们现在消费端出故障了，然后大量消息在 mq 里积压，现在出事故了，慌了。

大量消息在 mq 里积压了几个小时了还没解决

几千万条数据在 MQ 里积压了七八个小时，从下午 4 点多，积压到了晚上 11 点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复 consumer 的问题，让它恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。

一个消费者一秒是 1000 条，一秒 3 个消费者是 3000 条，一分钟就是 18 万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概 1 小时的时间才能恢复过来。

一般这个时候，只能临时紧急扩容了，具体操作步骤和思路如下：

• 先修复 consumer 的问题，确保其恢复消费速度，然后将现有 consumer 都停掉。
• 新建一个 topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。
• 然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。
• 接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。
• 等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。

mq 中的消息过期失效了

假设你用的是 RabbitMQ，RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里，而是大量的数据会直接搞丢。

这个情况下，就不是说要增加 consumer 消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。

假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。

mq 都快写满了

如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

参考博客：
https://hacpai.com/article/1542162310805?m=0&p=1
https://jsbintask.cn/2019/01/28/interview/interview-middleware-manymessage/