RocketMQ

典型回答 MQ的消费模式可以一共有3种，分别是推Push、拉Pull以及5.0中推出的 POP 模式。本文主要介绍下 pull 和 push，pop 单独介绍。 Push是服务端主动推送消息给客户端，Pull是客户端需要主动到服务端轮询获取数据。 他们各自有各自的优缺点，推优点是及时性较好，但如果客户端没有做好流控，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃。 拉优点是客户端可以依据自己的消费能力进行消费，但是频繁拉取会给服务端造成压力，并且可能会导致消息消费不及时。 RocketMQ既提供了Push模式也提供了Pull模式，开发者可以自行选择，主要有两个Consumer可以供开发者选择： 1 2 3 4 5 6 7 8 9 public class DefaultMQPullConsumer extends ClientConfig implements MQPullConsumer { // https://github.com/apache/rocketmq/blob/develop/client/src/main/java/org/apache/rocketmq/client/consumer/DefaultMQPullConsumer.java } public class DefaultMQPushConsumer extends ClientConfig implements MQPushConsumer { //https://github.com/apache/rocketmq/blob/develop/client/src/main/java/org/apache/rocketmq/client/consumer/DefaultMQPushConsumer.java } 其中DefaultMQPullConsumer已经不建议使用了，建议使用DefaultLitePullConsumer。Lite Pull Consumer是RocketMQ 4.6.0推出的Pull Consumer，相比于原始的Pull Consumer更加简单易用，它提供了Subscribe和Assign两种模式。 /** @deprecated Default pulling consumer. This class will be removed in 2022, and a better implementation {@link DefaultLitePullConsumer} is recommend to use in the scenario of actively pulling messages. ...

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

典型回答 ✅什么是Kafka的重平衡机制？ 关于Kafka的重平衡问题请看上面这篇，那么RocketMQ也有这样的问题吗？这要看是哪种消费方式，RocketMQ 支持两种消息模式：广播消费（ Broadcasting ）和集群消费（ Clustering ）。 ✅RocketMQ怎么实现消息分发的？ 广播模式下，每个消费者都会消费所有消息，不存在重平衡问题。 但是如果实在默认的集群模式下，消费者在一个消费组中，多个消费者会均摊消费，这时候就涉及重平衡的问题。 不过和Kafka不同的是，RocketMQ他只有个定时重平衡的机制，他会自动的每 20s 进行一次重平衡检查，如果发现有消费者新增或离开时，会触发重新分配队列。 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // 默认20秒，可以通过rocketmq.client.rebalance.waitInterval配置调整 private static long waitInterval = Long.parseLong(System.getProperty( "rocketmq.client.rebalance.waitInterval", "20000")); @Override public void run() { log.info(this.getServiceName() + " service started"); while (!this.isStopped()) { // 等待20秒 this.waitForRunning(waitInterval); // 执行重平衡 this.mqClientFactory.doRebalance(); } log.info(this.getServiceName() + " service end"); } 正是因为RocketMQ 定时进行重平衡的，而不是像 Kafka 依赖心跳机制做实时重平衡，那么就会出现如果一个消费者宕机，最多需要 20s 才能触发重平衡，导致这段时间内消息堆积在已宕机的消费者上，影响吞吐。不过定时也有个好处就是避免很多网络抖动，或者频繁增加、退出消费者等导致的频繁的重平衡。 ...

典型回答 ✅RocketMQ的事务消息是如何实现的？ ✅Kafka支持事务消息吗？如何实现的？ 以上是关于Kafka和RocketMQ的事务消息的介绍。 他们都叫事务消息，目的都是为了保证ACID，其实最重要的就是一个原子性。但是他们的目的和解决问题不同。 Kafka的事务消息，确保的是一组发送操作要么全部成功，要么全部失败，以保证消息处理的原子性。 RocketMQ的事务消息，确保的是发送方的本地事务和消息发送以原子性方式执行，即要么都成功，要么都失败。 所以，RocketMQ的事务消息，经常被用来解决分布式场景下的数据一致性问题，是分布式事务的一种常见方案。 而Kafka的事务消息，主要是用来来配合 Kafka 的幂等机制来实现 Kafka 的 Exactly Once 语义（每条消息只会被精确地传递一次：既不会多，也不会少；）。

典型回答 ✅RocketMQ如何保证消息不丢失？ 先看下上面这篇，如果保证不丢，那么大概就能知道，如果丢了可能是啥原因了。从发送端、Broker端以及消费者端分别分析。 发送端 用了单向发送 RocketMQ提供了一种发送方只负责发送消息，不等待服务端返回响应且没有回调函数触发，即只发送请求不等待应答的发送方式，叫做单向发送。 1 producer.sendOneway(msg); 用了这种发送方式，是非常有可能发送不成功，导致消息丢失的。 未处理发送失败的情况 如果使用了同步发送或者异步发送，但是没有处理好异常的情况，没有进行合理的重试，那么也会导致消息丢失。 1 2 3 4 5 6 7 8 9 10 try { SendResult sendResult = producer.send(msg); // 同步发送消息，只要不抛异常就是成功。 if (sendResult != null) { //忽略失败 } } catch (Exception e) { //忽略异常 } 1 2 3 4 5 6 7 8 9 10 11 12 13 // 异步发送消息, 发送结果通过callback返回给客户端。 producer.sendAsync(msg, new SendCallback() { @Override public void onSuccess(final SendResult sendResult) { // 消息发送成功。 System.out.println("send message success. topic=" + sendResult.getTopic() + ", msgId=" + sendResult.getMessageId()); } @Override public void onException(OnExceptionContext context) { // 忽略异常 } }); 发送过程中，Producer挂了 这种情况也有可能出现，就是消息正准备发呢，但是没等发出去，应用就挂了。那么消息也可能会丢了 ...

典型回答 RocketMQ重复消费，指的是同一个消息重复来了多次，那么通常的情况有很多，常见的有以下几个。 Consumer返回给Broker消费失败（常见） 不管是因为什么情况了，是真的消费失败了，还是出现了异常了，还是明明消费成功了，但是你错误的返回了失败等等情况，只要你给RocketMQ返回的是 RECONSUME_LATER ，那么消息就会重投，有重投就会有重复消费。 Consumer消费处理超时了（常见） 不只是返回失败的情况，如果消费方法执行时间过长，RocketMQ 可能判定消费者失联，也一样会重投消息。 那就和上面的情况一样了。 消息发重了（常见） 这种比较常见的，因为有的时候我们调用MQ发送消息的时候，因为网络抖动或者异常，我们会把一些实际成功的消息重发一遍，那么就会有两条一模一样的消息，那么对于消费者来说就可能会重复消费了。 广播模式 这不是重复消费，而是 RocketMQ 的广播模式特性，他就是会把一条消息发送给所有的消费者，但是如果大家处理的逻辑都一样， 那么和重复消费的表现是一样的。 重平衡（kafka） ✅RocketMQ和Kafka一样有重平衡的问题吗？ Kafka 在消费者组 rebalance 时，新消费者加入/失败、分区重新分配，如果 offset 没及时提交，重新分配分区时会从老的 offset 重新开始消费。那么就会重复消费。 扩展知识 如何保证消息幂等 ✅如何解决消息重复消费、重复下单等问题？

典型回答 普通消息，就是很普通，没有什么特别的， 和顺序消息相比的话，就是消息发送到 MQ 后，消费者不保证严格按照发送顺序消费。消息可能会被乱序消费。 顺序消息是指生产者按照顺序发送消息，消费者也必需严格按顺序消费的消息。一般是通过绑定同一个分区来实现的。 ✅RocketMQ如何保证消息的顺序性？ 顺序消息一般用在对顺序性有严格要求的场景中，比如是涉及到状态流转，尤其是那种状态流转的时间间隔很短的。 比如贷款的还款成功消息和结清消息。交易的确认收货消息和订单完结消息，基本都是同时发生的。如果系统是分别要处理这两个消息，那么可能就需要先处理确认收货，再处理订单完结，否则就会出问题的。 （以下部分为个人经验，如果面试官经验丰富，你就和他提，如果感觉他也就一般，就不要提了，他可能听不懂。（手动狗头）） 但是大多数情况下，我们用顺序消息的并不多，因为这只对收消息的应用有好处，而对发送消息的应用没有什么好处，反而增加了复杂性（而且还有吞吐量低、维护成本高等缺点，后面扩展知识介绍）。而要做顺序消息，又需要发送者来做代码改造，所以很多系统都不愿意改，比如交易系统，不可能这么改的。 所以，实际上的大多数场景，并不一定会直接用MQ的顺序消息，而是倾向于消费者自己排序。比如下面这篇文中介绍的几种方案： ✅MQ出现消息乱序了如何解决？ 扩展知识 顺序消息 其实，顺序消息一般用的并不多，上面提了原因和替代方案。确实，他的缺点也比较明显。 1、并发能力受限 为了保证顺序，通常会把消息按照 key 分配到固定队列或分区。并且要求同一个 key 的消息串行消费。 这就导致消息无法并发消费，那么处理速度就会大大下降，尤其是当某个消息处理慢的话，会拖慢整个队列的速度。 2、发消息复杂 如果顺序消息消费失败，需要重试，且必须保证重试后顺序仍然正确。所以这种容错策略设计起来都比较复杂。 而且一旦一个消息处理失败，可能会阻塞后续消息的发送和消费。 3、可能导致数据倾斜 为了保证顺序，消息必须按照 相同 key 分区到同一个队列。如果业务 key 太多或者分布不均匀，会导致队列热点和消费不平衡。

典型回答 在使用消息队列时，虽然它能有效解耦系统、削峰填谷、提升异步处理能力，但实际工程中也存在不少“坑” 1、丢消息 不管是哪种MQ，用了什么样的方案，都只能尽可能的保障消息不丢，但是都没办法彻底解决消息丢失的问题，在极限情况下，消息还是可能会丢的。 ✅Kafka如何保证消息不丢失？ ✅为什么Kafka没办法100%保证消息不丢失？ ✅RocketMQ如何保证消息不丢失？ 想要尽量确保消息的可靠性，可以用本地消息表或者事务消息： ✅如何基于MQ实现分布式事务 2、消息重复 在MQ的使用中，尤其是消费者端，最常见的问题就是消息重复了，这个问题发生的原因有很多： 1、发送者多发了 2、消息第一次处理失败，又重投了 都有可能导致消息重复，所以，这是一个必须要解决的问题，常见的方案就是实现消息的幂等消费。 ✅RabbitMQ如何防止重复消费 3、消息堆积 相信很多人也都遇到过消息堆积的问题，这个问题也常见，因为MQ的主要功能就是削峰填谷，既然他做了削峰填谷了，那么他必然有消息堆积的能力，不然他怎么做削峰填谷呢？ 所以，消息堆积很常见，遇到这个问题，有很多不同的解法，给大家一条解决的SOP： ✅RocketMQ消息堆积了怎么解决？ 4、消息乱序 消息乱序指的是消息没有按照我们希望的顺序投递，这个也有很多原因，比如发送方就没有按照顺序发送，或者broker投递的时候就不是有序的，或者是消费者处理的时候因为网络延迟啥的就没有保障顺序。 解决方案也有的，要么是用顺序消息，要么就是自己实现排序 ✅MQ出现消息乱序了如何解决？ 5、消息延迟 这个其实不算啥问题，和消息堆积一样，消息延迟本来就是MQ的一个特性，是个feature，不是个bug，哈哈哈。 想要减少延迟，那么就提升消费速度吧，搞消费者组，用批量消费，或者多线程消费都可以，总之就是让他消费的更快。 6、重平衡 当消费者数量、topic数量等发生变化的时候，MQ会触发重平衡，这时候可能会带来重复消费、乱序、STW等问题。需要重视。 ✅MQ的重平衡会带来哪些问题？ ✅什么是Kafka的重平衡机制？