Kafka使用最佳實踐-Kafka常見的使用誤區

1. kafka集群單個節點磁盤掛載的越多越好

業界Kafka的標準使用方式是作為臨時緩存使用。因此，很多人會誤以為，kafka的每個節點只要存儲夠大就行，不用關心其他的指標。官方并不建議kafka單節點關在多個磁盤，因為磁盤越多，表示需要更多的處理線程去管理（num.io.thread決定），CPU的壓力將非常大，如果磁盤數大于了CPU邏輯核數，kafka的CPU將因為非常繁忙導致數據落盤失敗，從而影響業務。

建議：

建議每個節點掛盤數，滿足每臺機器最大掛盤數量 <= processor（CPU邏輯核數） / 2。

最優策略為每個節點使用raid5或者raid10掛載數據目錄，每個raid5或者raid10的邏輯盤不超過8塊。

2. 把kafka當做數據庫使用

很多人認為，如果數據重要，需要把kafka中的數據保存周期延長到很大（例如：1年），例如。Kafka對于數據目錄中的每個segment文件會有一個操作句柄對應，如果數據保存周期過長，會導致操作句柄使用率增加，如果句柄數無限制增加并且到達上限后會導致kafka服務異常。正常情況下，業務側應當根據集群中的磁盤總容量來評估數據的保留時間。如果，集群中的業務種類多、數據量大。于此同時又不關心數據量的大小，很容易造成磁盤容量不足。

建議：

建議業務側評估好數據量的大小，調整合適的保留時間。一般情況下，建議使用7天即可。

3. 分區數越多越好

Kafka增加分區數的作用主要有兩點：第一：將數據分布均勻，防止不會出現某個節點或者某個數據盤的數據熱點。第二，提升消費并行度，消費者通常與分區是一一對應的，提升分區數同樣也能提升消費者的個數，從而提升消費性能。但是分區數不能無限制增加，如果數量太多會導致kafka和zookeeper負載增高，kafka內部調度線程無法及時處理響應，導致節點進程故障。

建議:

集群中topic總量不超過2000，每個節點的分區總量不超過2000。

如果業務重要或者數據量很大，建議分區量=節點數*磁盤數，如果該數值大于200，則分區數選擇為200，如果后期需要需要提升分區數來提升讀寫性能，可以使用kafka后臺命令逐步提升，如果數據量很小，建議分區量=節點數，保證每個節點的數據量均衡。

4. 業務側對寫入kafka的數據大小不感知

kafka組件的主要定位為消息隊列（非文件隊列），官方建議寫入kafka最佳的數據大小不超過15K。但是在很多的業務場景下，需要寫入的數據往往是大于15k的。Kafka服務端默認可以接受的最大的數據大小為10M

建議：

客戶端默認單條數據大小最大為1M（由配置request.size決定），在數據大小小于1M的情況下，使用默認值發送數據即可。

如果數據在1M到5M之間，開啟在生產端開啟壓縮模式（由type決定，可以選擇gzip,?snappy, 或者lz4），開啟壓縮后，生產端的壓縮數據過程和消費端的解壓縮數據過程會增加CPU的使用率。

不建議發送大于5M的數據，經過驗證持續返送大于5M的數據會導致kafka的直接內存溢出。

5. Topic可以隨意的創建和刪除

Kafka的topic代表了一個類型的數據，頻繁的創建刪除topic會導致zookeeper通信壓力大，出現broker節點信息上報失敗，服務不可用的情況。一旦zookeeper出現異常，刪除topic的流程會處于阻塞狀態，導致topic無法正常刪除。

建議：

Topic不建議頻繁創建刪除。

對于有共同特點的數據（例如：協議類型相同），可以歸并到一個topic里面處理。

6. 頻繁使用舊版本客戶端消費工具

舊版本的消費工具使用的命令如下：

每使用一次就會在zookeeper下生成一個永久節點。這個節點不會自動清理，如果經常使用會導致zookeeper異常。

EI企業智能 FusionInsight Kafka ZooKeeper

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。