MessageDecoder 类中的下面这段代码：

public static String messageProperties2String(Map<String, String> properties) {
     StringBuilder sb = new StringBuilder();
     if (properties != null) {
         for (final Map.Entry<String, String> entry : properties.entrySet()) {
             final String name = entry.getKey();
             final String value = entry.getValue();
             if (value == null) {
                 continue;
             }
             sb.append(name);
             sb.append(NAME_VALUE_SEPARATOR);
             sb.append(value);
             sb.append(PROPERTY_SEPARATOR);
         }
     }
     return sb.toString();
 }

如果是业务代码，这里看起来似乎没有什么问题。但在 TPS 很高的场景下， StringBuilder 默认长度是 16，处理一个正常的消息，至少会内部扩展 2 次，白白产生 2 个对象和 2 次数组复制。所以优化方案就是先算好需要的长度，创建 StringBuffer 的时候直接就指定好。

这个类中的 string2messageProperties 也进行了优化，用自己的解析代替了 split 调用。通过 jmh 进行一下测试，结果如下：

可以看出有了很大的提高。

关于消息属性，之前的程序还有一个问题是把一些不需要的属性也写到了 CommitLog 里面（或者也可以说是把不相关的东西放到了消息属性里面）。比如 wait=true 这个属性，实际上是在消息处理过程中才用的，不需要持久化，所以这次就想办法把它从 CommitLog 中删掉了。遗憾的是没有一个统一的地方可以一劳永逸的删掉这个属性，本次只针对普通消息进行了删除。删掉这个属性，每个消息的存储占用会减少 10 个字节，对于小消息来说，还是挺可观的。

RocketMQ 的通信协议定义了各种指令，它们的 Header 各不相同，共用了一个通用的解析方法，基于反射来解析和设置消息 Header。

这里简单的针对消息生产的指令，不再使用共同的这个解析器，而是简单粗暴的直接一个一个去 set 每一个属性，这样这个方法获得了大约 4 倍性能的提升。

现在，我们针对本次优化的成果，进行一次分布式的性能测试。

我们使用 2 台物理机部署为 Master/Slaver 模式，同步复制，异步刷盘，其它参数均用默认，分区数设置为 18。然后用另外 6 台服务器作为 client 同时生产和消费，每个生产者启动 100 个线程同步发送，消息体约 300 字节。

服务器硬件配置为 2*Xeon(R) Gold 5218，一共 32 核心 64 线程，128G 内存，Nvme SSD，client 和 server 的 ping 延迟是 0.06ms。

我们还派出了一个神秘的参赛选手，最终待测试的版本包括以下 4 个：
A、4.9.0 版本，使用默认参数。B、4.9.0 版本，按上面的修改 D 进行参数优化。C、4.9.1 版本，默认参数。D、快手内部某版本。

结果如下：

即使按进行过参数优化的 4.9.0 版本作为基线，4.9.1 版本也胜出了 28%，快手内部版本则胜出了 40%。

需要说明的是：
1、由于 OS 虚拟内存管理是个很复杂的机制，写 mmap 的 Byte Buffer 的速度也会存在抖动，所以测试的结果也存在波动。2、内核参数会对OS的内存性能有很大影响，不同硬件、内核可能会有不同的表现，RocketMQ/bin 目录下的 os.sh 可以作为一个内核参数调整的参考。3、Nvme SSD 不会是性能瓶颈所在，通过在一个物理机上安装多个 Broker（改一下端口号和文件存储路径），可以进一步提升 TPS，比如在本次测试的场景下，还是这两台物理机，4.9.1 版本每个物理机上 4 个 Broker 混布可以把总 TPS 提升到 60 多万。4、压测的时候 RocketMQ 自身的 benchmark 程序自己也会存在瓶颈，需要多实例运行得出 Broker 的性能，本次测试没有使用使用这个程序。

性能优化是个长期工作，本批次的优化主要集中在 Broker 的消息生产链路。其他地方也有很多可以优化的点，包括：

• 消费链路
• Client 的对象创建、数据复制、线程切换等
• 网络通信和序列化
• benchmark 程序

即便是生产链路也还有很多可以继续优化的地方，我们会继续推进这个工作，也欢迎大家一起来贡献。

作者介绍：
（1）黄理，当前就职于快手，架构师，Apache RocketMQ Commiter，多年 Java 架构和开发经验，个人技术爱好是性能优化方向。（2）胡宗棠，当前就职于中国移动云能力中心，云原生领域技术专家，Apache RocketMQ Committer，SOFAJRaft Committer，Alibaba/Nacos Committer，熟悉分布式消息队列、API 网关和分布式事务等中间件设计原理、架构以及各种应用场景，具有丰富高性能、高可用和高并发经验；