應大部分的小夥伴的要求，今天這篇我們們用大白話帶你認識 Kafka。

Kafka 基礎

訊息系統的作用

大部分小夥伴應該都清楚，這裡用機油裝箱舉個例子：

Kafka 優秀的架構設計！它的高效能是如何保證的？

所以訊息系統就是如上圖我們所說的倉庫，能在中間過程作為快取，並且實現解耦合的作用。

引入一個場景，我們知道中國移動，中國聯通，中國電信的日誌處理，是交給外包去做大資料分析的，假設現在它們的日誌都交給了你做的系統去做使用者畫像分析。

按照剛剛前面提到的訊息系統的作用，我們知道了訊息系統其實就是一個模擬快取，且僅僅是起到了快取的作用而並不是真正的快取，資料仍然是儲存在磁碟上面而不是記憶體。

Topic 主題

Kafka 學習了資料庫裡面的設計，在裡面設計了 Topic（主題），這個東西類似於關係型資料庫的表：

此時我需要獲取中國移動的資料，那就直接監聽 TopicA 即可。

Partition 分割槽

Kafka 還有一個概念叫 Partition（分割槽），分割槽具體在伺服器上面表現起初就是一個目錄。

一個主題下面有多個分割槽，這些分割槽會儲存到不同的伺服器上面，或者說，其實就是在不同的主機上建了不同的目錄。

這些分割槽主要的資訊就存在了 .log 檔案裡面。跟資料庫裡面的分割槽差不多，是為了提高效能。

至於為什麼提高了效能，很簡單，多個分割槽多個執行緒，多個執行緒並行處理肯定會比單執行緒好得多。

Topic 和 Partition 像是 HBase 裡的 Table 和 Region 的概念，Table 只是一個邏輯上的概念，真正儲存資料的是 Region。

這些 Region 會分散式地儲存在各個伺服器上面，對應於 Kafka，也是一樣，Topic 也是邏輯概念，而 Partition 就是分散式儲存單元。

這個設計是保證了海量資料處理的基礎。我們可以對比一下，如果 HDFS 沒有 Block 的設計，一個 100T 的檔案也只能單獨放在一個伺服器上面，那就直接佔滿整個伺服器了，引入 Block 後，大檔案可以分散儲存在不同的伺服器上。

注意：

分割槽會有單點故障問題，所以我們會為每個分割槽設定副本數。
分割槽的編號是從 0 開始的。

Producer 生產者

往訊息系統裡面傳送資料的就是生產者：

Consumer 消費者

從 Kafka 裡讀取資料的就是消費者：

Message 訊息

Kafka 裡面的我們處理的資料叫做訊息。

Kafka 的叢集架構

建立一個 TopicA 的主題，3 個分割槽分別儲存在不同的伺服器，也就是 Broker 下面。

Topic 是一個邏輯上的概念，並不能直接在圖中把 Topic 的相關單元畫出：

需要注意：Kafka 在 0.8 版本以前是沒有副本機制的，所以在面對伺服器當機的突發情況時會丟失資料，所以儘量避免使用這個版本之前的 Kafka。

Replica 副本

Kafka 中的 Partition 為了保證資料安全，所以每個 Partition 可以設定多個副本。

此時我們對分割槽 0，1，2 分別設定 3 個副本（其實設定兩個副本是比較合適的）：

而且其實每個副本都是有角色之分的，它們會選取一個副本作為 Leader，而其餘的作為 Follower。

我們的生產者在傳送資料的時候，是直接傳送到 Leader Partition 裡面，然後 Follower Partition 會去 Leader 那裡自行同步資料，消費者消費資料的時候，也是從 Leader 那去消費資料的。

Consumer Group 消費者組

我們在消費資料時會在程式碼裡面指定一個 group.id，這個 id 代表的是消費組的名字，而且這個 group.id 就算不設定，系統也會預設設定：

conf.setProperty("group.id","tellYourDream")

我們所熟知的一些訊息系統一般來說會這樣設計，就是隻要有一個消費者去消費了訊息系統裡面的資料，那麼其餘所有的消費者都不能再去消費這個資料。

可是 Kafka 並不是這樣，比如現在 ConsumerA 去消費了一個 TopicA 裡面的資料：

consumerA:
    group.id = a
consumerB:
    group.id = a

consumerC:
    group.id = b
consumerD:
    group.id = b

再讓 ConsumerB 也去消費 TopicA 的資料，它是消費不到了，但是我們在 ConsumerC 中重新指定一個另外的 group.id，ConsumerC 是可以消費到 TopicA 的資料的。

而 ConsumerD 也是消費不到的，所以在 Kafka 中，不同組可有唯一的一個消費者去消費同一主題的資料。

所以消費者組就是讓多個消費者並行消費資訊而存在的，而且它們不會消費到同一個訊息

如下，ConsumerA，B，C 是不會互相干擾的：

consumer group:a
    consumerA
    consumerB
    consumerC

如圖，因為前面提到過了消費者會直接和 Leader 建立聯絡，所以它們分別消費了三個 Leader，所以一個分割槽不會讓消費者組裡面的多個消費者去消費，但是在消費者不飽和的情況下，一個消費者是可以去消費多個分割槽的資料的。

Controller

熟知一個規律：在大資料分散式檔案系統裡面，95% 的都是主從式的架構，個別是對等式的架構，比如 ElasticSearch。

Kafka 也是主從式的架構，主節點就叫 Controller，其餘的為從節點，Controller 是需要和 Zookeeper 進行配合管理整個 Kafka 叢集。

Kafka 和 Zookeeper 如何配合工作

Kafka 嚴重依賴於 Zookeeper 叢集，所有的 Broker 在啟動的時候都會往 Zookeeper 進行註冊，目的就是選舉出一個 Controller。

這個選舉過程非常簡單粗暴，就是一個誰先誰當的過程，不涉及什麼演算法問題。

那成為 Controller 之後要做啥呢，它會監聽 Zookeeper 裡面的多個目錄，例如有一個目錄 /brokers/，其他從節點往這個目錄上**註冊（就是往這個目錄上建立屬於自己的子目錄而已）**自己。

這時命名規則一般是它們的 id 編號，比如 /brokers/0,1,2。註冊時各個節點必定會暴露自己的主機名，埠號等等的資訊。

此時 Controller 就要去讀取註冊上來的從節點的資料（透過監聽機制），生成叢集的後設資料資訊，之後把這些資訊都分發給其他的伺服器，讓其他伺服器能感知到叢集中其它成員的存在。

此時模擬一個場景，我們建立一個主題（其實就是在 Zookeeper 上 /topics/topicA 這樣建立一個目錄而已），Kafka 會把分割槽方案生成在這個目錄中。

此時 Controller 就監聽到了這一改變，它會去同步這個目錄的元資訊，然後同樣下放給它的從節點，透過這個方法讓整個叢集都得知這個分割槽方案，此時從節點就各自建立好目錄等待建立分割槽副本即可。這也是整個叢集的管理機制。

加餐時間

Kafka 效能好在什麼地方？

①順序寫

作業系統每次從磁碟讀寫資料的時候，需要先定址，也就是先要找到資料在磁碟上的物理位置，然後再進行資料讀寫，如果是機械硬碟，定址就需要較長的時間。

Kafka 的設計中，資料其實是儲存在磁碟上面，一般來說，會把資料儲存在記憶體上面效能才會好。

但是 Kafka 用的是順序寫，追加資料是追加到末尾，磁碟順序寫的效能極高，在磁碟個數一定，轉數達到一定的情況下，基本和記憶體速度一致。

隨機寫的話是在檔案的某個位置修改資料，效能會較低。

②零複製

先來看看非零複製的情況：

可以看到資料的複製從記憶體複製到 Kafka 服務程式那塊，又複製到 Socket 快取那塊，整個過程耗費的時間比較高。

Kafka 利用了 Linux 的 sendFile 技術（NIO），省去了程式切換和一次資料複製，讓效能變得更好。

日誌分段儲存

Kafka 規定了一個分割槽內的 .log 檔案最大為 1G，做這個限制目的是為了方便把 .log 載入到記憶體去操作：

00000000000000000000.index
00000000000000000000.log
00000000000000000000.timeindex

00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex

00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex

這個 9936472 之類的數字，就是代表了這個日誌段檔案裡包含的起始 Offset，也就說明這個分割槽裡至少都寫入了接近 1000 萬條資料了。

Kafka Broker 有一個引數，log.segment.bytes，限定了每個日誌段檔案的大小，最大就是 1GB。

一個日誌段檔案滿了，就自動開一個新的日誌段檔案來寫入，避免單個檔案過大，影響檔案的讀寫效能，這個過程叫做 log rolling，正在被寫入的那個日誌段檔案，叫做 active log segment。

如果大家有了解 HDFS 就會發現 NameNode 的 edits log 也會做出限制，所以這些框架都是會考慮到這些問題。

Kafka 的網路設計

Kafka 的網路設計和 Kafka 的調優有關，這也是為什麼它能支援高併發的原因：

Kafka 優秀的架構設計！它的高效能是如何保證的？

首先客戶端傳送請求全部會先傳送給一個 Acceptor，Broker 裡面會存在 3 個執行緒（預設是 3 個）。

這 3 個執行緒都是叫做 Processor，Acceptor 不會對客戶端的請求做任何的處理，直接封裝成一個個 socketChannel 傳送給這些 Processor 形成一個佇列。

傳送的方式是輪詢，就是先給第一個 Processor 傳送，然後再給第二個，第三個，然後又回到第一個。

消費者執行緒去消費這些 socketChannel 時，會獲取一個個 Request 請求，這些 Request 請求中就會伴隨著資料。

執行緒池裡面預設有 8 個執行緒，這些執行緒是用來處理 Request 的，解析請求，如果 Request 是寫請求，就寫到磁碟裡。讀的話返回結果。

Processor 會從 Response 中讀取響應資料，然後再返回給客戶端。這就是 Kafka 的網路三層架構。

所以如果我們需要對 Kafka 進行增強調優，增加 Processor 並增加執行緒池裡面的處理執行緒，就可以達到效果。

Request 和 Response 那一塊部分其實就是起到了一個快取的效果，是考慮到 Processor 們生成請求太快，執行緒數不夠不能及時處理的問題。

所以這就是一個加強版的 Reactor 網路執行緒模型。

總結

叢集的搭建會再找時間去提及。這一篇簡單地從角色到一些設計的方面講述了 Kafka 的一些基礎，在之後的更新中會繼續逐步推進，進行更加深入淺出的講解。

出處：

Kafka 優秀的架構設計！它的高效能是如何保證的？

①順序寫

②零複製

相關文章