一.Kafka生產過程分析

1.寫入方式

producer採用push模式將訊息傳送到broker，每條訊息都被追加(append)到分割槽中，屬於順序寫磁碟(順序寫磁碟效率要比隨機寫記憶體要高，保障Kafka吞吐率)。

2.分割槽

訊息傳送時都被髮送到一個topic，其本質就是個目錄，而topic是由一些分割槽日誌組成

1）分割槽的原因

（1）方便在叢集中擴充套件，每個分割槽可以通過調整以適應它所在的機器，而一個topic又可以有多個分割槽組成，因此整個叢集就可以適應任意大小的資料了；

（2）可以提高併發，因為可以以分割槽為單位讀寫了。

2）分割槽的原則

（1）指定了分割槽，則直接使用；

（2）未指定分割槽但指定key，通過對key的value進行hash出一個分割槽；

（3）分割槽和key都未指定，使用輪詢選出一個分割槽。

3.副本

同一個分割槽可能會有多個副本(對應server.properties配置中的defalut.replication.factor=N)。沒有replication的情況下，一旦broker宕機，其上所有的分割槽資料都不可被消費，同時producer也不能再將資料存於其上的分割槽。引入副本之後，同一個分割槽可能會有多個副本(副本之間不能共存同一機器，否則副本沒有意義)，這時需要在這些副本之間選出一個leader，producer和consumer只與這個leader互動，其它副本作為follower從leader中複製資料。

4.寫入流程

二.Broker儲存訊息

1.儲存方式

物理上把topic分成一個或多個分割槽(對應server.properties中的num.patitions=3配置) ，每個分割槽物理上對應一個資料夾(該資料夾儲存該分割槽所有訊息和索引檔案)

 2.儲存策略

無論訊息是否被消費，Kafka都會保留所有訊息。有兩種策略可以刪除久資料：

1）基於時間：log.retention.hours=168

2）基於大小：log.retention.bytes=1073741824

需要注意的是，因為Kafka讀取特定訊息的時間複雜度為O(1)，即與檔案大小無關，所以這裡 刪除過期檔案與提高Kafka效能無關。

3.Zookeeper儲存結構

注意：

1）這裡我麼沒有指定組名，所以他會隨機生成一個組名 

2）producer不在zk中註冊，消費者在zk中註冊

三.Kafaka消費過程分析

Kafka提供了兩種consumerAPI。

１.高階API

１）高階API優點

寫起來簡單

不需要自己管理offsets，系統通過zookeeper自行管理

消費者斷線會自動根據上一次的offsets去接著獲取資料(預設設定1分鐘更新以下zookeeper中的offsets)

可以使用group來區分對於同一個topic的不同程序(不同的group記錄不同的offsets，這樣不同的程序才不會混淆offsets)

2）高階API缺點

不能自行控制offsets(對於某些需求)

不能細化控制分割槽副本zk等

２.低階API

1）低階API優點

能讓開發者自己控制offsets，像從哪裡讀取就從哪裡讀取

自行控制連線分割槽，對分割槽自定義進行負載均衡

對zookeeper的依賴性降低（如：offsets不一定分要靠zk來儲存，通過引數指定--bootstrap-server來使offsets儲存到kafka中）

2）低階API缺點

不好寫複雜繁瑣

3 .消費者組

消費者是以consumer group消費者組的方式工作，有一個或者多個消費者組成一個組，共同消費一個topic，每個分割槽在同一時間只能由group中的一個消費者讀取，但是多個group可以同時消費這個分割槽。在這種情況下，消費者可以通過水平擴充套件的方式讀取大量訊息。另外如果一個消費者失敗了，那麼其他group成員會自動負載均衡讀取之前失敗的消費則讀取的分割槽

4.消費方式

consumer採用pull(拉)模式從broker中讀取訊息

push模式很難適應消費速率不同的消費者，因為訊息傳送速率是由broker決定的。它的目標是儘可能以最快速度傳遞訊息，但是這樣很容易造成consumer來不及處理訊息，典型的表現就是拒絕服務以及網路阻塞，而pull模式則可以根據consumer的消費能力以適當的速率進行消費。

對於Kafka而言，pull模式跟適合，它可以簡化broker的設計，consumer可自主控制消費訊息的速率，同時consumer可以自己控制消費方式——批量或逐條，同時還能選擇不同的提交方式從而實現不同的傳輸語義。

pull模式不足之處在於如果Kafka沒有訊息，消費者可能會陷入迴圈中，一直等待訊息到達。為了避免這種情況，我們在pull中設定引數，允許消費者請求在等待訊息到達的長輪詢中進行阻塞。

5.消費者組案例

1）需求：測試同一個消費者組中的消費者，同一時間只能有一個消費則消費。

2）案例實操

     （1）在node1 node2上修改 /root/apps/kafka_2.11-0.11.0.2/config/consumer.properties 為任意組名如下

     （2）測試

       node3為生產者，node1和node2為消費者，我們可以看到同一時間只有一個消費者獲得了訊息，而在該消費者掛掉之後，           另一消費者會獲得訊息 。

       測試成功。

圖2來源：https://blog.csdn.net/lizhitao/article/details/23744675#commentBox