RocketMQ on openEuler，是一种将 RocketMQ 消息中间件通过容器化的形式部署在 openEuler 操作系统上运行，借助 openEuler 零碎对于 OS 缓存回收效率加强的内核个性，晋升消息中间件在面向超大规模高并发、高吞吐量、低提早场景下稳定性和可靠性的软件解决方案。
RocketMQ 音讯队列在稳压测试中遇到的 OOM 问题
挪动云 RocketMQ 音讯队列产品正式上线前，通过压测工具，创立多组生产者 / 消费者过程对 RocketMQ 独享集群做多轮性能和稳定性的压力测试。
测试环境
压测后果
在某次继续长时间的压测过程中，发现音讯收发吞吐，在一段时间内的某一时刻会呈现大幅度 TPS（生产 / 生产）抖动降落的景象，并且是周期性的。挪动云 RocketMQ 音讯队列始终都比较稳定运行，为何在高并发的压测下也会呈现 TPS 的抖动？咱们初步狐疑是 CPU 负载或者 RocketMQ Broker 组件 GC 频率过高导致，但通过查看 CPU 负载和 JVM GC 频率并未发现任何异样。最终，通过排查发现是因为 Broker Pod 过程中的 buff/cache 在继续长时间压测下一直减少，零碎无奈及时无效回收，导致 Pod 中的运行过程占用内存空间超出事后设置的 Limit 限度，触发了 OOM Killer 机制重启了 Broker Pod。
RocketMQ on openEuler—解决大规模高并发场景下晋升稳定性的新抉择
为何在继续高并发下进行音讯收发会导致系统的 buff/cache 的继续减少？通过翻阅操作系统手册，可知 buff/cache 次要体现在零碎的 PageCache 上。
PageCache 在 RocketMQ 音讯存储中的重要作用
PageCache 也叫页缓冲或文件缓冲，在 linux 读写文件时，它用于缓存文件的逻辑内容，从而放慢对磁盘上映像和数据的拜访。上图中，红色局部即为，PageCache。可见 PageCache 的实质是由 Linux 内核治理的内存区域。平时咱们写的各种程序，通过 mmap 及 buffered I/O 将文件读取到内存空间实际上都是读取到 PageCache 中。为了在大规模高并发场景下实现实现低提早、高吞吐的指标，RocketMQ 音讯队列的存储模块次要采纳如下两种计划。
- 「Mmap + PageCache 的音讯并发读写计划」：在该计划中，音讯的读写流程都会通过 PageCache。在多线程并发读写的场景下，PageCache 不可避免会有锁的问题，尤其是在保护 PageCache 一致性时，零碎回刷脏页时磁盘压力较高，会导致呈现毛刺景象。
- 「堆外内存池化技术 + PageCache 的音讯读写拆散计划」：音讯写入时候写至 RocketMQ 启动时创立的堆外内存块（DirectByteBuffer）中，同时音讯从 PageCache 中读取。这样，音讯读写拆散使得整体流程并发性更好，无效升高时延，同时利用堆外内存池缩小了用户态与内核态的切换开销。
PageCache 在 RocketMQ 音讯队列的存储层扮演着无足轻重的作用，一旦零碎的 PageCache 呈现问题（如缓存回收、一致性和缺页中断等问题），都会对音讯收发的次要流程造成重大的影响。
openEuler 零碎在缓存回收效率方面的优化
为了避免 PageCache 申请过多（默认无限度）将牢靠内存耗尽，须要对 PageCache 的总量及应用牢靠内存总量进行限度。绝对于 CentOS 零碎内核无奈对未超出 node 节点内存资源的 PageCache 进行及时回收，openEuler 针对 PageCache 的回收减少了相干的零碎内核参数，并为限度 PageCache 使用量的性能提供若干 proc 接口，接口定义在 /proc/sys/vm/ 下，用来管制 PageCache 的使用量，具体如下：
- 「cache_reclaim_enable」：示意 PageCache 限度的性能的使能开关；
- 「cache_reclaim_s」：示意定期触发 cache 回收的工夫，以秒为单位。零碎会依据以后 online 的 cpu 个数来创立工作队列，如果有 n 个 cpu 则创立 n 个工作队列，每个工作队列每隔 cache_reclaim_s 秒进行一次回收。该参数与 cpu 高低线性能兼容，如果 cpu offline，则会缩小工作队列个数；反之，cpu online 则会减少工作队列个数。
- 「cache_reclaim_weight」：示意每次回收的权值，内核每个 CPU 每次冀望回收 32 * cache_reclaim_weight 个 page。该权值同时作用于 page 下限触发的回收和定期 pageCache 回收；
RocketMQ on openEuler 计划在生产环境中的验证
为解决遇到的 OOM 问题，咱们针对独享集群所在机器进行了操作系统内核版本的降级，更新至最新的 BC-Linux for Euler 21.10 版本（BC-Linux for Euler 是挪动云操作系统团队以 openEuler 社区操作系统为根底，借助开源社区的凋谢劣势，通过定制化形式研发的企业级 Linux 操作系统）。更新零碎后，采纳两种音讯体（1Kb 和 4Kb）别离对同样的测试环境进行长时间的压测。
测试场景 1
测试音讯大小 1Kb 音讯收发性能及长时间压测稳定性，测试中，独享集群可能达到收发音讯总和 TPS 为 2w+TPS（其中发送音讯 1w+TPS，生产音讯 1w+TPS）。音讯生产和生产的速度法则，如下图所示：从图中可见在音讯体大小为 1Kb 的音讯时，音讯生产和生产速度在长时间压测下没有抖动，TPS 放弃安稳，整个压测工夫服务失常。
测试场景 2
测试音讯大小 4Kb 音讯收发性能及长时间压测稳定性，测试中，集群可能达到收发音讯总和 TPS 为 1.4w+ TPS（其中发送音讯 0.7w+TPS，生产音讯 0.7w+TPS）。音讯生产和生产的速度法则，如下图所示：从图中可见在音讯体大小为 4Kb 的音讯时，音讯生产和生产速度长时间压测没有抖动，TPS 放弃安稳，整个压测工夫服务失常。
总结
挪动云 RocketMQ 音讯队列的独享实例在 22 年已实现了云原生化的齐全降级，特地适宜云原生、Serverless 化架构和大数据流计算的技术演进与相干利用场景。目前，RocketMQ on openEuler 的解决方案已在广州 3 AZ2、呼和浩特、北京、杭州等多个资源池上线且实现了局部存量服务器的迁徙与革新降级。后续，挪动云 RocketMQ 音讯队列并将一直晋升服务质量，为广大客户发明更多的价值。欢送大家多多关注。