RocketMQ相关面试题（下）

---

前言

前文指路：
RocketMQ相关面试题（上）
RocketMQ相关面试题（中）

---

1.RocketMQ怎么实现消息分发的？

RocketMQ 支持两种消息模式：广播消费和集群消费。

• 广播消费：当使用广播消费模式时，RocketMQ 会将每条消息推送给集群内所有的消费者，保证消息至少被每个消费者消费一次。
  广播模式下，RocketMQ 保证消息至少被客户端消费一次，但是并不会重投消费失败的消息，因此业务方需要关注消费失败的情况。并且，客户端每一次重启都会从最新消息消费。客户端在被停止期间发送至服务端的消息将会被自动跳过。
• 集群消费：当使用集群消费模式时，RocketMQ 认为任意一条消息只需要被集群内的任意一个消费者处理即可。
  集群模式下，每一条消息都只会被分发到一台机器上处理。但是不保证每一次失败重投的消息路由到同一台机器上。一般来说，用集群消费的更多一些。

2.RocketMQ的消息是推还是拉？

MQ的消费模式可以一共有3种，分别是推Push、拉Pull以及5.0中推出的 POP 模式。
Push：服务端主动推送消息给客户端，优点是及时性较好，但如果客户端没有做好流量控制，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃。
Pull：客户端需要主动到服务端轮询获取数据，优点是客户端可以依据自己的消费能力进行消费，但是频繁拉取会给服务端造成压力，并且可能会导致消息消费不及时。

3.介绍下 RocketMQ 5.0中的 pop 模式

在5.0之前，RocketMQ 的消息投递方式有推和拉两种
RocketMQ 5.0 引入的一种新的消费模式——Pop 模式，它结合了 Pull 和 Push 模式的优点，提供了一种高效、低延迟的消息消费方式。
Pop 模式其实也是一种拉的模式，主要是来代替原来的 push 模式的。
在5.0以前的 push 模式中，客户端在开始消费消息前，会需要通过负载均衡算法计算出自己需要消费哪些 Queue，每当 Consumer 数量发生变化时就会触发重平衡ReBalance。这个负载均衡是在客户端做的，也就是消费者这里，这也就意味着如果负载均衡时间过长会影响消费者的消费。
但是，这种模式有个问题，那就是无法通过一直增加客户端数量的方式来提升消费能力。因为 Queue 数量有限，客户端数量一旦达到 Queue 数量，再扩容的话，也会因为无法分配到 Queue而无法消费。这也就是传统的 push 模式的性能瓶颈。除了负载均衡以外，push 模式中，消费者除了要做负载均衡以外，还有很多其他的申请要求，比如消息拉取，消息消费位点管理等等。这使得客户端的职责很大，出错的概率也比较大。
还有一个问题，那就是如果某个消费者hang主，会导致分配到该消费者的消息队列中的消息无法消费，导致消息积压；于是在5.0中推出了一个新的 POP模式，来解决这些问题。
在 POP 模式中，消费者不需要感知到分区，即MessageQueue 和消费者不在进行绑定了，并且POP的消费位点也由Broker保存和控制。消费者直接通过 POP 模型提供的接口去获取到数据，消费成功后 ACK 数据。这样做好处就是消费者只需要负责POP 消息，不再需要进行负载均衡以及消息的进度管理。并且即便某个消费者hang住，其他消费者依旧可以继续消费队列中的数据，不会造成消息堆积。

4.用了RocketMQ一定能实现削峰的效果吗？

我们都知道，MQ有三个好处，异步、解耦，削峰填谷。
在高并发场景下，系统可能会面临短时间内大量请求涌入，导致系统负载急剧上升，甚至超过系统的处理能力，造成服务瘫痪。使用MQ来缓冲这些请求，可以将大量并发请求暂存到队列中，然后按照系统能够处理的速度逐渐消费这些请求。这样可以避免系统因为瞬间的高并发而崩溃，实现系统流量的平滑处理。这就是削峰填谷。
但是，并不是说用了MQ了就一定实现了削峰填谷了。这要看MQ的消费方式。
MQ的消息有推和拉两种模式，如果是那种推的模式，会在上游发送消息之后，就立即推给消费者，那这种情况对于接收消息的人来说，还是承担了很大的请求量。而如果消费者的消费能力不行，那么消息也会堆积到消费者端。并且一旦消息量太大，也会导致消费失败，那么消息就会重投，这就会导致更多的请求量过来。所以，如果想要起到很好地削峰填谷的作用，需要使用拉的模式来获取消息，这样自己就可以控制速度了。消息就可以在MQ的队列中堆积，而不是在客户端堆积，通过队列的缓冲来起到削峰填谷的作用！

---

总结

欢迎大家讨论，如有错误还请指正！