Kafka實戰(七) - 優雅地部署 Kafka 集羣

既然是集羣，必然有多個Kafka節點，只有單節點構成的Kafka僞集羣只能用於平常測試，不可能知足線上生產需求。
真正的線上環境須要考量各類因素，結合自身的業務需求而制定。看一些考慮因素（如下順序，但是分了順序的哦）

1 操做系統 - OS

可能你會問Kafka不是JVM上的大數據框架嗎？Java又是跨平臺的語言，把Kafka安裝到不一樣的操做系統上會有什麼區別嗎？
區別至關大！

確實，Kafka由Scala/Java編寫，編譯後源碼就是「.class」文件。
原本部署到哪一個OS應該同樣，可是不一樣OS的差別仍是給Kafka集羣帶來了至關大的影響。
毋庸置疑，部署在Linux上的生產環境是最多的。

考慮操做系統與Kafka的適配性，Linux系統顯然要比其餘兩個特別是Windows系統更加適合部署Kafka。可具體緣由你能談笑風生嗎？

1.1 I/O模型

I/O模型能夠近似認爲I/O模型就是OS執行I/O指令的方法。
主流的I/O模型一般有5種類型：

1. 阻塞式I/O
   e.g. Java中Socket的阻塞模式
2. 非阻塞式I/O
   e.g. Java中Socket的非阻塞模式
3. I/O多路複用
   e.g. Linux中的系統調用select函數
4. 信號驅動I/O
   e.g. epoll系統調用則介於第三種和第四種模型之間
5. 異步I/O
   e.g. 不多有Linux支持，反而Windows系統提供了一個叫IOCP線程模型屬於該類

我在這裏不詳細展開每一種模型的實現細節，由於那不是本文重點。

言歸正傳，I/O模型與Kafka的關係幾何？
Kafka Client 底層使用了Java的selector，而selector

• 在Linux上的實現機制是epoll
• 在Windows平臺上的實現機制是select

所以在這一點上將Kafka部署在Linux上是有優點的，可以得到更高效的I/O性能。

1.2 數據網絡傳輸效率

Kafka生產和消費的消息都是經過網絡傳輸的，而消息保存在哪裏呢？
確定是磁盤！
故Kafka須要在磁盤和網絡間進行大量數據傳輸。
Linux有個零拷貝（Zero Copy）技術，就是當數據在磁盤和網絡進行傳輸時避免昂貴內核態數據拷貝從而實現快速數據傳輸。Linux平臺實現了這樣的零拷貝機制，但有些使人遺憾的是在Windows平臺上必需要等到Java 8的60更新版本才能「享受」到。

一句話，在Linux部署Kafka可以享受到零拷貝技術所帶來的快速數據傳輸特性帶來的極致快感。

1.3 社區生態

社區目前對Windows平臺上發現的Kafka Bug不作任何承諾。所以，Windows平臺上部署Kafka只適合於我的測試或用於功能驗證，千萬不要應用於生產環境。

2 磁盤

2.1 靈魂拷問：機械硬盤 or 固態硬盤

• 前者便宜且容量大，但易壞！
• 後者性能優點大，可是貴！

建議是使用普通機械硬盤便可。

• Kafka雖然大量使用磁盤，可可能是順序讀寫操做，必定程度上規避了機械磁盤最大的劣勢，即隨機讀寫慢。從這一點上來講，使用SSD並無太大性能優點，機械磁盤物美價廉
• 而它因易損壞而形成的可靠性差等缺陷，又由Kafka在軟件層面提供機制來保證

2.2 是否應該使用磁盤陣列（RAID）

使用RAID的兩個主要優點在於：

• 提供冗餘的磁盤存儲空間
• 提供負載均衡

不過就Kafka而言

• Kafka本身實現了冗餘機制提供高可靠性
• 經過分區的設計，也能在軟件層面自行實現負載均衡

如此說來RAID的優點也就沒有那麼明顯了。雖然實際上依然有不少大廠確實是把Kafka底層的存儲交由RAID的，只是目前Kafka在存儲這方面提供了愈來愈便捷的高可靠性方案，所以在線上環境使用RAID彷佛變得不是那麼重要了。
綜上，追求性價比的公司能夠不搭建RAID，使用普通磁盤組成存儲空間便可。使用機械磁盤徹底可以勝任Kafka線上環境。

2.3 磁盤容量

集羣到底須要多大？
Kafka須要將消息保存在磁盤上，這些消息默認會被保存一段時間而後自動被刪除。
雖然這段時間是能夠配置的，但你應該如何結合自身業務場景和存儲需求來規劃Kafka集羣的存儲容量呢？

假設有個業務

• 天天須要向Kafka集羣發送1億條消息
• 每條消息保存兩份以防止數據丟失
• 消息默認保存兩週時間

如今假設消息的平均大小是1KB，那麼你能說出你的Kafka集羣須要爲這個業務預留多少磁盤空間嗎？

計算：

• 天天1億條1KB的消息，存兩份
  1億 * 1KB * 2 / 1000 / 1000 = 200GB

• 通常Kafka集羣除消息數據還存其餘類型數據，好比索引數據
  再爲其預留10%磁盤空間，所以總的存儲容量就是220GB

• 要存兩週，那麼總體容量即爲
  220GB * 14，大約3TB

• Kafka支持數據的壓縮，假設壓縮比是0.75
  那麼最後規劃的存儲空間就是0.75 * 3 = 2.25TB

總之在規劃磁盤容量時你須要考慮下面這幾個元素：

• 新增消息數
• 消息留存時間
• 平均消息大小
• 備份數
• 是否啓用壓縮

3 帶寬

對於Kafka這種經過網絡進行大數據傳輸的框架，帶寬容易成爲瓶頸。
普通的以太網絡，帶寬主要有兩種：1Gbps的千兆網絡和10Gbps的萬兆網絡，特別是千兆網絡應該是通常公司網絡的標準配置了
以千兆網絡爲例，說明帶寬資源規劃。

真正要規劃的是所需的Kafka服務器的數量。
假設機房環境是千兆網絡，即1Gbps，如今有業務，其目標或SLA是在1小時內處理1TB的業務數據。
那麼問題來了，你到底須要多少臺Kafka服務器來完成這個業務呢？

計算

帶寬1Gbps，即每秒處理1Gb數據
假設每臺Kafka服務器都是安裝在專屬機器，即每臺Kafka機器上沒有混入其餘服務
一般狀況下你只能假設Kafka會用到70%的帶寬資源，由於總要爲其餘應用或進程留一些資源。超過70%的閾值就有網絡丟包可能性，故70%的設定是一個比較合理的值，也就是說單臺Kafka服務器最多也就能使用大約700Mb帶寬。

這只是它能使用的最大帶寬資源，你不能讓Kafka服務器常規性使用這麼多資源，故一般要再額外預留出2/3的資源，即
單臺服務器使用帶寬700Mb / 3 ≈ 240Mbps
這裏的2/3實際上是至關保守的，能夠結合機器使用狀況酌情減小該值

有了240Mbps，能夠計算1小時內處理1TB數據所需的服務器數量了。
根據這個目標，每秒須要處理2336Mb的數據，除以240，約等於10臺服務器。
若是消息還須要額外複製兩份，那麼總的服務器臺數還要乘以3，即30臺。

總結

與其盲目上馬一套Kafka環境而後過後費力調整，不如在一開始就思考好實際場景下業務所需的集羣環境。在考量部署方案時須要通盤考慮，不能僅從單個維度上進行評估。

參考

• Linux內核模型架構
• Kafka核心技術與實戰