前言
kafka是一種高吞吐量的分佈式發佈訂閱消息系統，它可以處理消費者規模中的網站中的所有動作流數據，具有高性能、持久化、多副本備份、橫向擴展能力等等。
基礎架構及術語
話不多說，先看圖，通過這張圖我們來捋一捋相關的概念及之間的關係：
名詞解釋
Producer:即生產者，消息的產生者，是消息的入口。
Broker:Broker是kafka實例，每個服務器上有一個或多個kafka的實例，我們姑且認爲每個broker對應一臺服務器。每個kafka集羣內的broker都有一個不重複的編號，如圖中的broker-0、broker-1等…
Topic：消費的主題，可以理解爲消息的分類，kafka的數據就保存在topic。在每個broker上都可以創建多個topic。
Partition:topic的分區，每個topic可以有多個分區，分區的作用是做負載，提高kafka的吞吐量。同一個topic在不同的分區的數據是不重複的。partition的表現形式就是一個一個的文件夾！
Replication:每個分區都有多個副本，副本的作用是做備胎。當主分區（Leader）故障的時候會選擇一個備胎（Follower）上位，成爲leader。在kafka中默認副本的最大數量是10個，且副本的數量不能大於Broker的數量，follower和leader絕對是在不同的機器，同一機器對同一分區也只可能存在一個副本（包括自己）。
Message:每一條發送的消息主體。
Consumer:消費者，即消息的消費方，是消息的出口。
Consumer Group:我們可以將多個消費組組成一個消費者組，在kafka的設計中同一個分區的數據只能被消費者組中的某一個消費者消費。同一個消費者組的消費者可以消費同一個topic的不同分區的數據，這也是爲了提高kafka的吞吐量！
Zookeeper:kafka集羣依賴zookeeper來保存集羣的元信息，來保證系統的可用性。
工作流程分析
發送數據
我們看上面的架構圖中，producer就是生產者，是數據的入口。注意看圖中的紅色箭頭，Producer在寫入數據的時候永遠的找leader,不會直接將數據寫入follower!那leader怎麼找呢？寫入的流程又是怎麼樣的呢？我們看下圖
發送的流程如上圖。其中需要注意的一點就是，消息寫入leader後，follower是主動的去leader進行同步的！producer採用push模式將數據發佈到broker，每條消息追加到分區中，順序寫入磁盤，所以保證同一分區內的數據是有序的!寫入示意圖如下：
上面說到數據會寫入到不同的分區，那kafka爲什麼要做分區呢？其實分區的主要目的是：
1、方便擴展。因爲一個topic可以有多個partition，所以我們可以通過擴展機器去輕鬆的應對日益增長的數據量。
2、提高併發。以partition爲讀寫單位，可以多個消費者同時消費數據，提高了消息的處理效率。
熟悉負載均衡的應該知道，當我們向某個服務器發送請求的時候，服務端可能會對請求做一個負載，將流量分發到不同的服務器，那在kafka中，如果某個topic有多個partition，producer又怎麼知道該將數據發往哪個partition呢？其實kafka中有幾個原則：
a、partition在寫入的時候可以指定需要寫入的partition，如果有指定，則寫入對應的partition。
b、如果沒有指定partition，但是設置了數據的key，則會根據key的值hash出一個partition
c、如果既沒有指定partition又沒有設置key，則會輪詢出一個partition。
保證消息不丟失是一個消息隊列中間件的基本保證，那producer在向kafka寫入消息的時候，怎麼保證消息不丟失呢？實際上上面的寫入流程中有描述，其實就是通過ACK應答機制！在生產者向隊列寫入數據的售後可以設置參數來確定kafka接收到數據，這個參數可設置的值爲0、1、all。
0 代表producer往集羣發送數據不需要等到集羣的返回，不確保消息發送成功。安全性最低但是效率最高。
1 代表producer往集羣發送數據只要leader應答就可以發送下一條，之 確保leader發送成功。
all 代表producer往集羣發送數據需要所有的follower都完成從 leader 的同步纔會發送下一條，確保leader發送成功和所有的副本都完成備份。安全性最高，但是效率最低
最後要注意的是，如果往不存在的topic寫數據，能不能寫入成功呢？kafka會自動創建topic，分區和副本的數量根據默認配置都是1.
保存數據
producer將數據寫入kafka後，集羣就需要對數據進行保存了！kafka將數據保存在磁盤，可能在我們的一般的認知裏，寫入磁盤是比較耗時的操作，不適合這種高併發的組件。kafka初始會單獨開闢一塊磁盤空間，順序寫入數據（效率比隨機寫入高）。
partition結構 前面說過了每個topic都可以分爲一個或多個partition，如果你覺得topic都可以分爲一個或多個partit，如果你覺得topic比較抽象，那partition就是比較具體的東西了！Partition在服務器上的表現形式就是一個一個的文件夾，每個partition的文件夾下面會有多組segment文件，每組segment文件又包含.index文件、.log文件、.timeindex文件（早期版本中沒有）三個文件， log文件就實際是存儲message的地方，而index和timeindex文件爲索引文件，用於檢索消息。
如上圖，這個partition有三組segment文件，每個log文件的大小是一樣的，但是存儲的message數量是不一定相等的（每條message的大小不一致）。文件的命名是該segment最小offset來命名的，如000.index存儲offset爲0~368795的消息，kafka就是利用分段+索引的方式來解決查找效率的問題
Message結構 上面說到log文件就實際是存儲message的地方，我們在producer往kafka寫入的也是一條一條的message，那麼存儲在log中的message是什麼樣子的呢？消息主要包含消息體、消息大小、offset、壓縮類型等等。我們重點需要知道的是下面三個：
1、offset：offset是一個佔8byte的有序ID號，它可以唯一確定每條消息在partition內的位置
2、消息大小：消息大小佔用4byte，用於描述消息的大小。
3、消息體：消息體存放的是實際的消息數據（被壓縮過），佔用的空間根據具體的消息而不一樣。
存儲策略：無論消息是否被消費，kafka都會保存所有的消息、那麼對弈舊數據有什麼刪除策略呢？
1、基於時間，默認配置是168小時（7天）
2、基於大小，默然配置是1073741824.
需要注意的是，kafka讀取待定消息的時間複雜度是O(1)，所以這裏刪除過期的文件並不會提高kafka的性能
消費數據
下剖析存儲在log文件後，消費者就可以進行消費了。在消息隊列通信的兩種模式是點對點模式和發佈訂閱模式。kafka採用的是點對點的模式，消費者主動的去kafka集羣拉取消息，與producer相同的是，消費者在拉取消息的時候也是在找leader去拉取。
多個消費者可以組成一個消費者組（consumer group）,每個消費者組都有一個組ID！同一個消費組者的消費者可以消費同一topic下不同分區的數據，但是不會組內多個消費者消費同一分區的數據。如下圖所示：
圖示是消費者組內的消費者小於partition數量的情況，所以會出現某個消費者消費多個partition數據的情況，消費的速度也就不及只處理一個partition的消費者的處理速度！如果是消費者組的消費者多於partition的數量，那會不會出現多個消費者消費同一個partition的數據呢？上面已經提到過不會出現這種情況！多出來的消費者不消費任何partition的數據。所以在實際的應用中，建議消費者組的consumer的數量與partition的數量一致！
在保存數據的小節裏面，我們聊到了partition劃分爲多組segment，每個segment又包含.log、.index、.timeindex文件，存放的每條message包含offset、消息大小、消息體……我們多次提到segment和offset，查找消息的時候是怎麼利用segment+offset配合查找的呢？假如現在需要查找一個offset爲368801的message是什麼樣的過程呢？我們先看看下面的圖：
1、 先找到offset的368801message所在的segment文件（利用二分法查找），這裏找到的就是在第二個segment文件。
2、 打開找到的segment中的.index文件（也就是368796.index文件，該文件起始偏移量爲368796+1，我們要查找的offset爲368801的message在該index內的偏移量爲368796+5=368801，所以這裏要查找的相對offset爲5）。由於該文件採用的是稀疏索引的方式存儲着相對offset及對應message物理偏移量的關係，所以直接找相對offset爲5的索引找不到，這裏同樣利用二分法查找相對offset小於或者等於指定的相對offset的索引條目中最大的那個相對offset，所以找到的是相對offset爲4的這個索引。
3、 根據找到的相對offset爲4的索引確定message存儲的物理偏移位置爲256。打開數據文件，從位置爲256的那個地方開始順序掃描直到找到offset爲368801的那條Message。
這套機制是建立在offset爲有序的基礎上，利用segment+有序offset+稀疏索引+二分查找+順序查找等多種手段來高效的查找數據！至此，消費者就能拿到需要處理的數據進行處理了。那每個消費者又是怎麼記錄自己消費的位置呢？在早期的版本中，消費者將消費到的offset維護zookeeper中，consumer每間隔一段時間上報一次，這裏容易導致重複消費，且性能不好！在新的版本中消費者消費到的offset已經直接維護在kafk集羣的__consumer_offsets這個topic中！