為什麼需要消息隊列
周末無聊刷着手機，某寶網APP突然蹦出來一條消息“為了回饋老客戶，女朋友買一送一，活動僅限今天！”。買一送一還有這種好事，那我可不能錯過！忍不住立馬點了去。于是選了兩個最新款，下單、支付一氣呵成！滿足的躺在床上，想着馬上有女朋友了，竟然幸福的失眠了……
第二天正常上着班，突然接到快遞小哥的電話：
小哥：“你是xx嗎？你的女朋友到了，我現在在你樓下，你來拿一下吧！”。
我：“這……我在上班呢，可以晚上送過來嗎？“。
小哥：“晚上可不行哦，晚上我也下班了呢！”。
于是兩個人僵持了很久……
最後小哥說，要不我幫你放到樓下小芳便利店吧，你晚上下班了過來拿，尴尬的局面這才得以緩解！
回到正題，如果沒有小芳便利店，那快遞小哥和我的互動圖就應該如下：
會出現什麼情況呢？
1、為了這個女朋友，我請假回去拿（老闆不批）。
2、小哥一直在你樓下等（小哥還有其他的快遞要送）。
3、周末再送（顯然等不及）。
4、這個女朋友我不要了（絕對不可能）！
小芳便利店出現後，互動圖就應如下：
在上面例子中，“快遞小哥”和“買女朋友的我”就是需要互動的兩個系統，小芳便利店就是我們本文要講的-“消息中間件”。總結下來小芳便利店（消息中間件）出現後有如下好處：
1、 解耦
快遞小哥手上有很多快遞需要送，他每次都需要先電話一一确認收貨人是否有空、哪個時間段有空，然後再确定好送貨的方案。這樣完全依賴收貨人了！如果快遞一多，快遞小哥估計的忙瘋了……如果有了便利店，快遞小哥隻需要将同一個小區的快遞放在同一個便利店，然後通知收貨人來取貨就可以了，這時候快遞小哥和收貨人就實作了解耦！
2、 異步
快遞小哥打電話給我後需要一直在你樓下等着，直到我拿走你的快遞他才能去送其他人的。快遞小哥将快遞放在小芳便利店後，又可以幹其他的活兒去了，不需要等待你到來而一直處于等待狀态。提高了工作的效率。
3、 削峰
假設雙十一我買了不同店裡的各種商品，而恰巧這些店發貨的快遞都不一樣，有中通、圓通、申通、各種通等……更巧的是他們都同時到貨了！中通的小哥打來電話叫我去北門取快遞、圓通小哥叫我去南門、申通小哥叫我去東門。我一時手忙腳亂……
我們能看到在系統需要互動的場景中，使用消息隊列中間件真的是好處多多，基于這種思路，就有了豐巢、菜鳥驿站等比小芳便利店更專業的“中間件”了。
最後，上面的故事純屬虛構……
消息隊列通信的模式
通過上面的例子我們引出了消息中間件，并且介紹了消息隊列出現後的好處，這裡就需要介紹消息隊列通信的兩種模式了：
一、 點對點模式
如上圖所示，點對點模式通常是基于拉取或者輪詢的消息傳送模型，這個模型的特點是發送到隊列的消息被一個且隻有一個消費者進行處理。生産者将消息放入消息隊列後，由消費者主動的去拉取消息進行消費。點對點模型的的優點是消費者拉取消息的頻率可以由自己控制。但是消息隊列是否有消息需要消費，在消費者端無法感覺，是以在消費者端需要額外的線程去監控。
二、 釋出訂閱模式
如上圖所示，釋出訂閱模式是一個基于消息送的消息傳送模型，改模型可以有多種不同的訂閱者。生産者将消息放入消息隊列後，隊列會将消息推送給訂閱過該類消息的消費者（類似微信公衆号）。由于是消費者被動接收推送，是以無需感覺消息隊列是否有待消費的消息！但是consumer1、consumer2、consumer3由于機器性能不一樣，是以處理消息的能力也會不一樣，但消息隊列卻無法感覺消費者消費的速度！是以推送的速度成了釋出訂閱模模式的一個問題！假設三個消費者處理速度分别是8M/s、5M/s、2M/s，如果隊列推送的速度為5M/s，則consumer3無法承受！如果隊列推送的速度為2M/s，則consumer1、consumer2會出現資源的極大浪費！
Kafka
上面簡單的介紹了為什麼需要消息隊列以及消息隊列通信的兩種模式，接下來就到了我們本文的主角——kafka閃亮登場的時候了！Kafka是一種高吞吐量的分布式釋出訂閱消息系統，它可以處理消費者規模的網站中的所有動作流資料，具有高性能、持久化、多副本備份、橫向擴充能力……… 一些基本的介紹這裡就不展開了，網上有太多關于這些的介紹了，讀者可以自行百度一下！
基礎架構及術語
話不多說，先看圖，通過這張圖我們來捋一捋相關的概念及之間的關系：
如果看到這張圖你很懵逼，木有關系！我們先來分析相關概念
Producer：Producer即生産者，消息的産生者，是消息的入口。
kafka cluster：
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來儲存叢集的的元資訊，來保證系統的可用性。
工作流程分析
上面介紹了kafka的基礎架構及基本概念，不知道大家看完有沒有對kafka有個大緻印象，如果對還比較懵也沒關系！我們接下來再結合上面的結構圖分析kafka的工作流程，最後再回來整個梳理一遍我相信你會更有收獲！
發送資料
我們看上面的架構圖中，producer就是生産者，是資料的入口。注意看圖中的紅色箭頭，Producer在寫入資料的時候永遠的找leader，不會直接将資料寫入follower！那leader怎麼找呢？寫入的流程又是什麼樣的呢？我們看下圖：
發送的流程就在圖中已經說明了，就不單獨在文字列出來了！需要注意的一點是，消息寫入leader後，follower是主動的去leader進行同步的！producer采用push模式将資料釋出到broker，每條消息追加到分區中，順序寫入磁盤，是以保證同一分區内的資料是有序的！寫入示意圖如下：
上面說到資料會寫入到不同的分區，那kafka為什麼要做分區呢？相信大家應該也能猜到，分區的主要目的是：
1、 友善擴充。因為一個topic可以有多個partition，是以我們可以通過擴充機器去輕松的應對日益增長的資料量。
2、 提高并發。以partition為讀寫機關，可以多個消費者同時消費資料，提高了消息的處理效率。
熟悉負載均衡的朋友應該知道，當我們向某個伺服器發送請求的時候，服務端可能會對請求做一個負載，将流量分發到不同的伺服器，那在kafka中，如果某個topic有多個partition，producer又怎麼知道該将資料發往哪個partition呢？kafka中有幾個原則：
1、 partition在寫入的時候可以指定需要寫入的partition，如果有指定，則寫入對應的partition。
2、 如果沒有指定partition，但是設定了資料的key，則會根據key的值hash出一個partition。
3、 如果既沒指定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比較抽象，那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号，它可以唯一确定每條消息在parition内的位置！
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中！