作者介绍

日志 KAFKA 集群承载了全司的应用日志。

高峰每分钟流量 TP 级，每分钟接收数十亿条数据。

每天数据流量 PB 级 ,每天接收消息条数超过万亿级。

Broker : KAFKA 集群中的一个节点。

网络闲置率：是 KAFKA 服务的一个重要指标，即网络线程池线程平均的空闲比例，通常用于衡量集群的繁忙程度。集群没有流量时为最大值1，随着集群压力变大会逐渐变小，达到0.3以下集群性能就会达到瓶颈，就表明你的网络线程池非常繁忙，集群无法保证读写请求的及时处理，造成生产丢数以及消费堆积的问题。需要通过增加网络线程数或将负载转移给其他服务器的方式，来给该 Broker 减负。

请求队列：客户端发起的请求首先存放在这个队列，服务端拉取请求并进行处理。 主要包含了消费以及生产请求。

kubernetes 是个基于容器技术的分布式集群管理系统，或者说是容器编排、管理的编排平台。

pod 是 k8s 中的最小调度单元，应用以此作为载体调度运行。pod 内可以只有一个容器也可以包含多个容器，共享网络命名空间、存储资源等，我们的 filebeat 运行环境便是随着业务 pod 中注入一个 filebeat sidecar 容器来进行业务日志收集。

在节日流量高峰时，机器的 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 传输之前，会在一个内存队列做一次缓冲后再发送，关于这个默认队列，官方的参数如下：

queue.mem:  events:4096  flush.min_events:2048  flush.timeout: 1s

1）内存测试结果

当分区数低的时候，将 flush.timeout 调为 5S，压缩率效果明显提升，但是当分区数和线上环境保持一致后，效果还是不明显。

2）深入研究

在验证的过程之中，发现 Filebeat 传输与分区数有密切关系，同等数据的情况下，分区数越多，压缩率越低，请求数越多。

查阅官网发现参数：

round_robin.group_events：该参数含义为，设置在分区器选择下一个分区之前要发布到同一分区的事件数。默认值为 1，表示在每个事件之后都会选择下一个分区。

该参数通过将同一分区的多个事件打包发送，减少分区切换频率，从而提升单个请求的批次大小，增加压缩率。

3）分区测试结果

对上述参数的 filebeat 架构图总结

下图是整个优化过程的核心，通过加大内存队列的攒批能力，以及增大分区每个批次的条数，从而达到增大压缩率的目的。

 TIPS：

内存队列的量是由上游不同类型的日志累加，故 QPS 高的日志会在内存中占比较大。

若内存里的数据与分区数的比值大于 round_robin.group_events 参数时，以比值为主。比如内存有100条数据，Topic 4个分区，则比值为25，这时将round_robin.group_events 设置为10是没有效果的。

从上面测试结果可以看到不同的批次下，网卡流量会有变化，这个现象最初我们理解为 KAFKA 性能的下降。通过测试发现，批次提高后压缩比会提高，网络层面也是一个间接的优化效果。而且不光是网络，磁盘也会有节约，下面是不同批次下的压缩数据测试。

通过测试可以发现，条数超过50条的时候压缩比基本保持一致。这里的数据单条1KB。

1）线上压缩效果图

以下是增加压缩批次后，单条数据的大小减少了35%（说明：单条数据大小=流量/条数）。

filebeat 参数

queue.mem:  events:4096  flush.min_events:2048  flush.timeout: 5s （默认值1S）round_robin.group_events: 10 （默认值1）

找到线上的一些代表性的 topic 进行测试，测试结果符合预期，生产请求数降低了30%，流量降低了30-40%。

灰度测试没问题后，开始发布线上版本，但线上应用，需要重新发布才能生效。发布一周后效果明显，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