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例外，
本文由華為云發布，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/447059.html
標籤：其他
上一篇：ClickHouse副本機制簡介