應大部分的小夥伴的要求，今天這篇咱們用大白話帶你認識 Kafka。
圖片來自 Pexels
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.index00000000000000000000.log00000000000000000000.timeindex00000000000005367851.index00000000000005367851.log00000000000005367851.timeindex00000000000009936472.index00000000000009936472.log00000000000009936472.timeindex
這個 9936472 之類的數字，就是代表了這個日誌段文件裡包含的起始 Offset，也就說明這個分區裡至少都寫入了接近 1000 萬條數據了。
Kafka Broker 有一個參數，log.segment.bytes，限定了每個日誌段文件的大小，最大就是 1GB。
一個日誌段文件滿了，就自動開一個新的日誌段文件來寫入，避免單個文件過大，影響文件的讀寫性能，這個過程叫做 log rolling，正在被寫入的那個日誌段文件，叫做 active log segment。
如果大家有了解 HDFS 就會發現 NameNode 的 edits log 也會做出限制，所以這些框架都是會考慮到這些問題。
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 的一些基礎，在之後的更新中會繼續逐步推進，進行更加深入淺出的講解。
閱讀更多 51CTO 的文章
