RocketMQ 迈入万TPS消息俱乐部.docxVIP

RocketMQ 迈入50万TPS消息俱乐部 消息团队一直努力于RocketMQ的功能优化，双十一前进行了低延时（毛刺）优化，保障了双十一万亿消息的流转如丝般顺滑，在2021年双十一种，MetaQ以接近万亿的消息总量支撑着全集团数千个应用，在系统解耦、削峰填谷、数据库同步、位点回滚消费等多种业务场景中，MetaQ都有精彩、稳定的表现。高可用低延迟，高并发抗积累，2021双11的MetaQ真正做到了如丝般顺滑。 而最近通过对功能的持续优化，在RocketMQ最新的中小消息TPS已达47万，本人在F43机型上自测时TPS峰值为57万TPS，所以取了这么一个标题。 RocketMQ高功能优化探究 本章节简约引见下在优化RocketMQ过程中用到的方法和技巧。部分方法在消息领域提升不明显却带来了编码和运维的简单度，这类方法虽然最终没有利用起来，也在下面做了引见供大家参考。 Java篇 在接触到内核层面的功能优化之前，Java层面的优化需要先做起来。有时候灵机一动的优化方法需要实现Java程序来进行测试，留意测试的时候需要在排解其他干扰的同时充分利用JVM的预热(JIT)特性。推举使OpenJDK开发的基准测试(Benchmark)工具JMH。 JVM停顿 影响Java应用功能的头号大敌便是JVM停顿，说起停顿，大家耳熟能详的便是GC阶段的STW(Stop the World)，除了GC，还有很多其他缘由，如下图所示。 当怀疑我们的Java应用受停顿影响较大时，首先需要找出停顿的类型，下面一组JVM参数可以输出具体的平安点信息： -XX:+LogVMOutput -XX:LogFile=/dev/shm/vm.log -XX:+PrintGCApplicationStoppedTime -XX:+PrintSafepointStatistics -XX:PrintSafepointStatisticsCount=1 -XX:+PrintGCApplicationConcurrentTime 在RocketMQ的功能测试中，发觉存在大量的RevokeBias停顿，偏向锁次要是衰退无竞争情况下的同步原语以提高功能，但考虑到RocketMQ中该场景比较少，便通过-XX:-UseBiasedLocking关闭了偏向锁特性。 停顿有时候会让我们的StopWatch变得很不精确，有一段时间经常被StopWatch误导，观看到一段代码耗时特别，结果花时间去优化也没效果，其实不是这段代码耗时，只是在执行这段代码时发生了停顿。停顿和动态编译往往是功能测试的两大圈套。 GC GC将Java程序员从内存管理中解救了出来，但也对开发低延时的Java应用带来了更多的挑战。对GC的优化个人认为是一项调整参数的工作，垃圾收集方面最值得关注的两共功能属性为吞吐量和延迟，对GC进行优化往往是寻求吞吐量和延迟上的折衷，没方法鱼和熊掌兼得。 RocketMQ通过GC调优后最终实行的GC参数如下所示，供大家参考。 -server -Xms8g -Xmx8g -Xmn4g -XX:+UseG1GC -XX:G1HeapRegionSize=16m -XX:G1ReservePercent=25 -XX:InitiatingHeapOccupancyPercent=30 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:SurvivorRatio=8 -XX:+DisableExplicitGC -verbose:gc -Xloggc:/dev/shm/mq_gc_%p.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:+PrintAdaptiveSizePolicy -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=30m 可以看出，我们最终全部切换到了G1，16年双十一线上MetaQ集群接受的也是这一组参数，基本上GC时间能把握在20ms以内（一些超大的共享集群除外）。 对于G1，官方推举使用该-XX:MaxGCPauseMillis设置目标暂停时间，不要手动指定-Xmn和-XX:NewRatio，但我们在实测中发觉，假如指定过小的目标停连忙间(10ms)，G1会将重生代调整为很小，导致YGC愈加频繁，老年月用得更快，全部还是手动指定了-Xmn为4g，在GC频率不高的情况下完成了10ms的目标停连忙间，这里也说明有时候一些通用的调优阅历并不适用于全部的产品场景，需要更多的测试才能找到最合适的调优方法，往往需要另辟蹊径。 同时也共享下我们在使用CMS