方案概述

Kafka業務過載，一般表現為CPU使用率高、磁盤寫滿的現象。

• 當CPU使用率過高時，系統的運行速度會降低，并有加速硬件損壞的風險。
• 當磁盤寫滿時，相應磁盤上的Kafka日志目錄會出現offline問題。此時，該磁盤上的分區副本不可讀寫，降低了分區的可用性和容錯能力。同時由于Leader分區遷移到其他節點，會增加其他節點的負載。

CPU使用率高的原因

• 數據操作相關線程數（num.io.threads、num.network.threads、num.replica.fetchers）過多，導致CPU繁忙。
• 分區設置不合理，所有的生產和消費都集中在某個節點上，導致CPU利用率高。

磁盤寫滿的原因

• 業務數據增長較快，已有的磁盤空間不能滿足業務數據需要。
• 節點內磁盤使用率不均衡，生產的消息集中在某個分區，導致分區所在的磁盤寫滿。
• Topic的數據老化時間設置過大，保存了過多的歷史數據，容易導致磁盤寫滿。

實施步驟

CPU使用率高的處理措施：

• 優化線程參數num.io.threads、num.network.threads和num.replica.fetchers的配置。
• num.io.threads和num.network.threads建議配置為磁盤個數的倍數，但不能超過CPU核數。
• num.replica.fetchers建議配置不超過5。
• 合理設置Topic的分區，分區一般設置為節點個數的倍數。
• 生產消息時，給消息Key加隨機后綴，使消息均衡分布到不同分區上。

磁盤寫滿的處理措施：

• 擴容磁盤，使磁盤具備更大的存儲空間。
• 遷移分區，將已寫滿的磁盤中的分區遷移到本節點的其他磁盤中。
• 合理設置Topic的數據老化時間，減少歷史數據的容量大小。
• 在CPU資源情況可控的情況下，使用壓縮算法對數據進行壓縮。
• 常用的壓縮算法包括：ZIP，GZIP，SNAPPY，LZ4等。選擇壓縮算法時，需考慮數據的壓縮率和壓縮耗時。通常壓縮率越高的算法，壓縮耗時也越高。對于性能要求高的系統，可以選擇壓縮速度快的算法，比如LZ4；對于需要更高壓縮比的系統，可以選擇壓縮率高的算法，比如GZIP。

可以在生產者端配置“compression.type”參數來啟用指定類型的壓縮算法。

Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");
props.put("acks", "all");
props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
// 開啟GZIP壓縮
props.put("compression.type", "gzip");
Producer<String, String> producer = new KafkaProducer<>(props);