消息队列MQ面试题及学习笔记
前段时间看了中华石杉老师讲解的消息队列，感受很深刻，之前也了解MQ，在工作中也会用到，但是没有进行过系统的整理和反思，当看到一些问题时，一时间真不知道怎么回答。所以在此处进行记录一下，自己也对消息队列有个深刻的认识。
面试题
- 为什么使用消息队列？
- 消息队列有什么优点和缺点？
- Kafka、ActiveMQ、RabbitMQ、RocketMQ、Pulsar不同MQ中间件有什么区别及适用场景？
- 如何保证消息队列的高可用？
- 有几百万消息持续积压几小时，你会如何处理？
- 如何解决消息队列的延时以及过期失效问题？
- 消息队列满了以后该怎么处理？
- 如果让你写一个消息队列，该如何进行架构设计？
- ······
1 为什么使用消息队列
其实是问消息队列都有哪些使用场景，然后你说一下你项目里具体是什么业务场景，有什么技术挑战，如果不用MQ就会很麻烦，，在这个场景里为什么用，解决了什么问题，有什么好处。
MQ，消息队列，消息可以理解为一个业务现场，而队列则是保存这个业务现场的容器，而B服务对消息的处理，则是一个对业务现场的异步处理。所以，消息队列的本质，就是将某个业务现场暂存下来，异步处理。异步，解耦，消峰，MQ的三大主要应用场景。
-
异步。异步就是MQ的第一个能力。可以将一些非核心流程，如日志，短信，邮件等，通过MQ的方式异步去处理。这样做的好处是缩短主流程的响应时间，提升用户体验。
-
解耦。假设现在，日志不光要插入到数据库里，还要在硬盘中增加文件类型的日志，同时，一些关键日志还要通过邮件的方式发送给指定的人。那么，如果按照原来的逻辑，A可能就需要在原来的代码上做扩展，除了B服务，还要加上日志文件的存储和日志邮件的发送。但是，如果你使用了MQ，那么，A服务是不需要做更改的，它还是将消息放到MQ中即可，其它的服务，无论是原来的B服务还是新增的日志文件存储服务或日志邮件发送服务，都直接从MQ中获取消息并处理即可。这就是解耦，它的好处是提高系统灵活性，扩展性。
-
消峰。这个其实也很好理解，因为MQ的本质就是业务的排队。所以，面对突然到来的高并发，MQ也可以不用慌忙，先排好队，不要着急，一个一个来。消峰的好处就是避免高并发压垮系统的关键组件，如某个核心服务或数据库等。
2 使用消息队列有什么优缺点？
优点就是上面说的，在特殊场景下可以解决特定的问题，有其对应的好处：异步，解耦，削峰；
缺点：
- 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来就是A系统调用BCD三个系统的接口就好了，这4个系统好好的，你偏加入个MQ进来，万一MQ挂了，业务流程走不下去了，整套系统崩溃了；
- 系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？等等一系列问题；
- 一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求成功了。但是在异步处理过程中，BD两个系统写库成功，但是C系统写库失败，怎么办，数据不一致了；
所以消息队列，实际上是一种非常复杂的架构，引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉。最后，系统复杂度提升了一个数量级，可能比原来的复杂10倍。但是关键时刻，用还是要用的。
3 Kafka、ActiveMQ、RabbitMQ、RocketMQ、Pulsar不同MQ中间件有什么区别及适用场景？
此处见下表总结
4 如何保证消息队列的高可用
RabbitMQ的高可用
RabbitMQ是比较有代表性的，因为是基于主从做高可用的，我们就以他为例讲解第一种MQ的高可用性怎么实现。rabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式；
（1）单机模式
demo级别，一般自己本地启动玩玩，生产环境没人用；
（2）普通集群模式
意思就是在多台机器上启动多个rabbitMQ实例，每个机器启动一个。但是你创建的queue，只会放在一个rabbitmq实例上，但是每个实例都同步queue的元数据。等你消费的时候，实际上如果连接到了另外一个实例，那么那个实例就会从queue所在实例上拉取数据过来。
这种方式确实很麻烦，也不怎么好，没做到所谓的分布式，就是普通集群。因为这导致你要么消费者每次随机连接一个实例，然后拉取数据，要么固定连接那个queue所在实例消费数据。前者有数据拉取的开销，后者导致单实例性能瓶颈。
而且如果那个放queue的实例宕机了，会导致接下来其他实例就无法从那个实例拉取。如果你开启了消息持久化，消息不一定会丢，但是得等这个实例回复了，然后才能从这个queue拉取数据。
所以这个事就比较尴尬了，这就没有什么所谓的高可用性可言了，这个方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个queue的读写操作。
（3）镜像集群模式
这种模式，才是所谓的rabbitMQ的高可用模式，跟普通集群模式不一样的是，你创建的queue，无论元数据还是queue里的消息都会存在于多个实例上，然后每次你写消息到queue的时候，都会自动把消息进行同步到多个实例的queue里。
这样的话，好处在于，你任何一个机器宕机了，别的机器都可以用。坏处在于，第一，性能开销太大，消息同步所有机器，导致网络带宽压力和消耗很重；第二，没有扩展性，如果某个queue负载很重，你加机器，新增的机器也包含了这个queue的所有数据，并没有办法线性扩展你的queue。
如何开启镜像集群模式呢？rabbitmq有很好的管理控制台，在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候可以要求数据同步到所有节点的，也可以要求就同步到指定数量的节点，然后你再次创建queue的时候，应用这个策略，就会自动将数据同步到其他的节点上。
Kafka的高可用
Kafka，一个最基本的架构认识：多个broker组成，每个broker是一个节点；你创建一个topic，这个topic就可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition只放一部分数据。
这就是天然的分布式消息队列，就是说一个topic的数据，是分散放在多个机器上的，每个机器就放一部分数据。实际上rabbitmq之类的并不是分布式消息队列，就是传统的消息队列，只不过提供了一些集群、HA的机制而已，因为无论怎么玩儿，rabbitmq一个queue的数据都是放在了一个节点里的，镜像集群下，也是每个节点都放这个queue的完整数据，
kafka 0.8以前，是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
0.8以后，提供了HA机制，就是replica副本机制。每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。然后所有replica会选举一个leader出来，那么生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候，leader会负责把数据同步到所有follower上去，读的时候就直接读leader上数据即可。只能读leader？很简单，要是你可以随机读写每个follower，那么就要关心数据一致性的问题，系统复杂度太高，容易出问题。kafka会均匀的将一个partition的所有replica分布在不同机器上，这样才可以提高容错性。
现在就有高可用性了，因为如果某个broker宕机了，那个broker上面的partition在其他机器上都有副本的，如果这上面有某个partition的leader，那么此时会重新选举一个新的leader出来，大家继续读写那个新的leader即可。
写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据，一旦所有follower同步好数据了，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。（当然这只是其中一种模式，还可以适当调整这个行为）
消费的时候，只会从leader去读，但是只有当一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。
5 有几百万消息持续积压几小时，你会如何处理？
几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多。这个是我们真实遇到过的一个场景，确实是线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不能在面试的时候说吧。一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条
所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来
一般这个时候，只能操作临时紧急扩容了，具体操作步骤和思路如下：
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机器来消费消息
6 如何解决消息队列的延时以及过期失效问题？
假设你用的是rabbitmq，rabbitmq是可以设置过期时间的，就是TTL，如果消息在queue中积压超过一定的时间就会被rabbitmq给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在mq里，而是大量的数据会直接搞丢。
这个情况下，就不是说要增加consumer消费积压的消息，因为实际上没啥积压，而是丢了大量的消息。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。
这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入mq里面去，把白天丢的数据给他补回来。也只能是这样了。
假设1万个订单积压在mq里面，没有处理，其中1000个订单都丢了，你只能手动写程序把那1000个订单给查出来，手动发到mq里去再补一次
7 消息队列满了以后该怎么处理？
如果走的方式是消息积压在mq里，那么如果你很长时间都没处理掉，此时导致mq都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。
8 如果让你写一个消息队列，该如何进行架构设计？
其实聊到这个问题，一般面试官要考察两块：
（1）你有没有对某一个消息队列做过较为深入的原理的了解，或者从整体了解把握住一个mq的架构原理；
（2）看看你的设计能力，给你一个常见的系统，就是消息队列系统，看看你能不能从全局把握一下整体架构设计，给出一些关键点出来；
说实话，我一般面类似问题的时候，大部分人基本都会蒙，因为平时从来没有思考过类似的问题，大多数人就是平时埋头用，从来不去思考背后的一些东西。类似的问题，我经常问的还有，如果让你来设计一个spring框架你会怎么做？如果让你来设计一个dubbo框架你会怎么做？如果让你来设计一个mybatis框架你会怎么做？
其实回答这类问题，说白了，起码不求你看过那技术的源码，起码你大概知道那个技术的基本原理，核心组成部分，基本架构构成，然后参照一些开源的技术把一个系统设计出来的思路说一下就好
比如说这个消息队列系统，我们来从以下几个角度来考虑一下
（1）首先这个mq得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka的设计理念，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了。
（2）其次你得考虑一下这个mq的数据要不要落地磁盘吧？那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。
（3）其次你考虑一下你的mq的可用性啊？这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。
（4）能不能支持数据0丢失啊？可以的，参考我们之前说的那个kafka数据零丢失方案
其实一个mq肯定是很复杂的，面试官问你这个问题，其实是个开放题，他就是看看你有没有从架构角度整体构思和设计的思维以及能力。确实这个问题可以刷掉一大批人，因为大部分人平时不思考这些东西。