通常情況下，企業中會採取輪詢或者隨機的方式，通過Kafka的producer向Kafka叢集生產資料，來儘可能保證Kafka分割槽之間的資料是均勻分佈的。

在分割槽資料均勻分佈的前提下，如果我們針對要處理的topic資料量等因素，設計出合理的Kafka分割槽數量。對於一些實時任務，比如Spark Streaming/Structured-Streaming、Flink和Kafka整合的應用，消費端不存在長時間"掛掉"的情況即資料一直在持續被消費，那麼一般不會產生Kafka資料積壓的情況。

但是這些都是有前提的，當一些意外或者不合理的分割槽數設定情況的發生，積壓問題就不可避免。

Kafka訊息積壓的典型場景：

1. 實時/消費任務掛掉

比如，我們寫的實時應用因為某種原因掛掉了，並且這個任務沒有被監控程式監控發現通知相關負責人，負責人又沒有寫自動拉起任務的指令碼進行重啟。

那麼在我們重新啟動這個實時應用進行消費之前，這段時間的訊息就會被滯後處理，如果資料量很大，可就不是簡單重啟應用直接消費就能解決的。

2. Kafka分割槽數設定的不合理（太少）和消費者"消費能力"不足

Kafka單分割槽生產訊息的速度qps通常很高，如果消費者因為某些原因（比如受業務邏輯複雜度影響，消費時間會有所不同），就會出現消費滯後的情況。

此外，Kafka分割槽數是Kafka並行度調優的最小單元，如果Kafka分割槽數設定的太少，會影響Kafka consumer消費的吞吐量。

3. Kafka訊息的key不均勻，導致分割槽間資料不均衡

在使用Kafka producer訊息時，可以為訊息指定key，但是要求key要均勻，否則會出現Kafka分割槽間資料不均衡。

那麼，針對上述的情況，有什麼好的辦法處理資料積壓呢？

一般情況下，針對性的解決辦法有以下幾種：

1. 實時/消費任務掛掉導致的消費滯後

a. 任務重新啟動後直接消費最新的訊息，對於"滯後"的歷史資料採用離執行緒序進行"補漏"。

此外，建議將任務納入監控體系，當任務出現問題時，及時通知相關負責人處理。當然任務重啟指令碼也是要有的，還要求實時框架異常處理能力要強，避免資料不規範導致的不能重新拉起任務。

b. 任務啟動從上次提交offset處開始消費處理

如果積壓的資料量很大，需要增加任務的處理能力，比如增加資源，讓任務能儘可能的快速消費處理，並趕上消費最新的訊息

2. Kafka分割槽少了

如果資料量很大，合理的增加Kafka分割槽數是關鍵。如果利用的是Spark流和Kafka direct approach方式，也可以對KafkaRDD進行repartition重分割槽，增加並行度處理。

3. 由於Kafka訊息key設定的不合理，導致分割槽資料不均衡

可以在Kafka producer處，給key加隨機字尾，使其均衡。

推薦文章：

Kafka分割槽分配策略（Partition Assignment Strategy）

SparkStreaming和Kafka基於Direct Approach如何管理offset

如何為Kafka叢集確定合適的分割槽數以及分割槽數過多帶來的弊端

資料湖VS資料倉庫之爭？阿里提出湖倉一體架構

Kafka作為訊息系統的系統揭祕

關注微信公眾號：大資料學習與分享，獲取更對技術