本文在個人技術部落格不同步釋出，詳情可猛戳
亦可掃描螢幕右側二維碼關注個人公眾號，公眾號內有個人聯絡方式，等你來撩...

為什麼需要訊息佇列

　　週末無聊刷著手機，某寶網APP突然蹦出來一條訊息“為了回饋老客戶，女朋友買一送一，活動僅限今天！”。買一送一還有這種好事，那我可不能錯過！忍不住立馬點了去。於是選了兩個最新款，下單、支付一氣呵成！滿足的躺在床上，想著馬上有女朋友了，竟然幸福的失眠了……
　　第二天正常上著班，突然接到快遞小哥的電話：
　　小哥：“你是xx嗎？你的女朋友到了，我現在在你樓下，你來拿一下吧！”。
　　我：“這……我在上班呢，可以晚上送過來嗎？“。
　　小哥：“晚上可不行哦，晚上我也下班了呢！”。

　　回到正題，如果沒有小芳便利店，那快遞小哥和我的互動圖就應該如下：
　　
　　

　　會出現什麼情況呢？
　　1、為了這個女朋友，我請假回去拿（老闆不批）。
　　2、小哥一直在你樓下等（小哥還有其他的快遞要送）。
　　3、週末再送（顯然等不及）。
　　4、這個女朋友我不要了（絕對不可能）！

　　小芳便利店出現後，互動圖就應如下：
　　
　　

　　在上面例子中，“快遞小哥”和“買女朋友的我”就是需要互動的兩個系統，小芳便利店就是我們本文要講的-“訊息中介軟體”。總結下來小芳便利店（訊息中介軟體）出現後有如下好處：

　　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中！