RockerMQ中有人遇到这种情况吗？

是的，RocketMQ的Broker有可能导致CPU持续100%和磁盘读写很高的情况。以下是一些可能的原因和解决方法：

1. 资源竞争和线程堆积：如果生产者在发送消息时没有使用单例模式，可能会创建大量的MQ客户端连接，而这些连接在使用完毕后没有被正确关闭，导致系统资源（如线程）持续堆积，从而引起CPU和内存的飙升。解决这个问题通常需要确保生产者客户端使用单例模式，并且在不需要时及时关闭连接。
2. 日志配置问题：如果RocketMQ客户端的日志配置不当或未生效，可能会导致日志文件异常增大，从而引起磁盘空间不足和读写性能下降的问题。确保自定义日志配置正确并生效，可以有效控制日志文件的大小和数量，避免对磁盘造成过大压力。
3. 操作系统层面的调优：由于RocketMQ的Broker大量使用了mmap技术来实现CommitLog的高性能读写，因此操作系统层面的缓存策略和磁盘性能也会对Broker的性能产生重要影响。合理配置操作系统的缓存大小和磁盘I/O调度策略，可以提高数据写入性能，减少对CPU的占用。
4. NameServer的压力：RocketMQ的架构中，每个Broker都需要向NameServer注册自己的信息。如果NameServer承受的压力过大或者出现故障，也可能间接影响到Broker的正常工作。
5. 网络问题：网络延迟或不稳定也可能导致Broker处理请求的效率降低，从而增加CPU的负担。

总的来说，解决这类问题通常需要综合监控系统资源使用情况、日志文件大小、网络状况以及RocketMQ的配置和架构设计。通过逐一排查和调优，可以找到导致性能问题的根源，并采取相应措施进行解决。

出现这种现象可能是因为：

• 某些队列存在大量堆积的消息，即使没有消费者消费，Broker在进行日志清理、索引构建等工作时也会消耗大量CPU和磁盘资源。
• 此时间段内有其他后台任务（如定时统计、归档备份等）在运行，造成资源紧张。
• 存在某些隐含的异常消费行为，例如消费者短暂上线并拉取消息但未完成消费，Broker为维持长轮询会保持高负载。
• 系统层面的性能瓶颈，如GC频繁、操作系统调度不合理等。