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

前言背景

算法优化改版有大需求要上线，在线特征dump数据逐步放量，最终达到现有Kafka集群5倍的流量，预计峰值达到万兆网卡80%左右(集群有几十个物理节点，有几PB的容量，网卡峰值流出流量会达到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
......

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的大小，引起violet集群部分broker网络出口流量飙升。

2020-02-26日 在线特征dump数据的topics均值放量到50%左右
优化zk集群写入性能从1.5k降到100之内，单事务写强制刷盘改成事务批量按期刷盘，在线Dump特征流量放量，排查violet集群线上隐患，因为消费端flink仍是依赖的较低kafka-0.8.x版本，消费状态存储zk，致使写入频繁。此外zk的日志数据和事务数据目录从数据盘调整到系统盘，数据盘统一Kafka使用

 

 

客户端使用优化 

serving使用kafka按key进行hash分配出现生产倾斜致使消费出现lag，和业务方商定修改消费逻辑解决此问题
2020-03-02日 在线特征dump放量75%，优化violet集群IO完成了80%以上，支撑在线特征100%放量应该没有问题，主要对10.120.14.十一、10.103.35.七、10.103.35.二、10.120.10.8等4个节点IO削峰均衡化，热点挂载点IO峰值降低30~60%不等，操做策略以下：

• 扩容partitions，topics数据量大，partitions数量少，与业务沟通，扩partitions分配到低IO挂载点上
• 迁移partitions，partitions目录迁移和节点迁移，找出热点挂载点，分析出高读写的partitions，迁移到使用率低的磁盘挂载点上
• 调整topic保留时间，保证业务磁盘容量够用不浪费，与业务沟通，设置topics最小保留时间

优化前监控(3.02~3.03区间数据)

 

 

ioutil被打满，磁盘很是繁忙，响应变慢等待时间变长

优化后效果以下(3.06日区间数据)

 

 

红框部分IO持续高位为当时部分partition迁移致使的，能够忽略不计，因为2020-03-0二、2020-03-0三、2020-03-05持续放量直到100%，优化效果不明显

2020-03-04日 客户端参数优化

jstorm 

 

 

 

 

 flink

 

 

03-06日 优化violet集群IO完成了95%以上，主要对10.120.14.十一、10.103.35.七、10.103.35.二、10.103.35.三、10.103.35.十、10.120.10.二、10.120.10.三、10.120.10.五、10.120.10.六、10.120.10.七、10.120.10.八、10.120.10.九、10.120.10.11等13个节点IO削峰均衡化和磁盘使用率均衡化 

下面是3.07~3.08日区间监控数据

 

 

 

 

 

3.08日 内时间点监控数据

 

 

3.08日 是周日 经过监控获知indata_str_onlinefeedback_mibrowser和indata_str_onlinefeedback_3rd-small消费流量比较大，须要作IO均衡化
indata_str_onlinefeedback_mibrowser每秒消费流量

 

 

indata_str_onlinefeedback_3rd-small每秒消费流量2.5GB

 

 

03.09日 截止下午17:00最近6小时数据(3.08日晚优化后效果)

内核参数优化 

sudo blockdev --setra  16384  /dev/sdx
sudo sh -c 'echo "4096" > /sys/block/sdx/queue/nr_requests'
sudo sh -c 'echo "500" > /proc/sys/vm/dirty_writeback_centisecs'
sudo sh -c 'echo "35" > /proc/sys/vm/dirty_ratio'
sudo sh -c 'echo "5" > /proc/sys/vm/dirty_background_ratio'
sudo sh -c 'echo "2000" > /proc/sys/vm/dirty_expire_centisecs'

2020-03-11日 截止下午17:00最近6小时数据　　

 

 

可否彻底磁盘IO均衡，比较困难，但还能够下降，由于这跟客户端生产/消费策略及消费历史数据有关，有些不可控因素。

2020-03-11日 kafka jvm heap优化 经过Kafka集群业务监控发现利用率低
减小jvm heap大小，让渡给pagecache作系统级数据缓存

 

 

 

 

另外Apache Kafka PMC大神王国璋回复：Kafka对内存要求不大，可是若是客户端版本较低会须要down convert version，这个过程是很是消耗CPU和内存的。缘由是Producer向Kafka写入数据时，占用的堆外内存NIO Buffer，当消费读数据时，Kafka并不维护内存数据，由于使用系统函数sendfile将数据直接从磁盘文件复制到网卡设备中，而不须要经由应用程序之手。采集监控数据以下：

NIO Buffer

 

 

 

 non-heap memory

 

 

 

早期jvm heap配置为32GB，后来优化为16GB，如今降到10GB，既保证了kafka进程稳定，又不浪费内存

优化可否一次性解决到位 

性能优化可否预先或提早一次性所有搞定？
通常性topics的partitions扩容能够提早作，jvm heap也能够提早修改，可是有些参数就无法肯定了，由于集群流量不大，负载不高，没有性能瓶颈，找不到更看不出瓶颈在哪里，优化了也看不出效果。之内核参数优化为例

Centos Performance Tuning

另外IO均衡化也是，集群流量压力不大，找不到须要IO均衡化的目标topics。只有流量逐步放大，才容易发现并识别问题topics

因此优化须要分类、分批、分场景、根据瓶颈、风险、效果、难易程度逐步推动。

从预先优化到全面优化 

在线特征dump上线持续放量直至100%过程，咱们作了大量调整和优化，它是一个按部就班和不断完善的过程，不可能一蹴而就，回顾优化列表以下：

• 提早预先优化，预估大流量topics，扩容partitions覆盖更多磁盘挂载点
• 依赖服务zookeeper优化：单条事务消息刷盘改成批量刷盘
• 容器级优化：jvm heap利用率优化，从16GB下降大10GB，多余物理内存腾出给pagecache使用
• Kafka服务应用级优化
  • 调大replica.fetch.wait.max.ms，下降replica fetch Request无效请求数，释放cpu计算和内存资源
  • 增大replica.fetch.max.bytes，特别是kafka重启下降目标broker读IOPS
  • 调大为zookeeper.session.timeout = 20000ms，避免网络抖动异常致使broker掉线
• 业务客户端优化
  • jstorm
    • 生产端：增大batch大小，下降Producer Request次数，给磁盘write IO降压
    • 消费端：增大各个fetch参数，下降生产/消费速率，给磁盘read IO降压
  • flink：增大并行度，结合异步和jvm参数
• 持续IO均衡化
  • 扩容partitions，topics数据量大，partitions数量少，与业务沟通，扩partitions分配到低IO挂载点上
  • 迁移partitions，partitions目录迁移和节点迁移，找出热点挂载点，分析出高读写的partitions，迁移到使用率低的磁盘挂载点上
  • 调整topic保留时间，保证业务磁盘容量够用不浪费，与业务沟通，设置topics最小保留时间
• centos内核参数优化，目标是提高性能，保证稳定，同时充分利用pagecache和OS读写磁盘特性，用各类策略榨干取尽其资源
  
  • 设置/sys/block/sdb/queue/read_ahead_kb
  • 设置/sys/block/sdc/queue/nr_requests
  • ...省略，了解更多请看 centos系统参数优化

partition迁移重点分析

要作到全面性、多维度、立体化的综合性能优化并达到预期理想效果，须要对相关Kafka、jvm、netty技术原理及OS等等(不限于)有至关理解。例如持续IO均衡化，就是须要运用综合手段来解决，利用管理平台、各种监控数据和shell命令找出触发瓶颈的topics及对应partitions，而后用工具迁移实现IO再平衡。

 

以上操做是反复循环进行的动做，观察-》分析-》操做-》查看效果-》再观察... 反复进行直至达到最佳状态

如下为partitions目录迁移bugs，通过分析，重启后解决，错误缘由是broker应用内存中保留了partition目录迁移状态信息，重启后还原，但继续执行迁移须要从新操做

 

 小结

• 预先优化，保证初期放量稳定，性能不打折
• 持续优化，采起多种手段拍平IO毛刺，同时兼顾磁盘容量均衡
• 想要达到最佳效果，须要对centOS底层TCP传输、网络处理、pagecache使用、IO调度、磁盘读写调度及刷盘机制有综合性全面的理解；要对Kafka的底层原理、各类配置参数项等具备深入理解，能够进行Kafka集群参数调优，快速处理突发故障、恢复集群抖动和动态进行集群扩缩容等

 

博客引用地址：http://www.javashuo.com/article/p-zbntnfay-gc.html