性能文章>RocketMQ这样做,压测后性能提高30%>

RocketMQ这样做,压测后性能提高30%原创

6月前
320329
从官方这边获悉,RocketMQ在4.9.1版本中对消息发送进行了大量的优化,性能提升十分显著,接下来请跟着我一起来欣赏大神们的杰作。

根据RocketMQ4.9.1的更新日志,我们从中提取到关于消息发送性能优化的【Issues:2883】,详细链接如下:具体优化点如截图所示:

首先先尝试对上述优化点做一个简单的介绍:

  • 对WaitNotifyObject的锁进行优化(item2)
  • 移除HAService中的锁(item3)
  • 移除GroupCommitService中的锁(item4)
  • 消除HA中不必要的数组拷贝(item5)
  • 调整消息发送几个参数的默认值(item7)
    • sendMessageThreadPoolNums
    • useReentrantLockWhenPutMessage
    • flushCommitLogTimed
    • endTransactionThreadPoolNums
  • 减少琐的作用范围(item8-12)

通过阅读上述的变更,总结出优化手段主要包括如下三点:

  • 移除不必要的锁
  • 降低锁粒度(范围)
  • 修改消息发送相关参数

接下来结合源码,从中挑选具有代表性功能进行详细剖析,一起领悟Java高并发编程的魅力。

1、移除不必要的锁

本次性能优化,主要针对的是RocketMQ同步复制场景。

我们首先先来简单介绍一下RocketMQ主从同步在编程方面的技巧。

RocketMQ主节点将消息写入内存后, 如果采用同步复制,需要等待从节点成功写入后才能向消息发送客户端返回成功,在代码编写方面也极具技巧性,时许图如下图所示:

温馨提示:在RocketMQ4.7版本开始对消息发送进行了优化,同步消息发送模型引入了jdk的CompletableFuture实现消息的异步发送。

核心步骤解读:

  1. 消息发送线程调用Commitlog的aysncPutMessage方法写入消息。
  2. Commitlog调用submitReplicaRequest方法,将任务提交到GroupTransferService中,并获取一个Future,实现异步编程。值得注意的是这里需要等待,待数据成功写入从节点(内部基于CompletableFuture机制的内部线程池ForkJoin)。
  3. GroupTransferService中对提交的任务依次进行判断,判断对应的请求是否已同步到从节点。
  4. 如果已经复制到从节点,则通过Future唤醒,并将结果返回给消息发送端。

GroupTransferService代码如下图所示:

为了更加方便大家理解接下来的优化点,首先再总结提炼一下GroupTransferService的设计理念:

  • 首先引入两个List结合,分别命名为读、写链表。
  • 外部调用GroupTransferService的putRequest请求,将存储在写链表中(requestWrite)。
  • GroupTransferService的run方法从requestRead链表中获取任务,判断这些任务对应的请求的数据是否成功写入到从节点。
  • 每当requestRead中没有数据可读时,两个队列进行交互, 从而实现读写分离,降低锁竞争

新版本的优化点主要包括:

  • 更改putRequest的锁类型,用自旋锁替换synchronized
  • 去除doWaitTransfer方法中多余的锁

1.1 使用自旋锁替换synchronized

正入下图所示,GroupTransferService向外提供接口putRequest,用来接受外部的同步任务,需要对ArrayList加锁进行保护,往ArrayList中添加数据属于一个内存操作,操作耗时小。

故这里没必要采取synchronized这种synchronized,而是可以自旋锁,自旋锁的实现非常轻量级,其实现如下图所示:

整个锁的实现就只需引入一个AtomicBoolean,加锁、释放锁都是基于CAS操作,非常的轻量,并且自旋锁不会发生线程切换

1.2 去除多余的锁

“锁”的滥用是一个非常普遍的现象,多线程环境编程是一个非常复杂的交互过程,在编写代码过程中我们可能觉得自己无法预知这段代码是否会被多个线程并发执行,为了谨慎起见,就直接简单粗暴的对其进行加锁,带来的自然是性能的损耗,这里将该锁去除,我们就要结合该类的调用链条,判断是否需要加锁。

整个GroupTransferService中在多线程环境中运行需要被保护的主要是requestRead与requestWrite集合,引入的锁的目的也是确保这两个集合在多线程环境下安全访问,故我们首先应该梳理一下GroupTransferService的核心方法的运作流程:

doWaitTransfer方法操作的主要对象是requestRead链表,而且该方法只会被GroupTransferService线程调用,并且requestRead中方法会在swapRequest中被修改,但这两个方法是串行执行,而且在同一个线程中,故无需引入锁,该锁可以移除。

但由于该锁被移除,在swapRequests中进行加锁,因为requestWrite这个队列会被多个线程访问,优化后的代码如下:

从这个角度来看,其实主要是将锁的类型由synchronized替换为更加轻量的自旋锁。

2、降低锁的范围

被锁包裹的代码块是串行执行,即无法并发,在无法避免锁的情况下,降低锁的代码块,能有效提高并发度,图解如下:

如果多个线程区访问lock1,lock2,在lock1中domSomeThing1、domSomeThing2这两个方法都必须串行执行,而多个线程同时访问lock2方法,doSomeThing1能被多个线程同时执行,只有doSomething2时才需要串行执行,其整体并发效果肯定是lock2,基于这样理论:得出一个锁使用的最佳实践:被锁包裹的代码块越少越好

在老版本中,消息写入加锁的代码块比较大,一些可以并发执行的动作也被锁包裹,例如生成offsetMsgId。

新版本采用函数式编程的思路,只是定义来获取msgId的方法,在进行消息写入时并不会执行,降低锁的粒度,使得offsetMsgId的生成并行化,其编程手段之巧妙,值得我们学习。

3、调整消息发送相关的参数

  1. sendMessageThreadPoolNums

    Broker端消息发送端线程池数量,该值在4.9.0版本之前默认为1,新版本调整为操作系统的CPU核数,并且不小于4。

  2. useReentrantLockWhenPutMessage MQ消息写入时对内存加锁使用的锁类型,低版本之前默认为false,表示默认使用自旋锁;新版本使用ReentrantLock。自旋主要的优势是没有线程切换成本,但自旋容易造成CPU的浪费,内存写入大部分情况下是很快,但RocketMQ比较依赖页缓存,如果出现也缓存抖动,带来的CPU浪费是非常不值得,在sendMessageThreadPoolNums设置超过1之后,锁的类型使用ReentrantLock更加稳定。

  3. flushCommitLogTimed 首先我们通过观察源码了解一下该参数的含义:

    其主要作用是控制刷盘线程阻塞等待的方式,低版本flushCommitLogTimed为false,默认使用CountDownLatch,而高版本则直接使用Thread.sleep。猜想的原因是刷盘线程比较独立,无需与其他线程进行直接的交互协作,故无需使用CountDownLatch这种专门用来线程协作的“外来和尚”。

  4. endTransactionThreadPoolNums

    主要用于设置事务消息线程池的大小。新版本主要是可通过调整发送线程池来动态调节事务消息的值,这个大家可以根据压测结果动态调整。

最后说一句(求关注,别白嫖我)

如果这篇文章对您有所帮助,或者有所启发的话,帮忙扫描下发二维码关注一下,您的支持是我坚持写作最大的动力。

本文首发「中间件兴趣圈」公众号。

分类:标签:
请先登录,查看2条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

从Linux源码看Socket(TCP)的bind
前言之前笔者分享了关于Client端的Socket在进行Connect的时候到底做了哪些事情~今天笔者就来继续从Linux源码的角度看下Server端的Socket在进行bind的时候到底做了哪些事情
RocketMQ 在使用上的一些排坑和优化
前言:RocketMQ 在我们的项目中使用非常广泛,在使用的过程中,也遇到了很多的问题。比如没有多环境的隔离,在多个版本同时开发送测的情况下,互相干扰严重。RocketMQ 的投递可能会失败,导致丢失
给 wireshark 写一个 RocketMQ 协议解析的 lua 插件
前言学习 RocketMQ,需要搞懂两个东西:通信和存储。这里花了一点时间写了一个 RocketMQ 的 wireshark lua 插件,过程挺有意思,写出来记录一下。通过阅读这篇文章,你会了解到下
性能调优必备利器之 JMH
if 快还是 switch 快?HashMap 的初始化 size 要不要指定,指定之后性能可以提高多少?各种序列化方法哪个耗时更短?无论出自何种原因需要进行性能评估,量化指标总是必要的。在大部分场合
Rocketmq发送时异常system busy,start flow control for a while;broker busy start flow control for a while;
本文正在参加「Java应用线上问题排查经验/工具分享」活动先点赞再看,养成好习惯背景全国最大的短信平台,大家都用过我们的产品。数据量比较大,最多时候一天近7亿条短信。我们项目从RocketMQ3.2.
一次 RocketMQ 顺序消费延迟的问题定位
问题背景与现象昨晚收到了应用报警,发现线上某个业务消费消息延迟了 54s 多(从消息发送到MQ 到被消费的间隔):```2021-06-30T23:12:46.756 message processi
《吃透 MQ 系列》之 Kafka 存储选型的奥秘
谈到 Kafka 的存储设计,了解不多的同学,可能会有这样的疑惑:为什么 Kafka 会采用 Logging(日志文件)这种很原始的方式来存储消息,而没考虑用数据库或者 KV 来做存储?
《吃透 MQ 系列》之核心基础篇
上一篇文章谈到了《吃透系列》的讲解思路:先找到每个技术栈最本质的东西,然后以此为出发点,逐渐延伸出其他核心知识。所以,整个系列侧重于思考力的训练,不仅仅是讲清楚 What,而是更关注 Why 和 How,以帮助大家构建出牢固的知识体系。回到正文,这是技术系列《吃透 MQ》的开篇。