余东&王克礼 2025-06-26 07:15 广东
提升闲置率保证集群对业务的稳定，降低客户端生产消费次数，减少 IO 读写，减少流量。
文章概览
背景介绍
术语介绍
KAFKA 生产痛点与优化目标
优化过程
方案验证及上线
优化效果明细
优化总结
未来规划
作者介绍
余东，去哪儿旅行大数据运维。主要负责 KAFKA 和 FLINK 集群的开发和运维，以及自动化运维平台的建设。
王克礼，去哪儿网开发专家、后端架构负责人，主要负责基础框架、中间件、公共服务、服务可观测等领域的研发、稳定性保障工作。
一、背景介绍
业务背景
日志 KAFKA 集群承载了全司的应用日志。
高峰每分钟流量 TP 级，每分钟接收数十亿条数据。
每天数据流量 PB 级 ,每天接收消息条数超过万亿级。
日志集群架构图
二、术语介绍
KAFKA 术语
Broker : KAFKA 集群中的一个节点。
网络闲置率：是 KAFKA 服务的一个重要指标，即网络线程池线程平均的空闲比例，通常用于衡量集群的繁忙程度。集群没有流量时为最大值1，随着集群压力变大会逐渐变小，达到0.3以下集群性能就会达到瓶颈，就表明你的网络线程池非常繁忙，集群无法保证读写请求的及时处理，造成生产丢数以及消费堆积的问题。需要通过增加网络线程数或将负载转移给其他服务器的方式，来给该 Broker 减负。
请求队列：客户端发起的请求首先存放在这个队列，服务端拉取请求并进行处理。 主要包含了消费以及生产请求。
kubernetes 术语
kubernetes 是个基于容器技术的分布式集群管理系统，或者说是容器编排、管理的编排平台。
pod 是 k8s 中的最小调度单元，应用以此作为载体调度运行。pod 内可以只有一个容器也可以包含多个容器，共享网络命名空间、存储资源等，我们的 filebeat 运行环境便是随着业务 pod 中注入一个 filebeat sidecar 容器来进行业务日志收集。
三、KAFKA 生产痛点与优化目标
痛点
在节日流量高峰时，机器的 IO，存储，闲置率都开始骤增，服务端响应用户请求变慢，导致消费 KAFKA 出现堆积。高峰对部分业务采取了降级措施，但会影响业务数据的完整性。
目标
从根本去解决问题，优化传输链路，在不影响业务读写的情况下，增加压缩批次，减少服务端的请求量、流量、CPU 的消耗。
四、优化过程
从现象分析，KAFKA 压力大的最大根因是生产压缩率低。
压缩率低会带来以下问题
高峰期流量很大，磁盘存储均值达到70%，部分机器存储峰值达到87%。
客户端对 KAFKA 的请求量在高峰期急剧增加，导致服务端压力增大。
请求数指标验证
确认了问题的关键是压缩率低之后，需要想办法提升压缩率，KAFKA 的请求在 filebeat 客户端。我们需要研究 filebeat 的参数配置。
从 filebeat 官网确认，涉及到批次发送的有两个参数 bulk_flush_frequency 和 bulk_max_size，线上使用的 filebeat 没有配置这两个参数。
其中含义如下：
bulk_flush_frequency 批量发送 KAFKA request 需要等待的时间，默认0不等待。
bulk_max_size 单次 KAFKA request 请求批量的消息数量，默认2048。
针对这两个参数我们做了测试，将bulk_flush_frequency从0.1提升至0.2。
1）相关参数
bulk_flush_frequency:0.2bulk_max_size:2048
2）测试结果
优化效果不明显，对集群没有提升，继续分析原因。
FILEBEAT 内存参数研究
查阅资料，发现了在 filebeat 传输之前，会在一个内存队列做一次缓冲后再发送，关于这个默认队列，官方的参数如下：
queue.mem:events:4096flush.min_events:2048flush.timeout: 1s
1）内存测试结果
当分区数低的时候，将 flush.timeout 调为 5S，压缩率效果明显提升，但是当分区数和线上环境保持一致后，效果还是不明显。
2）深入研究
在验证的过程之中，发现 Filebeat 传输与分区数有密切关系，同等数据的情况下，分区数越多，压缩率越低，请求数越多。
查阅官网发现参数：
round_robin.group_events：该参数含义为，设置在分区器选择下一个分区之前要发布到同一分区的事件数。默认值为 1，表示在每个事件之后都会选择下一个分区。
该参数通过将同一分区的多个事件打包发送，减少分区切换频率，从而提升单个请求的批次大小，增加压缩率。
3）分区测试结果
应用名称 | 优化前每分钟流量 | 优化前每分钟请求量 | 优化后每分钟流量 | 优化后每分钟请求量 | |
1 | test_pub_****** | 50M | 20万 | 30M | 6万 |
对上述参数的 filebeat 架构图总结
下图是整个优化过程的核心，通过加大内存队列的攒批能力，以及增大分区每个批次的条数，从而达到增大压缩率的目的。
TIPS：
内存队列的量是由上游不同类型的日志累加，故 QPS 高的日志会在内存中占比较大。
若内存里的数据与分区数的比值大于 round_robin.group_events 参数时，以比值为主。比如内存有100条数据，Topic 4个分区，则比值为25，这时将round_robin.group_events 设置为10是没有效果的。
SNAPPY 压缩测试
从上面测试结果可以看到不同的批次下，网卡流量会有变化，这个现象最初我们理解为 KAFKA 性能的下降。通过测试发现，批次提高后压缩比会提高，网络层面也是一个间接的优化效果。而且不光是网络，磁盘也会有节约，下面是不同批次下的压缩数据测试。
通过测试可以发现，条数超过50条的时候压缩比基本保持一致。这里的数据单条1KB。
条数 | 压缩后大小 |
1 | 1.1K |
5 | 1.3K |
20 | 2.2K |
50 | 4K |
100 | 8K |
200 | 16K |
1）线上压缩效果图
以下是增加压缩批次后，单条数据的大小减少了35%（说明：单条数据大小=流量/条数）。
五、方案验证及上线
线上灰度测试验证
filebeat 参数
queue.mem:events:4096flush.min_events:2048flush.timeout: 5s （默认值1S）round_robin.group_events: 10 （默认值1）
找到线上的一些代表性的 topic 进行测试，测试结果符合预期，生产请求数降低了30%，流量降低了30-40%。
应用名称 | 优化前每分钟流量 | 优化前每分钟请求量 | 优化后每分钟流量 | 优化后每分钟请求量 | |
1 | test_1*** | 40G | 1600万 | 23G | 500万 |
2 | test_2*** | 33G | 1500万 | 21G | 200万 |
3 | test_3*** | 280G | 2.2亿 | 220G | 1.2亿 |
上线
灰度测试没问题后，开始发布线上版本，但线上应用，需要重新发布才能生效。发布一周后效果明显，CPU ，网络流量，磁盘都有不同程度的资源节约。
1）上线后的优化数据
CPU 从36%降到22%
TOPIC 生产请求数降低了42%
集群流量下降了20%
六、优化效果明细
七、优化总结
优化结果：每分钟降低上亿的客户端请求量，流量降低了35%，优化前每分钟只能承载26亿条消息，优化后五一压测每分钟能承载33亿条，KAFKA 提升了35%上限。
优化思路：提升闲置率保证集群对业务的稳定，降低客户端生产消费次数，减少 IO 读写，减少流量。
优化步骤：完善集群监控，加入指标。客户端读写次数，闲置率，生产条数与生产次数的比值，流量与生产次数的比值（计算单条消息大小），IO，流量等基础指标。
八、未来规划
未来随着业务增长，KAFKA 数据也会不断膨胀，集群压力随之增长，如 IO、网卡、闲置率、磁盘存储、CPU 等。需要权衡一个压缩值，既不影响数据延迟，也能提升集群容量，保障业务线的增长。
作者丨余东、王克礼
来源丨公众号：Qunar技术沙龙（ID：QunarTL）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
