您现在的位置是:首页 > 文章详情

Apache RocketMQ 4.9.1 高性能优化之路

日期:2021-10-13点击:312
经过社区的投票,Apache RocketMQ 秋天的第一个版本 4.9.1 如约而至,该版本中最值得关注的是高性能优化这块,针对 Broker 端的性能,特别是对小消息的生产性能进行了针对性优化,和 4.9.0 版本相比, 小消息实时生产的 TPS 提升了约 28%。


这一批优化相关的 Pull Request(PR)都挂在  ISSUE2883  下,分为 7 个 PR(A-G),接下来我们来看一下这一批优化的细节,大家也可以到 github 查看代码明细。

A、针对事务消息的优化


在当前的版本中,事务消息已经较为成熟,但压测的时候就会发现,默认的配置下每条消息都会打出一条日志:

log.info("Half offset {} has been committed/rolled back", i);

这肯定会影响性能,压测等大流量场景下甚至会导致灾难性影响。所以这个优化最简单,把这个日志改成 debug 就可以了。

B、消除不必要的锁


在 RocketMQ 内部,主从复制和同步刷盘都是多线程协作处理的。以主从复制为例(GroupTransferService),消息处理线程(多个)不断接收消息,产生待复制的消息,另外有一个 ServiceThread 单线程处理复制结果,可以把前者看做数据生产者,后者看做数据消费者,RocketMQ 使用了双 Buffer 来达到批量处理的目的。如下图,消费者正在处理数据的同时,生产者可以不受影响的继续添加数据,第一阶段生产者 Buffer 有 3 条数据,消费者 Buffer 有 2 条数据,由于消费者是单线程,没有别的线程跟它竞争,所以它可以批量处理这 2 条数据,完成后它会交换这两个 Buffer 的引用,于是接下来的第二阶段它又可以批量处理 3 条数据。


之前 RocketMQ 在生产者写入、交换 Buffer 引用、以及内部处理中都使用了多个重量级锁保证线程安全。但实际上只需要在生产线程写入以及交换 Buffer 引用的时候加轻量级自旋锁就可以,由于这两个操作都是非常快的,因此可以认为每次加解锁都只有 2 次 CAS 操作的开销。


除此之外,WaitNotifyObject 类也进行了优化,减少了需要进入同步代码块的次数。


C、消除主从复制中的数组拷贝


RocketMQ 使用 mmap 来方法 CommitLog 文件,其中有一个好处就是 io 操作的时候少了一个内存拷贝。但实际上由于工程的复杂性,代码中仍然会存在各种各样的内存拷贝,我们优化的目标就是消除那些本来可以避免的复制。

这一次我们就在主从复制这里找到了一个优化点,有一个 ByteBuffer,要把其中一部分写到 CommitLog 里面去,原来的代码会创建一个 byte [],然后复制一遍,其实只需要传入 ByteBuffer.array() 给后续方法,然后指明要复制的起止位置就可以了。这样优化后我们还节省了这个 byte[] 的创建,原先复制 1G 的 CommitLog 就会有至少 1G 的 byte[] 对象的分配和 gc 开销,这下也省了。这次修改的部分实际上运行在 Slave 中,但在同步复制的场景下,对消息发送的响应时间还是有影响的。


D、优化 Broker 的默认参数


从 RocketMQ4.X 开始引入了自旋锁并作为默认值,同时将参数 sendMessageThreadPoolNums(出现消息生产的线程数)改为了 1,这样处理每条消息写 CommitLog 的时候可以省下进出重量锁的开销。

不过这个地方单线程处理,任务有点重,处理消息的逻辑并不是往 CommitLog 里面一写(无法并行)就完事的,还有一些 CPU 开销比较大的工作,多线程处理比较好,经过一些实践测试,4 个线程是比较合理的数值,因此这个参数默认值改为 MIN(逻辑处理器数, 4)。


既然有 4 个线程,还用自旋锁可能就不合适了,因为拿不到锁的线程会让 CPU 白白空转。所以 useReentrantLockWhenPutMessage 参数还是改为 true 比较好。


还有个细节,endTransactionThreadPoolNums 这个参数默认设置成了 sendMessageThreadPoolNums 的至少 4 倍,以避免事务消息量特别大的场景下(比如事务消息压测),二阶段处理速度赶不上一阶段处理速度,进而导致严重的问题。


此外,对刷盘相关的参数也进行了调整。默认情况下,RocketMQ 是异步刷盘,但每次处理消息都会触发一个异步的刷盘请求。这次将 flushCommitLogTimed 这个参数改成 true,也就是定时刷盘(默认每 500ms),可以大幅降低对 IO 压力,在主从同步复制的场景下,可靠性也不会降低。


E、优化 put message 锁内操作


写 CommitLog 只能单线程操作,写之前要先获取一个锁,这个锁也就是影响 RocketMQ 性能最关键的一个锁。理论上这里只要往 MappedByteBuffer 写一下就好了,但实践往往要比理论复杂得多,因为各种原因,这个锁里面干的事情非常的多。


由于当前代码的复杂性,这个优化是本批次修改里面改动最大的,但它的逻辑其实很简单,就是把锁内干的事情,尽量的放到锁的外面去做,能先准备好的数据就先准备好。它包括了一下改动:

1、将 Buffer 的大部分准备工作(编码工作)放到了锁外,提前做好。
2、将 MessageId 的做成了懒初始化(放到锁外),这个消息 ID 的生成涉及很多编解码和数据复制工作,实际上性能开销相当大。
3、原来锁内用来查位点哈希表的 Key 是个拼接出来的字符串,这次也改到锁外先生成好。
4、顺便补上了之前遗漏的关于 IPv6 的处理。
5、删除了无用的代码。

F、优化消息属性编解码的性能


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 个字节,对于小消息来说,还是挺可观的。


G、优化消息 Header 解析的性能


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 网关和分布式事务等中间件设计原理、架构以及各种应用场景,具有丰富高性能、高可用和高并发经验;

加入 Apache RocketMQ 社区


十年铸剑,Apache RocketMQ 的成长离不开全球接近 500 位开发者的积极参与贡献,相信在下个版本你就是 Apache RocketMQ 的贡献者,在社区不仅可以结识社区大牛,提升技术水平,也可以提升个人影响力,促进自身成长。

社区 5.0 版本正在进行着如火如荼的开发,另外还有接近 30 个 SIG(兴趣小组)等你加入,添加社区开发者微信:rocketmq666 即可进群,参与贡献,打造下一代消息、事件、流超融合处理平台。

另外还可以加入钉钉群与rocketmq 爱好者一起广泛讨论:


本文分享自微信公众号 - RocketMQ官微(ApacheRocketMQ)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

原文链接:https://my.oschina.net/apacherocketmq/blog/5281480
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章