大流量大负载的Kafka集群优化实战

前言背景

算法优化改版有大需求要上线，在线特征dump数据逐步放量，最终达到现有Kafka集群5倍的流量，预计峰值达到万兆网卡80%左右(集群有几十个节点，网卡峰值流出流量800MB左右/sec、写入消息QPS为100w+ msgs/sec)。上下游服务需要做扩容评估，提前做好容量规划，保障服务持续稳定运行

• L3层 dump特征 @xxx
  • 1.依赖文章特征公共服务
  • 2.依赖用户特征公共服务 前期可以一起共建
• 评估dump特征数据量 @xxx
• kafka新增Topic接收dump数据，评估kafka是否需要扩容 @xxx
• 新增拼接数据流支撑dump特征，需要评估新增机器 @xxx

经过对Kafka集群软硬件资源及利用率综合分析与评估，决定不扩容机器，完全可以应对流量扩大5倍的性能挑战

流量灰度时间表

• 2020-02-21放量进度 流量灰度10%
• 2020-02-24放量进度 流量灰度30%
• 2020-03-02放量进度 流量灰度50%
• 2020-03-02放量进度 流量灰度70%
• 2020-03-03放量进度 流量灰度85%
• 2020-03-05放量进度 流量灰度100%

优化纪实

预先优化在topics创建的情况下，没有流量时做的优化工作

本次在线特征dump放量topics列表如下：

onlinefeedback
indata_str_onlinefeedback_mixxxbrowser
indata_str_onlinefeedback_oppoxxxbrowser
indata_str_onlinefeedback_3rd
......</pre>

violet集群的topics为indata_str_click_s3rd 和 indata_str_video_3rd_cjv 完成扩容并rebalance找出其他流量大的topics列表

以上topic都已经创建，但是只覆盖了少数磁盘挂载点，violet集群有21个节点252磁盘挂载点，但有些topics的partitions数量不到30，造成磁盘利用率不高，IO不均衡。

优化点：扩容partitions数量，覆盖更多磁盘挂载点

现状&优化旅程

2020-02-21日 开始放量 topics均值流量小于20%，以下是放量后22~23日监控数据(读写IOPS、IOutil)

从以上数据分析，读写IOPS和ioutil极其不均衡，而且其中写IOPS走向极端上下两条线，后来查明原因是zk事务日志是实时单条commit，大量flink使用0.8.x版本，消费状态用zk存储造成的。另外还发现violet出口流量不均衡，高的70%、低的10%左右，当时flink消费出现阻塞现象，原因为上线前Flink未及时调大fetch.message.max.bytes的大小&#