前言背景
算法優化改版有大需求要上線，在線特征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倍的性能挑戰：
- 集群有30台物理機，每台物理機有24core、48線程 128G內存，掛載12塊磁盤，當前CPU占用大約15%、磁盤使用率15~30%、磁盤讀寫延遲100ms、單個磁盤IOutil最高峰45%
- 磁盤IO讀寫不均衡，磁盤間數據分布不均衡
流量灰度時間表
- 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.11、10.103.35.7、10.103.35.2、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-02、2020-03-03、2020-03-05持續放量直到100%，優化效果不明顯
2020-03-04日 客戶端參數優化
jstorm
flink
03-06日 優化violet集群IO完成了95%以上，主要對10.120.14.11、10.103.35.7、10.103.35.2、10.103.35.3、10.103.35.10、10.120.10.2、10.120.10.3、10.120.10.5、10.120.10.6、10.120.10.7、10.120.10.8、10.120.10.9、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參數
- jstorm
- 持續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集群參數調優，快速處理突發故障、恢復集群抖動和動態進行集群擴縮容等