Kafka線上集羣部署方案怎麼作？

Kafka線上集羣部署方案怎麼作？

如今咱們就來看看在生產環境中的 Kafka 集羣方案該怎麼作。

既然是集羣，那必然就要有多個 Kafka 節點機器，由於只有單臺機器構成的 Kafka 僞集羣只能用於平常測試之用，根本沒法知足實際的線上生產需求。
而真正的線上環境須要仔細地考量各類因素，結合自身的業務需求而制定。

下面我就分別從操做系統、磁盤、磁盤容量和帶寬等方面來討論一下。

操做系統

首先咱們先看看要把 Kafka 安裝到什麼操做系統上。提及操做系統，可能你會問 Kafka 不
是 JVM 系的大數據框架嗎？

Java 又是跨平臺的語言，把 Kafka 安裝到不一樣的操做系統上
會有什麼區別嗎？其實區別至關大！
的確，如你所知，Kafka 由 Scala 語言和 Java 語言編寫而成，編譯以後的源代碼就是普通
的「.class」文件。原本部署到哪一個操做系統應該都是同樣的，可是不一樣操做系統的差別還
是給 Kafka 集羣帶來了至關大的影響。

目前常見的操做系統有 3 種：Linux、Windows 和
macOS。應該說部署在 Linux 上的生產環境是最多的，也有一些 Kafka 集羣部署在
Windows 服務器上。Mac 雖然也有 macOS Server，可是我懷疑是否有人（特別是國內
用戶）真的把生產環境部署在 Mac 服務器上。

**若是考慮操做系統與 Kafka 的適配性，Linux 系統顯然要比其餘兩個特別是 Windows 系
統更加適合部署 Kafka**。雖然這個結論可能你不感到意外，但其中具體的緣由你也必定要了解。

主要是在下面這三個方面上，Linux 的表現更勝一籌。

• I/O 模型的使用
• 數據網絡傳輸效率
• 社區支持度

I/O 模型的使用

我分別來解釋一下，首先來看 I/O 模型。什麼是 I/O 模型呢？

你能夠近似地認爲 I/O 模型
就是操做系統執行 I/O 指令的方法。

主流的 I/O 模型一般有 5 種類型：阻塞式 I/O、非阻塞式 I/O、I/O 多路複用、信號驅動
I/O 和異步 I/O。
每種 I/O 模型都有各自典型的使用場景，好比 Java 中 Socket 對象的阻塞模式和非阻塞模式就對應於前兩種模型；

而 Linux 中的系統調用 select 函數就屬於 I/O
多路複用模型；大名鼎鼎的 epoll 系統調用則介於第三種和第四種模型之間；
至於第五種模
型，其實不多有 Linux 系統支持，反而是 Windows 系統提供了一個叫 IOCP 線程模型屬
於這一種。
你沒必要詳細瞭解每一種模型的實現細節，一般狀況下咱們認爲後一種模型會比前一種模型要
高級，好比 epoll 就比 select 要好，瞭解到這一程度應該足以應付咱們下面的內容了。

說了這麼多，I/O 模型與 Kafka 的關係又是什麼呢？**實際上 Kafka 客戶端底層使用了 Java
的 selector，selector 在 Linux 上的實現機制是 epoll，而在 Windows 平臺上的實現機制
I/O 模型的使用
數據網絡傳輸效率
社區支持度
是 select**。

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

網絡傳輸效率

其次是網絡傳輸效率的差異。你知道的，Kafka 生產和消費的消息都是經過網絡傳輸的，而消息保存在哪裏呢？確定是磁盤。

故 Kafka 須要在磁盤和網絡間進行大量數據傳輸。若是你熟悉 Linux，你確定聽過零拷貝（Zero Copy）技術，就**是當數據在磁盤和網絡進行傳輸
時避免昂貴的內核態數據拷貝從而實現快速地數據傳輸**。

Linux 平臺實現了這樣的零拷貝機制，但有些使人遺憾的是在 Windows 平臺上必需要等到 Java 8 的 60 更新版本才能「享
受」到這個福利。
一句話總結一下，**在 Linux 部署 Kafka 可以享受到零拷貝技術所帶來的
快速數據傳輸特性**。

社區支持度

最後是社區的支持度。這一點雖然不是什麼明顯的差異，但若是不瞭解的話可能比前兩個因
素對你的影響更大。簡單來講就是，**社區目前對 Windows 平臺上發現的 Kafka Bug 不作
任何承諾**。雖然口頭上依然保證盡力去解決，但根據個人經驗，Windows 上的 Bug 通常
是不會修復的。

**所以，Windows 平臺上部署 Kafka 只適合於我的測試或用於功能驗證，
千萬不要應用於生產環境。

磁盤

若是問哪一種資源對 Kafka 性能最重要，磁盤無疑是要排名靠前的。

在對 Kafka 集羣進行磁盤規劃時常常面對的問題是，我應該選擇普通的機械磁盤仍是固態硬盤？
前者成本低且容量大，但易損壞；後者性能優點大，不過單價高。我給出的建議是使用普通機械硬盤便可。

**Kafka 大量使用磁盤不假，可它使用的方式可能是順序讀寫操做，必定程度上規避了機械磁盤
最大的劣勢，即隨機讀寫操做慢**。

從這一點上來講，使用 SSD 彷佛並無太大的性能優點，畢竟從性價比上來講，機械磁盤物美價廉，而它因易損壞而形成的可靠性差等缺陷，又由 Kafka 在軟件層面提供機制來保證，故使用普通機械磁盤是很划算的。

關於磁盤選擇另外一個常常討論的話題就是到底是否應該使用磁盤陣列（RAID）。使用
RAID 的兩個主要優點在於：

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

以上兩個優點對於任何一個分佈式系統都頗有吸引力。

不過就 Kafka 而言，一方面 Kafka
本身實現了冗餘機制來提供高可靠性；另外一方面經過分區的概念，Kafka 也能在軟件層面自行實現負載均衡。

如此說來 RAID 的優點就沒有那麼明顯了。

固然，我並非說 RAID 很差，實際上依然有不少大廠確實是把 Kafka 底層的存儲交由 RAID 的，只是目前 Kafka 在
存儲這方面提供了愈來愈便捷的高可靠性方案，所以在線上環境使用 RAID 彷佛變得不是
那麼重要了。

綜合以上的考量，我給出的建議是：

• **追求性價比的公司能夠不搭建 RAID，使用普通磁盤組成存儲空間便可。

**

• 使用機械磁盤徹底可以勝任 Kafka 線上環境。

**

磁盤容量

Kafka 集羣到底須要多大的存儲空間？這是一個很是經典的規劃問題。

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。
總之在規劃磁盤容量時你須要考慮下面這幾個元素：

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

帶寬

帶寬對於 Kafka 這種經過網絡大量進行數據傳輸的框架而言，帶寬特別容易成爲瓶頸。

事實上，在我接觸的真實案例當中，帶寬資源不足致使 Kafka 出現性能問題的比例至少佔 60%
以上。

若是你的環境中還涉及跨機房傳輸，那麼狀況可能就更糟了。
若是你不是超級土豪的話，我會認爲你和我平時使用的都是普通的以太網絡，帶寬也主要有
兩種：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 環境而後過後費力調整，不如在
一開始就思考好實際場景下業務所需的集羣環境。在考量部署方案時須要通盤考慮，不能僅從單個維度上進行評估。相信今天咱們聊完以後，你對如何規劃 Kafka 生產環境必定有了
一個清晰的認識。