kafka 線上真實環境實戰及調優進階系列
本套系列部落格從真實商業環境抽取案例進行總結和分享，並給出kafka商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。版權宣告：本套kafka調優系列版權歸作者(秦凱新)所有，禁止轉載，歡迎學習。
kafka真實環境部署規劃
1. 作業系統選型
因為kafka服務端程式碼是Scala語言開發的，因此屬於JVM系的大資料框架，目前部署最多的3類作業系統主要由Linux ，OS X 和Windows,但是部署在Linux數量最多，為什麼呢？因為I/O模型的使用和資料網路傳輸效率兩點。
- 第一：Kafka新版本的Clients在設計底層網路庫時採用了Java的Select模型，而在Linux實現機制是epoll,感興趣的讀者可以查詢一下epoll和select的區別，明確一點就是：kafka跑在Linux上效率更高，因為epoll取消了輪詢機制，換成了回撥機制，當底層連線socket數較多時，可以避免CPU的時間浪費。
- 第二：網路傳輸效率上。kafka需要通過網路和磁碟進行資料傳輸，而大部分作業系統都是通過Java的FileChannel.transferTo方法實現，而Linux作業系統則會呼叫sendFile系統呼叫，也即零拷貝（Zero Copy 技術），避免了資料在核心地址空間和使用者程式空間進行重複拷貝。
2. 磁碟型別規劃
- 機械磁碟（HDD） 一般機械磁碟尋道時間是毫秒級的，若有大量隨機I/O，則將會出現指數級的延遲，但是kafka是順序讀寫的，因此對於機械磁碟的效能也是不弱的，所以，基於成本問題可以考慮。
- 固態硬碟（SSD） 讀寫速度可觀，沒有成本問題可以考慮。
- JBOD (Just Bunch Of Disks ) 經濟實惠的方案，對資料安全級別不是非常非常高的情況下可以採用，建議使用者在Broker伺服器上設定多個日誌路徑，每個路徑掛載在不同磁碟上，可以極大提升併發的日誌寫入速度。
- RAID 磁碟陣列 常見的RAID是RAID10，或者稱為（RAID 1+0） 這種磁碟陣列結合了磁碟映象和磁碟帶化技術來保護資料，因為使用了磁碟映象技術，使用率只有50%，注意，LinkedIn公司採用的就是RAID作為儲存來提供服務的。那麼弊端在什麼地方呢？如果Kafka副本數量設定為3，那麼實際上資料將存在6倍的冗餘資料，利用率實在太低。因此，LinkedIn正在計劃更改方案為JBOD.
3. 磁碟容量規劃
我們公司物聯網平臺每天大約能夠產生一億條訊息，假設副本replica設定為2 （其實我們設定為3），資料留存時間為1周，平均每條上報事件訊息為1K左右，那麼每天產生的訊息總量為：1億 乘 2 乘 1K 除以 1000 除以 1000 =200G磁碟。預留10%的磁碟空間，為210G。一週大約為1.5T。採用壓縮，平均壓縮比為0.5，整體磁碟容量為0.75T。 關聯因素主要有：
- 新增訊息數
- 副本數
- 是否啟用壓縮
- 訊息大小
- 訊息保留時間
4. 記憶體容量規劃
kafka對於記憶體的使用，並不過多依賴JVM 記憶體,而是更多的依賴作業系統的頁快取，consumer若命中頁快取，則不用消耗物理I/O操作。一般情況下，java堆記憶體的使用屬於朝生夕滅的，很快會被GC,一般情況下，不會超過6G，對於16G記憶體的機器，檔案系統page cache 可以達到10-14GB。
- 怎麼設計page cache，可以設定為單個日誌段檔案大小，若日誌段為10G,那麼頁快取應該至少設計為10G以上。
- 堆記憶體最好不要超過6G。
5. CPU選擇規劃
kafka不屬於計算密集型系統，因此CPU核數夠多就可以，而不必追求時脈頻率，因此核數選擇最好大於8。
6. 網路頻寬決定Broker數量
頻寬主要有1Gb/s 和10 Gb/s 。我們可以稱為千兆位網路和萬兆位網路。舉例如下： 我們的物聯網系統一天每小時都要處理1Tb的資料，我們選擇1Gb/b頻寬，那麼需要選擇多少機器呢？
- 假設網路頻寬kafka專用，且分配給kafka伺服器70%頻寬，那麼單臺Borker頻寬就是710Mb/s，但是萬一出現突發流量問題，很容易把網路卡打滿，因此在降低1/3,也即240Mb/s。因為1小時處理1TTB資料，每秒需要處理292MB,1MB=8Mb，也就是2336Mb資料，那麼一小時處理1TB資料至少需要2336/240=10臺Broker資料。冗餘設計，最終可以定為20臺機器。
典型推薦
- cpu 核數 32
- 記憶體 32GB
- 磁碟 3TB 7200轉 SAS盤三塊
- 頻寬 1Gb/s
結語
秦凱新 於深圳 2018-10-27