MQ-面试大全

### 1、为什么要使用MQ

核心：解耦,异步,削峰

1）解耦：A 系统发送数据到 BCD 三个系统，通过接口调用发送。如果 E 系统也要这个数据呢？那如果 C 系统现在不需要了呢？A 系统负责人几乎崩溃……A 系统跟其它各种乱七八糟的系统严重耦合，A 系统产生一条比较关键的数据，很多系统都需要 A 系统将这个数据发送过来。如果使用MQ，A 系统产生一条数据，发送到 MQ 里面去，哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据，直接从 MQ 里消费即可；如果某个系统不需要这条数据了，就取消对 MQ 消息的消费即可。这样下来，A 系统压根儿不需要去考虑要给谁发送数据，不需要维护这个代码，也不需要考虑人家是否调用成功、失败超时等情况。就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦。

2）异步：A 系统接收一个请求，需要在自己本地写库，还需要在 BCD 三个系统写库，自己本地写库要 3ms，BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 +450 + 200 = 953ms，接近 1s，用户感觉搞个什么东西，慢死了慢死了。用户通过浏览器发起请求。如果使用 MQ，那么 A 系统连续发送 3 条消息到 MQ 队列中，假如耗时 5ms，A 系统从接受一个请求到返回响应给用户，总时长是 3 + 5 = 8ms。

3）削峰：减少高峰时期对服务器压力。

<!–more–>

### 2、MQ有什么优缺点

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰。

**缺点有以下几个：**

**系统可用性降低** 系统引入的外部依赖越多，越容易挂掉。万一 MQ 挂了，MQ 一挂，整套系统崩溃，你不就完了？

**系统复杂度提高** 硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？问题一大堆。

**一致性问题** A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？你这数据就不一致了。

### 3、Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别？

对于吞吐量来说kafka和RocketMQ支撑高吞吐，ActiveMQ和RabbitMQ比他们低一个数量级。对于延迟量来说RabbitMQ是最低的。

##### **1.从社区活跃度**

按照目前网络上的资料，RabbitMQ 、activeM 、ZeroMQ 三者中，综合来看，RabbitMQ 是首选。

##### **2.持久化消息比较**

ActiveMq 和RabbitMq 都支持。持久化消息主要是指我们机器在不可抗力因素等情况下挂掉了，消息不会丢失的机制。

##### **3.综合技术实现**

可靠性、灵活的路由、集群、事务、高可用的队列、消息排序、问题追踪、可视化管理工具、插件系统等等。RabbitMq / Kafka 最好，ActiveMq 次之，ZeroMq 最差。当然ZeroMq 也可以做到，不过自己必须手动写代码实现，代码量不小。尤其是可靠性中的：持久性、投递确认、发布者证实和高可用性。

##### **4.高并发**

毋庸置疑，RabbitMQ 最高，原因是它的实现语言是天生具备高并发高可用的erlang 语言。

##### **5.比较关注的比较，RabbitMQ 和 Kafka**

RabbitMq 比Kafka 成熟，在可用性上，稳定性上，可靠性上， RabbitMq 胜于 Kafka （理论上）。另外，Kafka 的定位主要在日志等方面，因为Kafka 设计的初衷就是处理日志的，可以看做是一个日志（消息）系统一个重要组件，针对性很强，所以如果业务方面还是建议选择 RabbitMq 。还有就是，Kafka 的性能（吞吐量、TPS ）比RabbitMq 要高出来很多。

### **4、如何保证高可用的？**

RabbitMQ 是比较有代表性的，因为是**基于主从**（非分布式）做高可用性的，我们就以 RabbitMQ为例子讲解第一种 MQ 的高可用性怎么实现。RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。单机模式，就是 Demo 级别的，一般就是你本地启动了玩玩儿的?，没人生产用单机模式普通集群模式，意思就是在多台机器上启动多个 RabbitMQ 实例，每个机器启动一个。你**创建的queue**，只会放在一个 **RabbitMQ** **实例上**，但是每个实例都同步 queue 的元数据（元数据可以认为是 queue 的一些配置信息，通过元数据，可以找到 queue 所在实例）。你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。**这方案主要是提高吞吐量的**，就是说让集群中多个节点来服务某个 queue 的读写操作。镜像集群模式：这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会**存在于多个实例上**，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。这样的话，好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。

Kafka 一个最基本的架构认识：由多个 broker 组成，每个 broker 是一个节点；你创建一个topic，这个 topic 可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个partition 就放一部分数据。这就是天然的分布式消息队列，就是说一个 topic 的数据，是**分散放在**多个机器上的，每个机器就放一部分数据**。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，那么此时会从 follower 中重新选举一个新的 leader 出来，大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。写数据的时候，生产者就写 leader，然后 leader 将数据落地写本地磁盘，接着其他 follower 自己主动从 leader 来 pull 数据。一旦所有 follower 同步好数据了，就会发送ack 给 leader，leader 收到所有 follower 的 ack 之后，就会返回写成功的消息给生产者。（当然，这只是其中一种模式，还可以适当调整这个行为）消费的时候，只会从 leader 去读，但是只有当一个消息已经被所有 follower 都同步成功返回 ack 的时候，这个消息才会被消费者读到。

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

消息积压处理办法：临时紧急扩容：先修复 consumer 的问题，确保其恢复消费速度，然后将现有 cnosumer 都停掉。新建一个topic，partition 是原来的 10 倍，临时建立好原先 10 倍的 queue 数量。然后写一个临时的分发数据的 consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。接着临时征用 10 倍的机器来部署 consumer，每一批 consumer 消费一个临时 queue 的数据。这种做法相当于是临时将 queue 资源和 consumer 资源扩大 10 倍，以正常的 10 倍速度来消费数据。等快速消费完积压数据之后，得恢复原先部署的架构，重新用原先的 consumer 机器来消费消息。 MQ中消息失效：假设你用的是 RabbitMQ，RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq里，而是大量的数据会直接搞丢。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上12点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。mq消息队列块满了：如果消息积压在 mq 里，你很长时间都没有处理掉，此时导致 mq 都快写满了，咋办？这个还有别的办法吗？没有，谁让你第一个方案执行的太慢了，你临时写程序，接入数据来消费，消费一个丢弃一个，都不要了，快速消费掉所有的消息。然后走第二个方案，到了晚上再补数据吧。

### 6、让你来设计一个消息队列，你会怎么设计

比如说这个消息队列系统，我们从以下几个角度来考虑一下：首先这个 mq 得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下 kafka 的设计理念，broker -> topic -> partition，每个partition 放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给 topic 增加 partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？其次你得考虑一下这个 mq 的数据要不要落地磁盘吧？那肯定要了，落磁盘才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是 kafka 的思路。其次你考虑一下你的 mq 的可用性啊？这个事儿，具体参考之前可用性那个环节讲解的 kafka 的高可用保障机制。多副本 -> leader & follower -> broker 挂了重新选举 leader 即可对外服务。能不能支持数据 0 丢失啊？可以的，参考我们之前说的那个 kafka 数据零丢失方案。

### **7、 Kafka 概念**

Kafka 是一种高吞吐量、分布式、基于发布/订阅的消息系统，最初由 LinkedIn 公司开发，使用Scala 语言编写，目前是 Apache 的开源项目。

1. broker：Kafka 服务器，负责消息存储和转发

2. topic：消息类别，Kafka 按照 topic 来分类消息

3. partition：topic 的分区，一个 topic 可以包含多个 partition，topic 消息保存在各个partition 上

4. offset：消息在日志中的位置，可以理解是消息在 partition 上的偏移量，也是代表该消息的唯一序号

5. Producer：消息生产者

6. Consumer：消息消费者

7. Consumer Group：消费者分组，每个 Consumer 必须属于一个 group

8. Zookeeper：保存着集群 broker、topic、partition 等 meta 数据；另外，还负责 broker 故障发现，partition leader 选举，负载均衡等功能

### 8、你们为什么使⽤**mq**？具体的使⽤场景是什么？

mq的作⽤很简单，削峰填⾕。以电商交易下单的场景来说，正向交易的过程可能涉及到创建订单、扣减库存、扣减活动预算、扣减积分等等。每个接⼝的耗时如果是100ms，那么理论上整个下单的链路就需要耗费400ms，这个时间显然是太⻓了。如果这些操作全部同步处理的话，⾸先调⽤链路太⻓影响接⼝性能，其次分布式事务的问题很难处理，这时候像扣减预算和积分这种对实时⼀致性要求没有那么⾼的请求，完全就可以通过mq异步的⽅式去处理了。同时，考虑到异步带来的不⼀致的问题，我们可以通过job去重试保证接⼝调⽤成功，⽽且⼀般公司都会有核对的平台，⽐如下单成功但是未扣减积分的这种问题可以通过核对作为兜底的处理⽅案。使⽤mq之后我们的链路变简单了，同时异步发送消息我们的整个系统的抗压能⼒也上升了。

### 9、用过MQ吗？是基于什么做的选型？

我们主要调研了⼏个主流的mq，kafka、rabbitmq、rocketmq、activemq，选型我们主要基于以下⼏个点去考虑：

1. 由于我们系统的qps压⼒⽐较⼤，所以性能是⾸要考虑的要素。

2. 开发语⾔，由于我们的开发语⾔是java，主要是为了⽅便⼆次开发。

3. 对于⾼并发的业务场景是必须的，所以需要⽀持分布式架构的设计。

4. 功能全⾯，由于不同的业务场景，可能会⽤到顺序消息、事务消息等。

基于以上⼏个考虑，我们最终选择了RocketMQ。

### 10、你说到消费者消费失败的问题，那么如果⼀直消费失败导致消息积压怎么处理？

因为考虑到时消费者消费⼀直出错的问题，那么我们可以从以下⼏个⻆度来考虑：

1. 消费者出错，肯定是程序或者其他问题导致的，如果容易修复，先把问题修复，让consumer恢复正常消费

2. 如果时间来不及处理很麻烦，做转发处理，写⼀个临时的consumer消费⽅案，先把消息消费，然后再转发到⼀个新的topic和MQ资源，这个新的topic的机器资源单独申请，要能承载住当前积压的消息

3. 处理完积压数据后，修复consumer，去消费新的MQ和现有的MQ数据，新MQ消费完成后恢复原状

### 11、说说**RocketMQ**实现原理吧？

RocketMQ由NameServer注册中⼼集群、Producer⽣产者集群、Consumer消费者集群和若⼲

Broker（RocketMQ进程）组成，它的架构原理是这样的：

1. Broker在启动的时候去向所有的NameServer注册，并保持⻓连接，每30s发送⼀次⼼跳

2. Producer在发送消息的时候从NameServer获取Broker服务器地址，根据负载均衡算法选择⼀台服务器来发送消息

3. Conusmer消费消息的时候同样从NameServer获取Broker地址，然后主动拉取消息来消费

### 12、RocketMQ为什么不使⽤Zookeeper作为注册中⼼呢？

我认为有以下⼏个点是不使⽤zookeeper的原因：

1. 根据CAP理论，同时最多只能满⾜两个点，⽽zookeeper满⾜的是CP，也就是说zookeeper并不能保证服务的可⽤性，zookeeper在进⾏选举的时候，整个选举的时间太⻓，期间整个集群都处于不可⽤的状态，⽽这对于⼀个注册中⼼来说肯定是不能接受的，作为服务发现来说就应该是为可⽤性⽽设计。

2. 基于性能的考虑，NameServer本身的实现⾮常轻量，⽽且可以通过增加机器的⽅式⽔平扩展，增加集群的抗压能⼒，⽽zookeeper的写是不可扩展的，⽽zookeeper要解决这个问题只能通过划分领域，划分多个zookeeper集群来解决，⾸先操作起来太复杂，其次这样还是⼜违反了CAP中的A的设计，导致服务之间是不连通的。

3. 持久化的机制来带的问题，ZooKeeper 的 ZAB 协议对每⼀个写请求，会在每个 ZooKeeper 节点上保持写⼀个事务⽇志，同时再加上定期的将内存数据镜像（Snapshot）到磁盘来保证数据的⼀致性和持久性，⽽对于⼀个简单的服务发现的场景来说，这其实没有太⼤的必要，这个实现⽅案太重了。⽽且本身存储的数据应该是⾼度定制化的。

4. 消息发送应该弱依赖注册中⼼，⽽RocketMQ的设计理念也正是基于此，⽣产者在第⼀次发送消息的时候从NameServer获取到Broker地址后缓存到本地，如果NameServer整个集群不可⽤，短时间内对于⽣产者和消费者并不会产⽣太⼤影响。

### 13、RocketMQ中的Broker是怎么保存数据的呢？

RocketMQ主要的存储⽂件包括commitlog⽂件、consumequeue⽂件、indexfile⽂件。

Broker在收到消息之后，会把消息保存到commitlog的⽂件当中，⽽同时在分布式的存储当中，每个broker都会保存⼀部分topic的数据，同时，每个topic对应的messagequeue下都会⽣成consumequeue⽂件⽤于保存commitlog的物理位置偏移量offset，indexfile中会保存key和offset的对应关系。

CommitLog⽂件保存于${Rocket_Home}/store/commitlog⽬录中，从图中我们可以明显看出来⽂件名的偏移量，每个⽂件默认1G，写满后⾃动⽣成⼀个新的⽂件。

由于同⼀个topic的消息并不是连续的存储在commitlog中，消费者如果直接从commitlog获取消息效率⾮常低，所以通过consumequeue保存commitlog中消息的偏移量的物理地址，这样消费者在消费的时候先从consumequeue中根据偏移量定位到具体的commitlog物理⽂件，然后根据⼀定的规则（offset和⽂件⼤⼩取模）在commitlog中快速定位。

### 14、RocketMQ中的Master**和**Slave之间是怎么同步数据的呢？

⽽消息在master和slave之间的同步是根据raft协议来进⾏的：

1. 在broker收到消息后，会被标记为uncommitted状态

2. 然后会把消息发送给所有的slave

3. slave在收到消息之后返回ack响应给master

4. master在收到超过半数的ack之后，把消息标记为committed

5. 发送committed消息给所有slave，slave也修改状态为committed

### 15、你知道**RocketMQ**为什么速度快吗？

是因为使⽤了顺序存储、Page Cache和异步刷盘。

1. 我们在写⼊commitlog的时候是顺序写⼊的，这样⽐随机写⼊的性能就会提⾼很多

2. 写⼊commitlog的时候并不是直接写⼊磁盘，⽽是先写⼊操作系统的PageCache

3. 最后由操作系统异步将缓存中的数据刷到磁盘