以下是20道RocketMQ高频面试题：
- 为什么要使用消息队列？
- 解耦：避免系统间直接调用，降低系统耦合度，即使部分系统故障，也不影响其他系统正常运行。
- 异步处理：对于一些非即时性任务，如发送邮件、短信等，可将任务放入消息队列异步处理，提高系统响应速度。
- 削峰填谷：在流量高峰时，将大量请求暂存到消息队列中，让后端系统按一定速度处理，避免系统因过载而崩溃。
- 为什么要选择RocketMQ？
- 高可靠性：通过同步/异步刷盘和多副本机制，保证消息不丢失。
- 功能丰富：支持顺序消息、事务消息、延时消息等，能满足复杂业务需求。
- 性能优越：在高并发情况下，能提供较低的延迟，保证消息快速传递。
- 与阿里云集成好：若系统在阿里云上部署，RocketMQ可无缝对接阿里云的各种服务。
- RocketMQ有什么优缺点？
- 优点：可靠性高、功能丰富、延迟低、与阿里云深度集成。
- 缺点：运维复杂，配置和调优难度较大；社区和生态相对较小，相比Kafka，第三方工具较少。
- 消息队列有哪些消息模型？RocketMQ采用哪种消息模型？
- 消息队列主要有点对点模型和发布/订阅模型。
- RocketMQ采用发布/订阅模型，生产者发布消息到主题（Topic），多个消费者可订阅该主题并接收处理消息。
- RocketMQ的基本架构包含哪些组件？每个组件的作用是什么？
- NameServer：注册中心，维护集群路由信息，如Broker地址、Topic与Queue的路由关系等。
- Broker：消息存储和转发主体，接收生产者消息并存储，为消费者提供消息拉取服务，有Master和Slave之分。
- Producer：消息生产者，将业务消息发送到Broker。
- Consumer：消息消费者，从Broker拉取消息并进行业务处理。
- RocketMQ支持哪些消息发送模式？
- 同步发送：生产者发送消息后，等待Broker响应，可靠性高，但影响发送性能。
- 异步发送：发送消息后不等待响应，继续执行其他任务，Broker存储成功后通过回调接口通知生产者，性能较高，可靠性稍低。
- 单向发送：发送消息后既不等待响应，也不接收回调通知，发送性能最高，但可靠性最低。
- Broker主节点挂了怎么切换？
- 在多master - 多slave模式下，若未配置自动切换，需手动将slave切换为master。
- 若为Dledger模式，集群至少由3个broker构成，当某个master宕机后，会通过raft协议自动选举新的master，实现自动切换。
- RocketMQ如何保证消息的可靠传输？
- 生产者端：可采用同步发送，或利用事务消息保证消息与本地事务一致性，还可开启消息确认机制。
- Broker端：通过同步或异步刷盘将消息持久化到磁盘，利用Master - Slave架构进行数据复制。
- 消费者端：消费者成功处理消息后向Broker确认（ACK），未确认消息不会被删除，处理失败可根据配置重试。
- RocketMQ如何保证消息的顺序消费？ 生产者可将相同键（Key）的消息通过哈希取模等方式发送到同一队列，消费者将consumeMode指定为有序消费，消费者启动时会获取分布式锁，每个线程以消息队列作为key上锁后按顺序消费消息。
- RocketMQ的事务消息是如何实现的？ 基于两阶段提交协议。第一阶段发送半消息，第二阶段执行本地事务，第三阶段根据事务结果向Broker发送提交或回滚消息，若Broker未收到确认消息，会进行事务状态回查。
- 延时消息底层是怎么实现的？ RocketMQ将延时消息发送到特定的Topic，通过定时任务扫描延时消息队列，根据消息的延时级别计算到期时间，到期后将消息重新发送到目标Topic供消费者消费。
- 什么是死信队列？ 死信队列用于存储处理失败或无法处理的消息，当消息消费重试次数达到上限后，会被发送到死信队列，方便开发者后续排查和处理问题消息。
- RocketMQ有几种集群方式？
- 多master模式：配置简单，单个master宕机不影响全局，但未消费消息在恢复前不可订阅。
- 多master - 多slave异步复制：master宕机后slave可提供服务，消息实时性不受影响，但可能丢失部分消息，且slave不会自动切换为master。
- 多master - 多slave同步复制：消息基本不丢失，但发送单个消息的RT可能略高，同样未解决slave自动切换问题。
- Dledger模式：要求至少3个broker，master宕机后可通过raft协议自动选举新master。
- RocketMQ消息堆积了怎么解决？
- 首先排查消费者消费速度慢的原因，如业务逻辑复杂、消费线程数不足等，可优化业务逻辑或增加消费线程数。
- 若为生产者发送速度过快导致，可适当降低发送速度，或增加消费者实例数，提高整体消费能力。
- 还可考虑增加Broker的存储资源，避免因磁盘空间不足等问题影响消息处理。
- RocketMQ如何实现高可用？
- Broker高可用：通过Master - Slave模式实现，Master故障时，Slave自动接管服务。
- NameServer高可用：NameServer之间不进行数据同步，Producer和Consumer连接多个NameServer提高可用性。
- 消息持久化：Broker将消息持久化到磁盘，防止消息丢失。
- RocketMQ的负载均衡机制是如何工作的？
- Producer端：根据Topic路由信息，选择合适的Broker和Queue发送消息，实现写入负载均衡。
- Consumer端：在集群消费模式下，Consumer Group内的消费者按负载均衡策略，消费Topic下的消息队列，实现消费端负载均衡。
- 为什么Consumer要集群部署？可以部署多少个？ 集群部署可提高消息消费能力，实现负载均衡，避免单个Consumer处理能力不足。理论上可部署多个，但受限于系统资源和消息处理能力，过多会导致资源浪费和竞争加剧。
- 如何增加Topic的队列数？增加队列数会有什么影响？ 可通过RocketMQ的管理工具或相关API增加Topic的队列数。增加队列数可提高消息的并发处理能力，提升吞吐量，但会增加内存等资源消耗，也可能导致消息分布更分散，增加管理复杂度。
- RocketMQ如何通过性能优化提高消息的吞吐量？
- 使用内存映射文件和直接内存访问技术，实现零拷贝传输，提高数据传输效率。
- 采用异步刷盘方式，减少磁盘IO对消息写入性能的影响。
- 生产环境用的是同步复制还是异步复制？同步刷盘还是异步刷盘？ 这取决于业务对数据可靠性和性能的要求。若对可靠性要求极高，如金融业务，可采用同步复制和同步刷盘；若更注重性能，可选择异步复制和异步刷盘，但需考虑一定的数据丢失风险。
