RocketMQ性能优化：全网最全的一篇

硬件配置

硬件配置是优化 RocketMQ 性能的基础。合理选择和配置硬件资源，可以为 RocketMQ 提供更高的吞吐量和更低的延迟。

CPU

• 选择高性能的多核 CPU：RocketMQ 的 Broker 和 NameServer 是多线程的架构，CPU 的核心数越多，能够同时处理的消息读写操作就越多。因此，建议选择高主频、多核的 CPU（如 8 核或以上）来提升消息处理的并行能力。
• 避免 CPU 过度争用：对于高并发场景下的 Broker，避免将 CPU 资源完全用满，以免导致线程调度和上下文切换开销过大。可以通过 CPU 绑定、隔离策略来优化 CPU 使用。
  

内存

• 充足的内存容量：RocketMQ Broker 主要在内存中缓存消息和索引，内存越大，能够缓存的消息越多，减少磁盘 I/O 频率，提高消息处理性能。建议至少配置 32GB 或以上的内存。
• 使用 ECC 内存：由于 RocketMQ 需要处理大量的消息数据，使用 ECC（Error-Correcting Code）内存可以避免内存错误带来的数据损坏，提高系统的稳定性和可靠性。

磁盘

• 使用高性能的 SSD 磁盘：RocketMQ 的消息存储依赖于磁盘 I/O，建议使用高性能的 SSD 或 NVMe SSD 作为消息存储设备，以减少 I/O 延迟，提升写入和读取性能。
• 合理配置 RAID：对于数据可靠性要求高的场景，可以使用 RAID 10 来兼顾磁盘的性能和可靠性；对于更高的性能需求，可以使用 RAID 0，但需要做好数据备份和容灾。
  

网络

• 高带宽低延迟网络：RocketMQ 集群节点之间的通信和客户端到 Broker 的消息传输都依赖于网络，建议配置 10GbE 或更高带宽的低延迟网络，减少网络传输时延，提高消息传输性能。
• 优化网络配置：调整 TCP 参数（如tcp_nodelay、tcp_keepalive 等）以减少网络延迟和带宽消耗。在 Linux 系统上，可以在 /etc/sysctl.conf 中进行配置，例如：

net.core.somaxconn = 1024
net.ipv4.tcp_max_syn_backlog = 2048

操作系统调优

操作系统的配置对 RocketMQ 的性能有显著影响。通过合理的操作系统调优，可以更好地发挥硬件性能，提升 RocketMQ 的消息处理能力。

内存与交换优化

• 锁定 RocketMQ 进程内存：防止操作系统将 RocketMQ 的内存数据交换到磁盘，避免由于频繁的内存交换导致性能下降。在 /etc/security/limits.conf 中设置：

* soft memlock unlimited
* hard memlock unlimited

• 禁用交换（swap）：RocketMQ 对内存的依赖性很强，应该尽量避免使用 swap 交换分区。在 /etc/sysctl.conf 中设置：

vm.swappiness = 0

设置后，运行 sysctl -p 使配置生效。

文件系统与磁盘 I/O 优化

• 选择合适的文件系统：推荐使用 xfs 或 ext4 文件系统。xfs 在大文件写入和高并发写入场景下性能表现较好，适合 RocketMQ 的消息存储场景。
• 调整文件描述符限制：RocketMQ Broker 需要打开大量文件来进行数据操作，增大文件描述符限制能避免 Too many open files 错误。编辑 /etc/security/limits.conf：

* soft nofile 65536
* hard nofile 65536

• 优化磁盘 I/O 调度算法：在磁盘 I/O 密集型应用中，可以使用 deadline 或 noop 调度算法来减少磁盘延迟，提高 I/O 性能。可以通过 echo deadline > /sys/block/sdX/queue/scheduler 命令进行配置。

网络参数调优

• 增加 TCP 参数：调整 TCP 相关参数，减少延迟，优化网络传输性能。例如：

net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 300

RocketMQ 配置优化

Broker 配置优化

• 调整文件存储配置：RocketMQ 默认使用 MappedFile 来管理消息存储文件。为了优化磁盘 I/O，可以调整以下配置参数：
  • flushDiskType：设置为 ASYNC_FLUSH 可以提高写入性能，但会增加数据丢失的风险。适合对数据可靠性要求不高的场景。
  • storePathRootDir 和 storePathCommitLog：将 CommitLog 和 ConsumeQueue 分别存储在不同的磁盘上，减少磁盘 I/O 争用，提高读写性能。
  • mappedFileSizeCommitLog：根据磁盘性能和数据量调整 CommitLog 文件大小。较大的文件大小可以减少文件切换频率，提升写入性能。
• 调整线程池大小：RocketMQ 的 Broker 使用多个线程池处理客户端请求和内部任务。根据硬件资源和业务负载，合理调整线程池大小，避免线程过多导致的 CPU 争用和上下文切换开销。
• 优化消息写入与刷盘策略：根据业务场景，合理设置消息写入的刷盘策略（同步刷盘 SYNC_FLUSH 或异步刷盘 ASYNC_FLUSH），平衡数据可靠性和写入性能。
  

NameServer 配置优化

• 优化 NameServer 的高可用性：NameServer 是 RocketMQ 集群的路由中心，负责 Broker 和客户端的注册和路由信息的管理。为了提高 NameServer 的可用性，可以部署多个 NameServer 实例，分布在不同的物理节点上，确保在单点故障时系统仍然可用。
• 合理配置 NameServer 的心跳和路由更新频率：根据集群规模和网络环境，合理配置 NameServer 的心跳和路由更新频率，避免频繁的网络请求和资源消耗。可以调整以下参数：

brokerHeartbeatInterval=10000  # 心跳间隔，单位为毫秒
brokerTimeout=30000           # Broker 超时时间，单位为毫秒

客户端配置优化

• 调整客户端重试策略：根据业务需求和网络环境，合理设置客户端的消息发送重试次数和间隔，避免过多的重试请求影响 Broker 性能。可以通过以下参数进行配置：

producer.setRetryTimesWhenSendFailed(3);  // 设置发送失败时的重试次数
producer.setRetryAnotherBrokerWhenNotStoreOK(true);  // 发送失败时尝试其他 Broker

• 使用异步发送模式：在不需要强一致性的场景中，使用异步发送模式可以提高消息发送的吞吐量和性能。可以使用异步发送 API 进行消息发送：

producer.send(message, new SendCallback() {
    @Override
    public void onSuccess(SendResult sendResult) {
        // 处理发送成功的逻辑
    }

    @Override
    public void onException(Throwable e) {
        // 处理发送失败的逻辑
    }
});

JVM调优

jvm脚本要进行调优

消息存储设计优化

RocketMQ 的消息存储设计对其性能有直接影响。通过优化消息存储策略和数据结构设计，可以提升消息存储和检索的效率。

合理规划 CommitLog 和 ConsumeQueue

• 分离 CommitLog 和 ConsumeQueue：为了减少磁盘 I/O 争用，提高读写性能，可以将 CommitLog 和 ConsumeQueue 文件分别存储在不同的物理磁盘或 SSD 上。CommitLog 主要用于存储消息数据，而 ConsumeQueue 是消息索引文件，将这两者分离存储可以最大限度地减少磁盘 I/O 的冲突，提升系统性能。
  

优化 CommitLog 文件大小

• 设置合适的 CommitLog 文件大小：CommitLog 文件的大小直接影响文件切换的频率。文件太小，会导致频繁的文件切换，增加 I/O 操作；文件太大，则可能导致单次 I/O 操作时间过长。通常可以根据磁盘的 I/O 性能和消息写入的速率，调整 mappedFileSizeCommitLog 的大小（例如设置为 1GB 或 2GB）。较大的 CommitLog 文件可以减少文件切换的频率，提升写入性能。
  

调整刷盘策略

• 选择合适的刷盘策略：RocketMQ 支持同步刷盘（SYNC_FLUSH）和异步刷盘（ASYNC_FLUSH）两种模式。同步刷盘会在每次写入后将数据同步到磁盘，数据可靠性高，但写入性能较低；异步刷盘则是将数据写入内存缓冲区中，并在一定条件下批量刷盘到磁盘，写入性能较高但有数据丢失的风险。根据业务对数据可靠性和性能的不同需求，可以选择不同的刷盘策略。
  

合理设置数据保留策略

• 调整消息保留时间：根据业务需求，合理设置消息在 Broker 上的保留时间，避免无效消息占用磁盘空间。可以通过调整 fileReservedTime 参数来配置消息的保留时间（单位为小时）。减少消息的保留时间，可以有效减少磁盘使用，释放 I/O 资源。
• 启用文件删除保护：在删除过期文件时，可以启用文件删除保护机制，确保在删除文件前有足够的磁盘空间缓存，防止数据丢失。可以在 broker.conf 中设置：

deleteWhen=04  # 删除过期文件的时间点（每天凌晨 4 点）
fileReservedTime=72  # 文件保留时间（单位：小时）

压缩消息体

• 使用消息压缩：对于一些场景中，消息体较大且重复率较高的情况下，可以在应用层对消息体进行压缩（如使用 Gzip、Snappy 等压缩算法），然后存储在 RocketMQ 中。虽然 RocketMQ 不直接支持消息体压缩，但是通过应用层的压缩，可以有效减少消息体占用的空间，提升存储效率
  

Schema设计与优化

RocketMQ 概念	类比的 MySQL 概念	解释
Topic	Table（表）	存储特定类型消息的集合，类似于表存储特定类型数据
Message	Row（行/记录）	每条消息就像表中的一条记录
Message Properties	Column（字段）	消息的属性（如 Tag、Keys 等）类似于表中的字段
Tag	Column Value（字段值）	消息属性的具体值，类似于表字段的具体数据

topic设计优化

message设计优化

写入优化

RocketMQ 的写入和消费性能直接影响系统的整体吞吐量和响应时间。通过优化写入和消费策略，可以进一步提升 RocketMQ 的性能。

• 使用批量发送：RocketMQ 支持批量发送消息，可以通过批量将多条消息合并为一个请求，减少网络往返次数和服务器的处理开销。可以使用批量发送 API：

List<Message> messages = new ArrayList<>();
// 添加消息到列表中
producer.send(messages);

• 使用异步发送：在对消息时效性要求不高的场景中，可以使用异步发送模式，提高吞吐量。异步发送模式下，消息发送和结果处理是并行的，可以减少消息发送的延迟和阻塞
  

消费优化

• 增加消费线程数：消费端通过线程池来处理消息，合理增加消费线程数可以提高并发消费能力。在 Consumer 配置中调整 consumeThreadMin 和 consumeThreadMax 参数。例如：

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("ConsumerGroup");
consumer.setConsumeThreadMin(20);
consumer.setConsumeThreadMax(64);

• 使用批量消费：通过设置 consumeMessageBatchMaxSize 和 pullBatchSize 参数，启用批量消费模式，一次性拉取和处理多条消息，减少消费请求次数，降低网络开销，提升消费吞吐量。例如：

consumer.setConsumeMessageBatchMaxSize(32);  // 一次批量消费32条消息
consumer.setPullBatchSize(64);  // 一次性拉取64条消息

• 减少消费逻辑复杂度：在消费端，减少每条消息的处理逻辑复杂度，避免阻塞操作和长时间的计算任务。可以将耗时操作（如数据库访问、网络调用等）异步化或放到后台任务中处理。
• 异步消费：在处理不需要严格消息顺序的场景下，可以使用异步消费模型，将消息处理逻辑放入异步线程中，快速返回消费结果，减少消费线程的阻塞时间。
• 调整消费超时时间：RocketMQ 允许设置消费超时时间，如果消费超时，消息会被重新消费。合理设置 consumeTimeout 参数，避免因为超时导致的消息重复消费和消费延迟。默认的消费超时时间为 15 分钟，可以根据实际业务场景进行调整：

consumer.setConsumeTimeout(10);  // 设置消费超时时间为10分钟

监控与调优

持续的监控与调优是确保 RocketMQ 系统高性能运行的关键。通过监控 RocketMQ 的性能指标和运行状态，可以及时发现问题并进行优化调整。

性能监控

• 使用 RocketMQ Console 监控：RocketMQ 提供了一个 Web 控制台（RocketMQ Console）用于监控集群的运行状态，包括 Broker、NameServer、Topic、Consumer Group 等信息。可以通过 RocketMQ Console 监控系统的运行情况，及时发现和处理问题。
• 集成第三方监控工具：可以将 RocketMQ 的性能指标集成到 Prometheus、Grafana 等第三方监控工具中，进行更详细的监控和报警。
  

日志分析

• 启用慢查询日志：在 RocketMQ 配置中启用慢查询日志，记录处理时间较长的消息操作，分析日志内容，找出性能瓶颈和优化方向。
• 分析 Broker 和 Consumer 的日志：定期分析 Broker 和 Consumer 的日志文件，检查是否存在异常和错误信息，及时优化系统配置和业务逻辑。
  

参数调优

• 根据负载调整参数：根据 RocketMQ 的负载情况和业务需求，动态调整 RocketMQ 的参数配置，如线程池大小、队列长度、刷盘策略等，优化系统性能。
• 优化 JVM 参数：根据 RocketMQ 的内存使用和 GC 情况，合理配置 JVM 参数，减少垃圾回收对系统性能的影响。

大家在Rocketmq实例优化和schema设计优化有什么想法，欢迎评论🙏