RocketMQ相关面试题（中）

---

前言

书接上文（RocketMQ相关面试题（上））

---

1.RocketMQ如何保证消息不丢失？

从三个方面入手：生产者、消费者、broker，缺一不可。
生产者：首先在生产者端，消息的发送分为同步和异步两种，在同步发送消息的情况下，消息的发送会同步阻塞等待Broker返回结果，在Broker确认收到消息之后，生产者才会拿到SendResult。如果这个过程中发生异常，那么就说明消息发送可能失败了，就需要生产者进行重新发送消息。但是Broker其实并不会立即把消息存储到磁盘上，而是先存储到内存中，内存存储成功之后，就返回给确认结果给生产者了。然后再通过异步刷盘的方式将内存中的数据存储到磁盘上。但是这个过程中，如果机器挂了，那么就可能会导致数据丢失。如果想要保证消息不丢失，可以将消息保存机制修改为同步刷盘，这样，Broker会在同步请求中把数据保存在磁盘上，确保保存成功后再返回确认结果给生产者。异步发送的话就需要生产者重写SendCallback的onSuccess和onException方法，用于给Broker进行回调。在方法中实现消息的确认或者重新发送。
Broker：为了保证消息不丢失，RocketMQ肯定要通过集群方式进行部署，Broker 通常采用一主多从部署方式，并且采用主从同步的方式做数据复制。当主Broker宕机时，从Broker会接管主Broker的工作，保证消息不丢失。同时，RocketMQ的Broker还可以配置多个实例，消息会在多个Broker之间进行冗余备份，从而保证数据的可靠性。默认方式下，Broker在接收消息后，写入 master 成功，就可以返回确认响应给生产者了，接着消息将会异步复制到 slave 节点。但是如果这个过程中，Master的磁盘损坏了。那就会导致数据丢失了。如果想要解决这个问题，可以配置同步复制的方式，即Master在将数据同步到Slave节点后，再返回给生产者确认结果。
消费者：在消费者端，需要确保在消息拉取并消费成功之后再给Broker返回ACK，就可以保证消息不丢失了，如果这个过程中Broker一直没收到ACK，那么就可以重试。
所以，在消费者的代码中，一定要在业务逻辑的最后一步return ConsumeConcurrentlyStatus.CONSUME_SUCCESS; 当然，也可以先把数据保存在数据库中，就返回，然后自己再慢慢处理。
但是，需要注意的是RocketMQ和Kafka一样，只能最大限度的保证消息不丢失，但是没办法做到100%保证不丢失。

2.RocketMQ如何实现延时消息？

RocketMQ是支持延迟消息的，延迟消息写入到Broker后，不会立刻被消费者消费，需要等待指定的时长后才可被消费处理。
当消息发送到Broker后，Broker会将消息根据延迟级别进行存储。RocketMQ的延迟消息实现方式是：将消息先存储在内存中，然后使用Timer定时器进行消息的延迟，到达指定的时间后再存储到磁盘中，最后投递给消费者。
但是，RocketMQ的延迟消息并不是支持任意时长的延迟的，它只支持（5.0之前）：1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h这几个时长。
但是，由于Timer定时器有一定的缺陷，比如在定时器中有大量任务时，会导致定时器的性能下降，从而影响消息投递。
因此，在RocketMQ 5.0中，采用了一种新的实现方式：基于时间轮的定时消息。时间轮是一种高效的定时器算法，能够处理大量的定时任务，并且能够在O(1)时间内找到下一个即将要执行的任务，因此能够提高消息的投递性能。并且，基于时间轮的定时消息能够支持更高的消息精度，可以实现秒级、毫秒级甚至更小时间粒度的定时消息。
具体实现方式如下：
RocketMQ在Broker端使用一个时间轮来管理定时消息，将消息按照过期时间放置在不同的槽位中，这样可以大幅减少定时器任务的数量。时间轮的每个槽位对应一个时间间隔，比如1秒、5秒、10秒等，每次时间轮的滴答，槽位向前移动一个时间间隔。当Broker接收到定时消息时，根据消息的过期时间计算出需要投递的槽位，并将消息放置到对应的槽位中。当时间轮的滴答到达消息的过期时间时，时间轮会将该槽位中的所有消息投递给消费者。

3.RocketMQ有几种集群方式？

3种，分别是单Master模式、多Master模式以及多Master多Slave模式。
单Master集群：这是一种最简单的集群方式，只包含一个Master节点和若干个Slave节点。所有的写入操作都由Master节点负责处理，Slave节点主要用于提供读取服务。当Master节点宕机时，集群将无法继续工作。
多Master集群：这种集群方式包含多个Master节点，不部署Slave节点。优点是配置简单，单个Master宕机或重启维护对应用无影响，性能最高；缺点是单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响。
多Master多Slave集群：这种集群方式包含多个Master节点和多个Slave节点。每个Master节点都可以处理写入操作，并且有自己的一组Slave节点。当其中一个Master节点宕机时，消费者仍然可以从Slave消费。优点是数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；缺点是性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备机不能自动切换为主机。

4.RocketMQ消息堆积了怎么解决？

RocketMQ的消息堆积，一般都是因为客户端本地消费过程中，由于消费耗时过长或消费并发度较小等原因，导致客户端消费能力不足，出现消息堆积的问题。
当线上出现消息堆积的问题时，一般有以下几种方式来解决：
增加消费者数量：消息堆积了，消费不过来了，那就把消费者的数量增加一下，让更多人的实例来消费这些消息。
提升消费者消费速度：消费者消费的慢可能是消息堆积的主要原因，想办法提升消费速度，比如引入线程池、本地消息存储后即返回成功后续再慢慢消费等。
降低生产者的生产速度：如果生产者可控的话，可以让生产者生成消息的速度慢一点。
清理过期消息：有一些过期消息、或者一直无法成功的消息，在业务做评估之后，如果无影响或者影响不大，其实是可以清理的。
调整 RocketMQ 的配置参数：RocketMQ 提供了很多可配置的参数，例如消息消费模式、消息拉取间隔时间等，可以根据实际情况来调整这些参数，从而优化消息消费的效率。
增加 Topic 队列数：如果一个 Topic 的队列数比较少，那么就容易出现消息堆积的情况。可以通过增加队列数来提高消息的处理并发度，从而减少消息堆积。

总结

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