一、【每日一问：20250626】说说RocketMQ的主要特性有哪些？在业务场景中作用是什么？
RocketMQ的主要特性
-
高吞吐量：RocketMQ可以处理高流量、低延迟的数据流，非常适合金融、电子商务等高并发场景。
-
高可靠性：通过消息持久化、多副本机制，RocketMQ确保消息的高度可靠性。
-
灵活的消息模型：支持多种模型，包括点对点和发布/订阅。
-
支持顺序消息：可以保证在同一主题内，消息的消费顺序。
-
事务消息：支持分布式事务，确保消息与数据库操作的一致性。
-
丰富的消息过滤机制：支持基于Tag和属性的消息过滤。
应用场景：
-
系统解耦：微服务架构中，服务间通信通过消息中间件实现解耦，降低服务间的相互依赖。
-
异步处理：非实时处理任务通过消息队列异步执行，提高系统响应速度。
-
流量削峰：在高并发情况下，消息队列可以缓冲流量，防止流量骤增导致系统崩溃。
-
事件驱动架构：实现复杂业务流程的事件驱动，推动业务中各个阶段的事件流转。
-
日志处理：收集和处理日志、监控数据等场景，尤其适合大规模数据的实时处理。
二、【每日一问：20250627】RocketMQ消息是如何存储的?@所有人
【每日一问：20250627】
问：RocketMQ消息是如何存储的?
答：参考答案：
RocketMQ的消息存储是一个复杂而高效的过程，设计上充分考虑了性能和扩展性。消息存储的主要组件包括 CommitLog 文件、消费队列文件（ConsumeQueue）、以及索引文件（IndexFile）。我们来详细解释一下这几个核心部分。
- CommitLog文件
CommitLog是RocketMQ的核心存储文件，负责保存消息的完整内容。
●顺序写入：所有的消息都顺序写入CommitLog文件，这种方式减少了磁盘寻道时间，提高了写入性能。
●文件滚动：CommitLog按照固定大小（比如1GB）进行分片。当一个文件写满后，会创建一个新的文件。
●存储所有数据：包括消息体、主题、队列ID等。
- ConsumeQueue文件
ConsumeQueue是针对消息的逻辑视图，旨在加快消费者对消息的访问速度。
●条目固定：每个ConsumeQueue条目固定为20字节，包含消息在CommitLog中的偏移量、消息大小、Tag哈希值。
●独立文件：每个主题的每个队列都有独立的ConsumeQueue文件，文件路径为store/consumequeue/{topic}/{queueId}。
●快速定位：通过ConsumeQueue，消费者无需扫描整个CommitLog即可快速找到消息的位置。
- IndexFile文件
IndexFile用于支持消息的快速检索。
●哈希索引：为消息的key建立哈希索引，支持通过key快速检索消息偏移。
●增强查询：IndexFile是可选的，用于需要基于消息属性进行快速查找的场景。
消息存储流程
1.接收消息：Broker接收到消息后，将其放入内存缓冲区（待写入CommitLog）。
2.写入CommitLog：
●每条消息追加到当前活跃的CommitLog文件中。使用顺序写入提升写入效率和磁盘利用率。
3.同步到ConsumeQueue：
●异步转发服务（ReputMessageService）从CommitLog读取新写入的消息。
●将消息的偏移量和其他元数据（如大小和Tag哈希值）存储到相应的ConsumeQueue文件中。
4.更新IndexFile（可选）：
●若消息带有key（如业务ID），则将其哈希和偏移量存入IndexFile。
●这样，可以通过该key快速查找消息。
三、【每日一问：20250628】问：讲讲RocketMQ的Broker有哪几种集群模式？
RocketMQ的Broker有三种集群模式：
-
单Master模式：只有一个Master节点，其他都是Slave节点。Master节点负责响应客户端的请求并存储消息，Slave节点只同步Master节点的消息，也会响应部分客户端的读请求。这种模式的优点是简单易部署，但是存在单点故障的问题，如果Master节点宕机，会导致整个服务不可用。
-
Master-Slave模式（经典双集群部署）：一个Master节点对应多个Slave节点，Master和Slave都是独立的NameServer。Master节点负责响应客户端请求并存储消息，Slave节点只同步Master节点的消息，也会响应部分客户端的读请求。这种模式的优点是高可用性，即使Master节点宕机，Slave节点可以自动升级为Master节点，继续提供服务。但是，如果只有一个Master节点，存在单点故障的问题。
-
Dledger模式（高可用集群部署）：在Master-Slave模式的基础上增加了Raft协议，实现了自动脑裂后的数据高可靠性。即使某个节点从网络上掉下来或者宕机后，仍然能够保证所有的消息不会丢失。这种模式的优点是高可用性和高可靠性，即使某个节点出现故障，也能保证服务的可用性。
四、【每日一问：20250629】讲讲RocketMQ的事务消息的原理是什么？
【每日一问参考答案：20250629】讲讲RocketMQ的事务消息的原理是什么？
RocketMQ事务消息是一种用于确保分布式系统中消息一致性的机制，主要是利用了消息中间件的二阶段提交机制，可以解决分布式系统中由于网络、系统故障等原因导致的消息不一致问题。以下是RocketMQ事务消息的基本原理：
事务消息的基本流程
- 消息发送阶段：
● 发送方首先发送一个"半消息"（Half Message）到RocketMQ的Broker。此时，这个消息对消费者是不可见的。
● 发送方会收到一个确认，表示半消息已经成功存储。
- 本地事务执行：
● 发送方在收到半消息确认后，开始执行本地事务操作（例如，数据库操作）。
● 本地事务的结果有两种：成功或失败。
- 事务状态提交：
● 如果本地事务成功，发送方提交一个"提交"请求给Broker，Broker将半消息标记为可投递状态，消费者可以消费该消息。
● 如果本地事务失败，发送方提交一个"回滚"请求给Broker，Broker将删除该半消息。
- 事务状态回查：
● 在某些情况下，发送方可能由于网络问题或系统故障未能及时提交事务状态。
● Broker会定期回查发送方以获取事务状态。发送方需要实现一个回查接口，以便Broker询问本地事务的最终状态。
● 根据回查结果，Broker决定是提交还是回滚该消息。
@所有人
五、【每日一问：20250630】说说你的项目RocketMQ如何保证消息不丢失？
RocketMQ通过多层面的机制来确保消息的可靠性，包括生产者端、broker端和消费者端。
- 生产者端保证
a. 同步发送
同步发送是最可靠的发送方式，它会等待broker的确认响应。
b. 异步发送 + 重试机制
异步发送通过回调来处理发送结果，并可以设置重试次数。
2.Broker端保证
a. 同步刷盘，通过配置broker.conf文件，可以启用同步刷盘：
brokerRole = SYNC_MASTER
- 消费者端保证
a. 手动提交消费位移，使用手动提交可以确保消息被正确处理后再提交位移。
b. 幂等性消费，在消费端实现幂等性处理，确保重复消费不会导致业务问题。
通过这些机制的组合，RocketMQ能够在各个环节保证消息的可靠性，极大地降低了消息丢失的风险。在实际应用中，可以根据业务需求选择合适的配置和实现方式，以在可靠性和性能之间取得平衡。@所有人
六、【每日一问：20250701】RocketMQ延迟消息是如何实现的?
【每日一问参考答案：20250701】RocketMQ延迟消息是如何实现的?
RocketMQ通过特定的延迟级别设计实现延迟消息功能。在RocketMQ中，延迟消息是通过设置消息的延迟级别（Delay Level）来实现的。每个延迟级别对应一个特定的时间段，这样可以让消息在指定的时间之后才被消费。
实现原理
-
延迟级别：RocketMQ不支持任意时间的延迟，而是提供了18个固定的延迟级别，从1s，5s，10s，30s，1m，2m，3m到2h不等。
-
特殊主题：所有延迟消息都会先发送到一个特殊的内部主题 SCHEDULE_TOPIC_XXXX。
-
定时任务：Broker会启动一个定时任务，按照延迟时间的先后顺序依次扫描每个延迟级别队列。
-
消息转移：当扫描到期的消息时，会将消息从延迟队列转移到目标主题。
-
消费者消费：消息被转移到目标主题后，消费者就可以正常消费这条消息了。
注意事项
● 延迟级别配置：可以在broker.conf中自定义延迟级别，以满足业务需求。
● 性能影响：延迟消息可能对性能有影响，尤其是在高负载的情况下。
● 精确延迟：RocketMQ的延迟机制不是精确的，延迟时间为近似值。
这种延迟机制非常适合应用于那些需要延迟处理的场景，比如订单超时关闭、优惠券过期提醒等。确保您的业务逻辑满足延迟级别的要求，并合理规划RocketMQ的资源。
七、【每日一问：20250702】请问RocketMQ消息积压一般产生原因是什么？如何解决消息积压问题呢？
【每日一问参考答案：20250702】请问RocketMQ消息积压一般产生原因是什么？如何解决消息积压问题呢？
一般消息出现堆积原因有：
● 消费者消息处理逻辑异常，导致消息无法正常消费。
● 消息生产应用出现突发流量，消息生产速度远大于消费速度，消息来不及消费出现堆积。
● 消费者依赖的下游服务耗时变长，消费线程阻塞等。
● 消费线程不够，消费并发度较小，消费速度跟不上生产速度。
解决方案有：
（1）确认消息的消费耗时是否合理，通过打印堆栈日志信息分析如果是消费耗时较长，可以参考出来解决方案：
- 分析和优化业务逻辑
● 简化逻辑：仔细分析业务逻辑，去除不必要的步骤和复杂计算。
● 分解任务：将复杂的任务分解为多个简单的子任务，逐步处理。
● 异步处理：对于不需要立即完成的任务，考虑使用异步处理，将其放到后台执行。
- 使用并行和并发技术
● 多线程处理：在消费者内部使用多线程来并行处理消息。
● 批量处理：如果业务允许，合并多条消息进行批量处理，减少处理次数。
- 优化I/O操作
● 数据库优化：优化数据库查询，使用索引、减少查询次数或使用批量操作。
● 缓存使用：对于频繁访问的数据，使用缓存来减少数据库或外部服务的访问次数。
● 网络优化：减少网络请求的次数和延迟，使用更高效的协议或配置
（2）如果消费耗时正常，则有可能是因为消费并发度不够导致消息堆积，需要逐步调大消费线程或扩容节点来解决。
（3）设置消息过期时间
在消息发送时设置TTL，消息在队列中超过一定时间后自动过期并被丢弃。这样可以确保系统不会处理过期的消息。这个要看具体的业务场景。
八、【每日一问：20250703】 说说你的项目消息重复如何处理的？@所有人
在处理消息重复的问题时，通常需要确保消息的幂等性，即无论消息被处理多少次，结果都是一致的。关于幂等性解决方案通常如下：
- 业务逻辑层面
● 业务逻辑幂等性：设计业务逻辑时，确保同一消息被多次处理不会导致不一致的结果。例如，更新操作可以使用唯一标识符来确保只更新一次。
- 唯一标识
● 消息ID：为每条消息分配一个唯一的ID，消费者在处理消息时检查该ID是否已处理过。
● 去重存储：使用数据库或缓存（如Redis）存储已处理的消息ID，并在处理新消息前进行检查。
- 事务性操作
● 事务支持：在数据库操作中使用事务，确保操作的原子性和一致性。
● 分布式事务：在分布式系统中，使用分布式事务管理器（如二阶段提交）来确保跨服务的操作一致性。
具体的实现需要根据业务需求和系统架构进行选择。
九、 【每日一问：20250704】 如果要你对生产环境的RocketMQ进行调优，请问你的思路是什么？
答：参考答案：
这个一个综合性问题，RocketMQ在生产环境中的优化是一个多方面的任务，涉及到系统配置、应用代码、监控和运维等多个层面。主要优化思路有：
- 生产者优化
a) 批量发送消息
批量发送可以提高吞吐量，减少网络开销。
b) 异步发送
对于非关键消息，使用异步发送可以提高发送效率。
c) 合理设置发送超时时间
- 消费者优化
a) 增加消费并发度
通过增加消费线程数来提高消费能力。
b) 批量消费
配置批量消费可以减少网络交互，提高效率。
c) 合理设置消费重试次数
- Broker配置优化
需要在broker.conf中配置：
brokerRole = ASYNC_MASTER #主从异步复制消息
flushDiskType = ASYNC_FLUSH #开启异步刷盘
- 合理设置Topic的队列数
小规模系统：对于一般的小型应用，可以从 4 到 8 个队列开始，根据具体的消息负载和性能监控结果再行调整。
中等到大型系统：对于大型系统或高吞吐量需求，默认 16 到 32 个队列 是常见的设置。
- 消费设置长轮询模式
长轮询可以减少无效的轮询请求，在消费者端配置：
- JVM优化
a) 设置合适的堆内存大小
b) 使用G1垃圾收集器
- 消息存储优化
a) 启用文件预热
在broker.conf中开启文件预热配置，将warmMapedFileEnable这个参数设置为 true 时，RocketMQ 会在创建映射文件时对其进行预热。具体的实现方式可能包括写入一些数据以触发操作系统将文件的物理页与虚拟内存页面相关联，可以减少I/O延迟和提高文件读写效率。
- 监控和告警
使用RocketMQ的Dashboard或者其他监控工具（如Prometheus + Grafana）来监控系统状态，并设置适当的告警阈值。
- 消息压缩
对于大消息，可以考虑进行压缩。
这些优化策略涵盖了RocketMQ的多个方面，包括生产者、消费者、Broker配置、网络、JVM、存储等。在实际应用中，需要根据具体的业务场景和硬件环境来选择合适的优化策略。同时，优化是一个持续的过程，需要不断监控、测试和调整，以达到最佳的性能表现。