消息中間件：解耦抢呆、異步睦尽、削峰
消息隊列通信的兩種模式：
? ? 一铁材、點對點模式：
如上圖所示宇攻，點對點模式通常是基于拉取或者輪詢的消息傳送模型惫叛，這個模型的特點是發(fā)送到隊列的消息被一個且只有一個消費者進行處理。
生產(chǎn)者將消息放入消息隊列后逞刷，由消費者主動的去拉取消息進行消費嘉涌。
點對點模型的的優(yōu)點是消費者拉取消息的頻率可以由自己控制。但是消息隊列是否有消息需要消費夸浅，在消費者端無法感知仑最，所以在消費者端需要額外的線程去監(jiān)控。
? ? 二帆喇、發(fā)布訂閱模式
如上圖所示警医，發(fā)布訂閱模式是一個基于消息推送的消息傳送模型，該模型可以有多種不同的訂閱者。
生產(chǎn)者將消息放入消息隊列后预皇，隊列會將消息推送給訂閱過該類消息的消費者（類似微信公眾號）侈玄。
由于是消費者被動接收推送，所以無需感知消息隊列是否有待消費的消息吟温！
但是consumer1序仙、consumer2、consumer3由于機器性能不一樣溯街，所以處理消息的能力也會不一樣诱桂，可是消息隊列卻無法感知消費者消費的速度！所以推送的速度成了發(fā)布訂閱模模式的一個問題呈昔！假設三個消費者處理速度分別是8M/s、5M/s友绝、2M/s堤尾，如果隊列推送的速度為5M/s，則consumer3無法承受迁客！如果隊列推送的速度為2M/s郭宝，則consumer1、consumer2會出現(xiàn)資源的極大浪費掷漱！
kafka：是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)粘室。
基礎(chǔ)架構(gòu)及其術(shù)語：
Producer：即生產(chǎn)者，消息的產(chǎn)生者卜范，是消息的入口衔统。
Kafka Cluster：
Broker：是kafka實例。每個服務器上有一個或多個kafka的實例海雪，我們姑且認為每個broker對應一臺服務器锦爵。每個kafka集群內(nèi)的broker都有一個不重復的編號，如圖中的broker-0奥裸、broker-1等……
Topic：消息的主題险掀，可以理解為消息的分類，kafka的數(shù)據(jù)就保存在topic湾宙。在每個broker上都可以創(chuàng)建多個topic樟氢。
Partition：Topic的分區(qū)，每個topic可以有多個分區(qū)侠鳄，分區(qū)的作用是做負載埠啃，提高kafka的吞吐量。同一個topic在不同的分區(qū)的數(shù)據(jù)是不重復的畦攘，partition的表現(xiàn)形式就是一個一個的文件夾霸妹！
Replication:每一個分區(qū)都有多個副本，副本的作用是做備胎知押。當主分區(qū)（Leader）故障的時候會選擇一個備胎（Follower）上位叹螟，成為Leader鹃骂。在kafka中默認副本的最大數(shù)量是10個，且副本的數(shù)量不能大于Broker的數(shù)量罢绽，follower和leader絕對是在不同的機器畏线，同一機器對同一個分區(qū)也只可能存放一個副本（包括自己）。
Message：每一條發(fā)送的消息主體良价。
Consumer：消費者寝殴，即消息的消費方，是消息的出口明垢。
??????????Consumer Group：我們可以將多個消費者組成一個消費者組蚣常，在kafka的設計中同一個分區(qū)的數(shù)據(jù)只能被消費者組中的某一個消費者消費。同一個消費者組的消費者可以消費同一個topic的不同分區(qū)的數(shù)據(jù)痊银，這也是為了提高kafka的吞吐量抵蚊！
Zookeeper：kafka集群依賴zookeeper來保存集群的的元信息，來保證系統(tǒng)的可用性溯革。
工作流程分析：
? ? ? ? ? ? 一贞绳、發(fā)送數(shù)據(jù)：我們看上面的架構(gòu)圖中蹋半，producer就是生產(chǎn)者垮衷，是數(shù)據(jù)的入口。注意看圖中的紅色箭頭册招，Producer在寫入數(shù)據(jù)的時候永遠的找leader抖单，不會直接將數(shù)據(jù)寫入follower萎攒！那leader怎么找呢？寫入的流程又是什么樣的呢臭猜？我們看下圖：
需要注意的一點是躺酒，消息寫入leader后，follower是主動的去leader進行同步的蔑歌！
producer采用push模式將數(shù)據(jù)發(fā)布到broker羹应，每條消息追加到分區(qū)中，順序?qū)懭氪疟P次屠，所以保證同一分區(qū)內(nèi)的數(shù)據(jù)是有序的园匹！寫入示意圖如下：
上面說到數(shù)據(jù)會寫入到不同的分區(qū)，那kafka為什么要做分區(qū)呢劫灶？相信大家應該也能猜到裸违，分區(qū)的主要目的是：
1、 方便擴展本昏。因為一個topic可以有多個partition供汛，所以我們可以通過擴展機器去輕松的應對日益增長的數(shù)據(jù)量。
2、 提高并發(fā)怔昨。以partition為讀寫單位雀久，可以多個消費者同時消費數(shù)據(jù)，提高了消息的處理效率趁舀。
熟悉負載均衡的朋友應該知道赖捌，當我們向某個服務器發(fā)送請求的時候，服務端可能會對請求做一個負載矮烹，將流量分發(fā)到不同的服務器越庇，那在kafka中，如果某個topic有多個partition奉狈，producer又怎么知道該將數(shù)據(jù)發(fā)往哪個partition呢卤唉？
kafka中有幾個原則：
1、 partition在寫入的時候可以指定需要寫入的partition仁期，如果有指定搬味，則寫入對應的partition。
2蟀拷、 如果沒有指定partition，但是設置了數(shù)據(jù)的key萍聊，則會根據(jù)key的值hash出一個partition问芬。
3、 如果既沒指定partition寿桨，又沒有設置key此衅，則會輪詢選出一個partition。
保證消息不丟失是一個消息隊列中間件的基本保證亭螟，那producer在向kafka寫入消息的時候挡鞍，怎么保證消息不丟失呢？
其實上面的寫入流程圖中有描述出來预烙，那就是通過?ACK應答機制?墨微！ 在生產(chǎn)者向隊列寫入數(shù)據(jù)的時候可以設置參數(shù)來確定是否確認kafka接收到數(shù)據(jù)， 這個參數(shù)可設置的值為? ?0扁掸、1翘县、all。
? ? ? 0代表producer往集群發(fā)送數(shù)據(jù)不需要等到集群的返回谴分，不確保消息發(fā)送成功锈麸。安全性最低但是效率最高。
? ? ? 1代表producer往集群發(fā)送數(shù)據(jù)只要leader應答就可以發(fā)送下一條牺蹄，只確保leader發(fā)送成功忘伞。
? ? ? all代表producer往集群發(fā)送數(shù)據(jù)需要所有的follower都完成從leader的同步才會發(fā)送下一條，確保leader發(fā)送成功和所有的副本都完成備份。安全性最高氓奈，但是效率最低翘魄。
最后要注意的是，如果往不存在的topic寫數(shù)據(jù)探颈，能不能寫入成功呢熟丸？kafka會自動創(chuàng)建topic，分區(qū)和副本的數(shù)量根據(jù)默認配置都是1伪节。
??????? ? ? 二光羞、保存數(shù)據(jù)：Producer將數(shù)據(jù)寫入kafka后，集群就需要對數(shù)據(jù)進行保存了怀大。kafka將數(shù)據(jù)保存在磁盤纱兑，可能在我們的一般的認知里，寫入磁盤是比較耗時的操作化借，不適合這種高并發(fā)的組件潜慎。Kafka初始會單獨開辟一塊磁盤空間，順序?qū)懭霐?shù)據(jù)（效率比隨機寫入高）蓖康。
Partition 結(jié)構(gòu)：前面說過了每個topic都可以分為一個或多個partition铐炫，如果你覺得topic比較抽象，那partition就是比較具體的東西了蒜焊！
Partition在服務器上的表現(xiàn)形式就是一個一個的文件夾倒信，每個partition的文件夾下面會有多組segment文件，每組segment文件又包含.index文件泳梆、.log文件鳖悠、.timeindex文件（早期版本中沒有）三個文件， log文件就實際是存儲message的地方优妙，而index和timeindex文件為索引文件乘综，用于檢索消息。
????如上圖套硼，這個partition有三組segment文件卡辰，每個log文件的大小是一樣的，但是存儲的message數(shù)量是不一定相等的（每條的message大小不一致）熟菲。文件的命名是以該segment最小offset來命名的看政，如000.index存儲offset為0~368795的消息，kafka就是利用分段+索引的方式來解決查找效率的問題抄罕。
Message結(jié)構(gòu)：上面說到log文件就實際是存儲message的地方允蚣，我們在producer往kafka寫入的也是一條一條的message，那存儲在log中的message是什么樣子的呢呆贿？
消息主要包含消息體嚷兔、消息大小森渐、offset、壓縮類型……等等冒晰！我們重點需要知道的是下面三個：
1同衣、 offset：offset是一個占8byte的有序id號，它可以唯一確定每條消息在parition內(nèi)的位置壶运！
2耐齐、 消息大小：消息大小占用4byte蒋情，用于描述消息的大小埠况。
3、 消息體：消息體存放的是實際的消息數(shù)據(jù)（被壓縮過）棵癣，占用的空間根據(jù)具體的消息而不一樣辕翰。
存儲策略：無論消息是否被消費，kafka都會保存所有的消息狈谊。那對于舊數(shù)據(jù)有什么刪除策略呢喜命？
1、 基于時間河劝，默認配置是168小時（7天）壁榕。
2、 基于大小赎瞎，默認配置是1073741824护桦。
需要注意的是，kafka讀取特定消息的時間復雜度是O(1)煎娇，所以這里刪除過期文件并不會提高kafka的性能！
? ? ? ? ? ? 三贪染、消費數(shù)據(jù)：消息存儲在log文件后缓呛，消費者就可以進行消費了。
????????與生產(chǎn)消息相同的是杭隙，消費者在拉取消息的時候也是找leader去拉取哟绊。
多個消費者可以組成一個消費者組（consumer group），每個消費者組都有一個組id痰憎！同一個消費組者的消費者可以消費同一topic下不同分區(qū)的數(shù)據(jù)票髓，但是不會組內(nèi)多個消費者消費同一分區(qū)的數(shù)據(jù)！Ｏ吃拧洽沟！是不是有點繞。我們看下圖：
圖示是消費者組內(nèi)的消費者小于partition數(shù)量的情況蜗细，所以會出現(xiàn)某個消費者消費多個partition數(shù)據(jù)的情況裆操，消費的速度也就不及只處理一個partition的消費者的處理速度怒详！
如果是消費者組的消費者多于partition的數(shù)量，那會不會出現(xiàn)多個消費者消費同一個partition的數(shù)據(jù)呢踪区？上面已經(jīng)提到過不會出現(xiàn)這種情況昆烁！多出來的消費者不消費任何partition的數(shù)據(jù)。
所以在實際的應用中缎岗，建議消費者組的consumer的數(shù)量與partition的數(shù)量一致静尼！
在保存數(shù)據(jù)的小節(jié)里面，我們聊到了partition劃分為多組segment传泊，每個segment又包含.log鼠渺、.index、.timeindex文件或渤，存放的每條message包含offset系冗、消息大小、消息體……我們多次提到segment和offset薪鹦，查找消息的時候是怎么利用segment+offset配合查找的呢掌敬？
假如現(xiàn)在需要查找一個offset為368801的message是什么樣的過程呢？我們先看看下面的圖：
1池磁、 先找到offset的368801message所在的segment文件（利用二分法查找）奔害，這里找到的就是在第二個segment文件。
2地熄、 打開找到的segment中的.index文件（也就是368796.index文件华临，該文件起始偏移量為368796+1，我們要查找的offset為368801的message在該index內(nèi)的偏移量為368796+5=368801端考，所以這里要查找的相對offset為5）雅潭。由于該文件采用的是稀疏索引的方式存儲著相對offset及對應message物理偏移量的關(guān)系，所以直接找相對offset為5的索引找不到却特，這里同樣利用二分法查找相對offset小于或者等于指定的相對offset的索引條目中最大的那個相對offset扶供，所以找到的是相對offset為4的這個索引。
3裂明、 根據(jù)找到的相對offset為4的索引確定message存儲的物理偏移位置為256椿浓。打開數(shù)據(jù)文件，從位置為256的那個地方開始順序掃描直到找到offset為368801的那條Message闽晦。
這套機制是建立在offset為有序的基礎(chǔ)上扳碍，利用segment+有序offset+稀疏索引+二分查找+順序查找等多種手段來高效的查找數(shù)據(jù)！至此仙蛉，消費者就能拿到需要處理的數(shù)據(jù)進行處理了笋敞。那每個消費者又是怎么記錄自己消費的位置呢？在早期的版本中荠瘪，消費者將消費到的offset維護zookeeper中液样，consumer每間隔一段時間上報一次振亮，這里容易導致重復消費，且性能不好鞭莽！在新的版本中消費者消費到的offset已經(jīng)直接維護在kafk集群的__consumer_offsets這個topic中坊秸！
