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的队列中堆积,而不是在客户端堆积,通过队列的缓冲来起到削峰填谷的作用!
总结
欢迎大家讨论,如有错误还请指正!