干啥啥不行，看小說第一名躬贡。這不谆奥，好好寫了一篇文章。

最近整理了一下文章目錄拂玻，因為好早之前就有兄弟跟我說之前文章找不到酸些，我也懶得整理宰译，現(xiàn)在好好整了一下，發(fā)現(xiàn)有一篇文章寫了一半我就放著了魄懂，抽空把他剛好補(bǔ)齊了一下沿侈，之前放著沒寫大概是很難想到從哪里湊這么多問題？市栗？缀拭？

看這里，找文章：文章目錄

說說你對kafka的理解

kafka是一個流式數(shù)據(jù)處理平臺填帽，他具有消息系統(tǒng)的能力蛛淋，也有實時流式數(shù)據(jù)處理分析能力，只是我們更多的偏向于把他當(dāng)做消息隊列系統(tǒng)來使用篡腌。

如果說按照容易理解來分層的話铣鹏，大致可以分為3層：

第一層是Zookeeper，相當(dāng)于注冊中心哀蘑，他負(fù)責(zé)kafka集群元數(shù)據(jù)的管理诚卸，以及集群的協(xié)調(diào)工作，在每個kafka服務(wù)器啟動的時候去連接到Zookeeper绘迁，把自己注冊到Zookeeper當(dāng)中

第二層里是kafka的核心層合溺，這里就會包含很多kafka的基本概念在內(nèi)：

record：代表消息

topic：主題，消息都會由一個主題方式來組織缀台，可以理解為對于消息的一個分類

producer：生產(chǎn)者棠赛，負(fù)責(zé)發(fā)送消息

consumer：消費者，負(fù)責(zé)消費消息

broker：kafka服務(wù)器

partition：分區(qū)膛腐，主題會由多個分區(qū)組成睛约，通常每個分區(qū)的消息都是按照順序讀取的，不同的分區(qū)無法保證順序性哲身，分區(qū)也就是我們常說的數(shù)據(jù)分片sharding機(jī)制辩涝，主要目的就是為了提高系統(tǒng)的伸縮能力，通過分區(qū)勘天，消息的讀寫可以負(fù)載均衡到多個不同的節(jié)點上

Leader/Follower：分區(qū)的副本怔揩。為了保證高可用，分區(qū)都會有一些副本脯丝，每個分區(qū)都會有一個Leader主副本負(fù)責(zé)讀寫數(shù)據(jù)商膊，F(xiàn)ollower從副本只負(fù)責(zé)和Leader副本保持?jǐn)?shù)據(jù)同步，不對外提供任何服務(wù)

offset：偏移量宠进，分區(qū)中的每一條消息都會根據(jù)時間先后順序有一個遞增的序號晕拆，這個序號就是offset偏移量

Consumer group：消費者組，由多個消費者組成材蹬，一個組內(nèi)只會由一個消費者去消費一個分區(qū)的消息

Coordinator：協(xié)調(diào)者实幕，主要是為消費者組分配分區(qū)以及重平衡Rebalance操作

Controller：控制器阱高，其實就是一個broker而已，用于協(xié)調(diào)和管理整個Kafka集群茬缩，他會負(fù)責(zé)分區(qū)Leader選舉赤惊、主題管理等工作，在Zookeeper第一個創(chuàng)建臨時節(jié)點/controller的就會成為控制器

第三層則是存儲層凰锡，用來保存kafka的核心數(shù)據(jù)未舟，他們都會以日志的形式最終寫入磁盤中。

image

消息隊列模型知道嗎掂为？kafka是怎么做到支持這兩種模型的裕膀？

對于傳統(tǒng)的消息隊列系統(tǒng)支持兩個模型：

1. 點對點：也就是消息只能被一個消費者消費，消費完后消息刪除
2. 發(fā)布訂閱：相當(dāng)于廣播模式勇哗，消息可以被所有消費者消費

上面也說到過昼扛，kafka其實就是通過Consumer Group同時支持了這兩個模型。

如果說所有消費者都屬于一個Group欲诺，消息只能被同一個Group內(nèi)的一個消費者消費抄谐，那就是點對點模式。

如果每個消費者都是一個單獨的Group扰法，那么就是發(fā)布訂閱模式蛹含。

實際上，Kafka通過消費者分組的方式靈活的支持了這兩個模型塞颁。

能說說kafka通信過程原理嗎浦箱？

1. 首先kafka broker啟動的時候，會去向Zookeeper注冊自己的ID（創(chuàng)建臨時節(jié)點）祠锣，這個ID可以配置也可以自動生成酷窥，同時會去訂閱Zookeeper的brokers/ids路徑，當(dāng)有新的broker加入或者退出時伴网，可以得到當(dāng)前所有broker信息
2. 生產(chǎn)者啟動的時候會指定bootstrap.servers蓬推，通過指定的broker地址，Kafka就會和這些broker創(chuàng)建TCP連接（通常我們不用配置所有的broker服務(wù)器地址是偷，否則kafka會和配置的所有broker都建立TCP連接）
3. 隨便連接到任何一臺broker之后拳氢，然后再發(fā)送請求獲取元數(shù)據(jù)信息（包含有哪些主題募逞、主題都有哪些分區(qū)蛋铆、分區(qū)有哪些副本，分區(qū)的Leader副本等信息）
4. 接著就會創(chuàng)建和所有broker的TCP連接
5. 之后就是發(fā)送消息的過程
6. 消費者和生產(chǎn)者一樣放接，也會指定bootstrap.servers屬性刺啦，然后選擇一臺broker創(chuàng)建TCP連接，發(fā)送請求找到協(xié)調(diào)者所在的broker
7. 然后再和協(xié)調(diào)者broker創(chuàng)建TCP連接纠脾，獲取元數(shù)據(jù)
8. 根據(jù)分區(qū)Leader節(jié)點所在的broker節(jié)點玛瘸，和這些broker分別創(chuàng)建連接
9. 最后開始消費消息

image

那么發(fā)送消息時如何選擇分區(qū)的蜕青？

主要有兩種方式：

1. 輪詢，按照順序消息依次發(fā)送到不同的分區(qū)
2. 隨機(jī)糊渊，隨機(jī)發(fā)送到某個分區(qū)

如果消息指定key右核，那么會根據(jù)消息的key進(jìn)行hash，然后對partition分區(qū)數(shù)量取模渺绒，決定落在哪個分區(qū)上贺喝，所以，對于相同key的消息來說宗兼，總是會發(fā)送到同一個分區(qū)上躏鱼，也是我們常說的消息分區(qū)有序性。

很常見的場景就是我們希望下單殷绍、支付消息有順序染苛，這樣以訂單ID作為key發(fā)送消息就達(dá)到了分區(qū)有序性的目的。

如果沒有指定key主到，會執(zhí)行默認(rèn)的輪詢負(fù)載均衡策略茶行，比如第一條消息落在P0，第二條消息落在P1登钥，然后第三條又在P1拢军。

除此之外，對于一些特定的業(yè)務(wù)場景和需求怔鳖，還可以通過實現(xiàn)Partitioner接口茉唉，重寫configure和partition方法來達(dá)到自定義分區(qū)的效果。

好结执，那你覺得為什么需要分區(qū)度陆？有什么好處？

這個問題很簡單献幔，如果說不分區(qū)的話懂傀，我們發(fā)消息寫數(shù)據(jù)都只能保存到一個節(jié)點上，這樣的話就算這個服務(wù)器節(jié)點性能再好最終也支撐不住蜡感。

實際上分布式系統(tǒng)都面臨這個問題蹬蚁，要么收到消息之后進(jìn)行數(shù)據(jù)切分，要么提前切分郑兴，kafka正是選擇了前者犀斋，通過分區(qū)可以把數(shù)據(jù)均勻地分布到不同的節(jié)點。

分區(qū)帶來了負(fù)載均衡和橫向擴(kuò)展的能力情连。

發(fā)送消息時可以根據(jù)分區(qū)的數(shù)量落在不同的Kafka服務(wù)器節(jié)點上叽粹，提升了并發(fā)寫消息的性能，消費消息的時候又和消費者綁定了關(guān)系，可以從不同節(jié)點的不同分區(qū)消費消息虫几，提高了讀消息的能力锤灿。

另外一個就是分區(qū)又引入了副本，冗余的副本保證了Kafka的高可用和高持久性辆脸。

詳細(xì)說說消費者組和消費者重平衡但校？

Kafka中的消費者組訂閱topic主題的消息，一般來說消費者的數(shù)量最好要和所有主題分區(qū)的數(shù)量保持一致最好（舉例子用一個主題啡氢，實際上當(dāng)然是可以訂閱多個主題）始腾。

當(dāng)消費者數(shù)量小于分區(qū)數(shù)量的時候，那么必然會有一個消費者消費多個分區(qū)的消息空执。

而消費者數(shù)量超過分區(qū)的數(shù)量的時候浪箭，那么必然會有消費者沒有分區(qū)可以消費。

所以辨绊，消費者組的好處一方面在上面說到過奶栖，可以支持多種消息模型，另外的話根據(jù)消費者和分區(qū)的消費關(guān)系门坷，支撐橫向擴(kuò)容伸縮宣鄙。

image

當(dāng)我們知道消費者如何消費分區(qū)的時候，就顯然會有一個問題出現(xiàn)了默蚌，消費者消費的分區(qū)是怎么分配的冻晤，有先加入的消費者時候怎么辦？

舊版本的重平衡過程主要通過ZK監(jiān)聽器的方式來觸發(fā)绸吸，每個消費者客戶端自己去執(zhí)行分區(qū)分配算法鼻弧。

新版本則是通過協(xié)調(diào)者來完成，每一次新的消費者加入都會發(fā)送請求給協(xié)調(diào)者去獲取分區(qū)的分配锦茁，這個分區(qū)分配的算法邏輯由協(xié)調(diào)者來完成攘轩。

而重平衡Rebalance就是指的有新消費者加入的情況，比如剛開始我們只有消費者A在消費消息码俩，過了一段時間消費者B和C加入了度帮，這時候分區(qū)就需要重新分配，這就是重平衡稿存，也可以叫做再平衡笨篷，但是重平衡的過程和我們的GC時候STW很像，會導(dǎo)致整個消費群組停止工作瓣履，重平衡期間都無法消息消息率翅。

另外，發(fā)生重平衡并不是只有這一種情況拂苹，因為消費者和分區(qū)總數(shù)是存在綁定關(guān)系的安聘，上面也說了痰洒，消費者數(shù)量最好和所有主題的分區(qū)總數(shù)一樣瓢棒。

那只要消費者數(shù)量浴韭、主題數(shù)量（比如用的正則訂閱的主題）、分區(qū)數(shù)量任何一個發(fā)生改變脯宿，都會觸發(fā)重平衡念颈。

下面說說重平衡的過程。

重平衡的機(jī)制依賴消費者和協(xié)調(diào)者之間的心跳來維持连霉，消費者會有一個獨立的線程去定時發(fā)送心跳給協(xié)調(diào)者榴芳，這個可以通過參數(shù)heartbeat.interval.ms來控制發(fā)送心跳的間隔時間。

1. 每個消費者第一次加入組的時候都會向協(xié)調(diào)者發(fā)送JoinGroup請求跺撼，第一個發(fā)送這個請求的消費者會成為“群主”窟感，協(xié)調(diào)者會返回組成員列表給群主

2. 群主執(zhí)行分區(qū)分配策略，然后把分配結(jié)果通過SyncGroup請求發(fā)送給協(xié)調(diào)者歉井，協(xié)調(diào)者收到分區(qū)分配結(jié)果

3. 其他組內(nèi)成員也向協(xié)調(diào)者發(fā)送SyncGroup柿祈，協(xié)調(diào)者把每個消費者的分區(qū)分配分別響應(yīng)給他們

image

那你跟我再具體講講分區(qū)分配策略？

主要有3種分配策略：

Range

不知道咋翻譯哩至，這個是默認(rèn)的策略躏嚎。大概意思就是對分區(qū)進(jìn)行排序，排序越靠前的分區(qū)能夠分配到更多的分區(qū)菩貌。

比如有3個分區(qū)卢佣，消費者A排序更靠前，所以能夠分配到P0\P1兩個分區(qū)箭阶，消費者B就只能分配到一個P2虚茶。

如果是4個分區(qū)的話，那么他們會剛好都是分配到2個仇参。

image

但是這個分配策略會有點小問題媳危，他是根據(jù)主題進(jìn)行分配，所以如果消費者組訂閱了多個主題冈敛，那就有可能導(dǎo)致分區(qū)分配不均衡待笑。

比如下圖中兩個主題的P0\P1都被分配給了A，這樣A有4個分區(qū)抓谴，而B只有2個暮蹂，如果這樣的主題數(shù)量越多，那么不均衡就越嚴(yán)重癌压。

image

RoundRobin

也就是我們常說的輪詢了仰泻，這個就比較簡單了，不畫圖你也能很容易理解滩届。

這個會根據(jù)所有的主題進(jìn)行輪詢分配集侯，不會出現(xiàn)Range那種主題越多可能導(dǎo)致分區(qū)分配不均衡的問題。

P0->A，P1->B棠枉，P1->A浓体。。辈讶。以此類推

image

Sticky

這個從字面看來意思就是粘性策略命浴，大概是這個意思。主要考慮的是在分配均衡的前提下贱除，讓分區(qū)的分配更小的改動生闲。

比如之前P0\P1分配給消費者A，那么下一次盡量還是分配給A月幌。

這樣的好處就是連接可以復(fù)用碍讯，要消費消息總是要和broker去連接的，如果能夠保持上一次分配的分區(qū)的話扯躺，那么就不用頻繁的銷毀創(chuàng)建連接了捉兴。

來吧！如何保證消息可靠性缅帘？

消息可靠性的保證基本上我們都要從3個方面來闡述（這樣才比較全面轴术，無懈可擊）

生產(chǎn)者發(fā)送消息丟失

kafka支持3種方式發(fā)送消息，這也是常規(guī)的3種方式钦无，發(fā)送后不管結(jié)果逗栽、同步發(fā)送、異步發(fā)送失暂，基本上所有的消息隊列都是這樣玩的彼宠。

1. 發(fā)送并忘記，直接調(diào)用發(fā)送send方法弟塞，不管結(jié)果凭峡，雖然可以開啟自動重試，但是肯定會有消息丟失的可能
2. 同步發(fā)送决记，同步發(fā)送返回Future對象摧冀，我們可以知道發(fā)送結(jié)果，然后進(jìn)行處理
3. 異步發(fā)送系宫，發(fā)送消息索昂，同時指定一個回調(diào)函數(shù)，根據(jù)結(jié)果進(jìn)行相應(yīng)的處理

為了保險起見扩借，一般我們都會使用異步發(fā)送帶有回調(diào)的方式進(jìn)行發(fā)送消息椒惨，再設(shè)置參數(shù)為發(fā)送消息失敗不停地重試。

acks=all潮罪，這個參數(shù)有可以配置0|1|all康谆。

0表示生產(chǎn)者寫入消息不管服務(wù)器的響應(yīng)领斥，可能消息還在網(wǎng)絡(luò)緩沖區(qū)，服務(wù)器根本沒有收到消息沃暗，當(dāng)然會丟失消息月洛。

1表示至少有一個副本收到消息才認(rèn)為成功，一個副本那肯定就是集群的Leader副本了描睦，但是如果剛好Leader副本所在的節(jié)點掛了膊存，F(xiàn)ollower沒有同步這條消息导而，消息仍然丟失了忱叭。

配置all的話表示所有ISR都寫入成功才算成功，那除非所有ISR里的副本全掛了今艺，消息才會丟失韵丑。

retries=N，設(shè)置一個非常大的值虚缎，可以讓生產(chǎn)者發(fā)送消息失敗后不停重試

kafka自身消息丟失

kafka因為消息寫入是通過PageCache異步寫入磁盤的撵彻，因此仍然存在丟失消息的可能。

因此針對kafka自身丟失的可能設(shè)置參數(shù)：

replication.factor=N实牡，設(shè)置一個比較大的值陌僵，保證至少有2個或者以上的副本。

min.insync.replicas=N创坞，代表消息如何才能被認(rèn)為是寫入成功碗短，設(shè)置大于1的數(shù)，保證至少寫入1個或者以上的副本才算寫入消息成功题涨。

unclean.leader.election.enable=false偎谁，這個設(shè)置意味著沒有完全同步的分區(qū)副本不能成為Leader副本，如果是true的話纲堵，那些沒有完全同步Leader的副本成為Leader之后巡雨，就會有消息丟失的風(fēng)險。

消費者消息丟失

消費者丟失的可能就比較簡單席函，關(guān)閉自動提交位移即可淘邻，改為業(yè)務(wù)處理成功手動提交峦嗤。

因為重平衡發(fā)生的時候，消費者會去讀取上一次提交的偏移量，自動提交默認(rèn)是每5秒一次结澄，這會導(dǎo)致重復(fù)消費或者丟失消息。

enable.auto.commit=false吁津，設(shè)置為手動提交凭舶。

還有一個參數(shù)我們可能也需要考慮進(jìn)去的：

auto.offset.reset=earliest，這個參數(shù)代表沒有偏移量可以提交或者broker上不存在偏移量的時候溶推，消費者如何處理徊件。earliest代表從分區(qū)的開始位置讀取奸攻，可能會重復(fù)讀取消息，但是不會丟失虱痕，消費方一般我們肯定要自己保證冪等睹耐，另外一種latest表示從分區(qū)末尾讀取，那就會有概率丟失消息部翘。

綜合這幾個參數(shù)設(shè)置硝训，我們就能保證消息不會丟失，保證了可靠性新思。

OK窖梁，聊聊副本和它的同步原理吧？

Kafka副本的之前提到過夹囚，分為Leader副本和Follower副本纵刘，也就是主副本和從副本，和其他的比如Mysql不一樣的是荸哟，Kafka中只有Leader副本會對外提供服務(wù)假哎，F(xiàn)ollower副本只是單純地和Leader保持?jǐn)?shù)據(jù)同步，作為數(shù)據(jù)冗余容災(zāi)的作用鞍历。

在Kafka中我們把所有副本的集合統(tǒng)稱為AR（Assigned Replicas）舵抹，和Leader副本保持同步的副本集合稱為ISR（InSyncReplicas）。

ISR是一個動態(tài)的集合劣砍，維持這個集合會通過replica.lag.time.max.ms參數(shù)來控制惧蛹，這個代表落后Leader副本的最長時間，默認(rèn)值10秒秆剪，所以只要Follower副本沒有落后Leader副本超過10秒以上赊淑，就可以認(rèn)為是和Leader同步的（簡單可以認(rèn)為就是同步時間差）。

另外還有兩個關(guān)鍵的概念用于副本之間的同步：

HW（High Watermark）：高水位仅讽，也叫做復(fù)制點陶缺，表示副本間同步的位置。如下圖所示洁灵，0_{4綠色表示已經(jīng)提交的消息饱岸，這些消息已經(jīng)在副本之間進(jìn)行同步，消費者可以看見這些消息并且進(jìn)行消費徽千，4}6黃色的則是表示未提交的消息苫费，可能還沒有在副本間同步，這些消息對于消費者是不可見的双抽。

LEO（Log End Offset）：下一條待寫入消息的位移

hw

<figcaption style="margin-top: 5px; text-align: center; color: #888; font-size: 12px;">hw</figcaption>

副本間同步的過程依賴的就是HW和LEO的更新百框，以他們的值變化來演示副本同步消息的過程，綠色表示Leader副本牍汹，黃色表示Follower副本铐维。

首先柬泽，生產(chǎn)者不停地向Leader寫入數(shù)據(jù)，這時候Leader的LEO可能已經(jīng)達(dá)到了10嫁蛇，但是HW依然是0锨并，兩個Follower向Leader請求同步數(shù)據(jù)，他們的值都是0睬棚。

image

然后第煮，消息還在繼續(xù)寫入，Leader的LEO值又發(fā)生了變化抑党，兩個Follower也各自拉取到了自己的消息包警，于是更新自己的LEO值，但是這時候Leader的HW依然沒有改變新荤。

image

此時揽趾，F(xiàn)ollower再次向Leader拉取數(shù)據(jù)台汇，這時候Leader會更新自己的HW值苛骨，取Follower中的最小的LEO值來更新。

image

之后苟呐，Leader響應(yīng)自己的HW給Follower痒芝，F(xiàn)ollower更新自己的HW值，因為又拉取到了消息牵素，所以再次更新LEO严衬，流程以此類推。

image

你知道新版本Kafka為什么拋棄了Zookeeper嗎笆呆？

我認(rèn)為可以從兩個個方面來回答這個問題：

首先请琳，從運維的復(fù)雜度來看，Kafka本身是一個分布式系統(tǒng)赠幕，他的運維就已經(jīng)很復(fù)雜了俄精，那除此之外，還需要重度依賴另外一個ZK榕堰，這對成本和復(fù)雜度來說都是一個很大的工作量竖慧。

其次，應(yīng)該是考慮到性能方面的問題逆屡，比如之前的提交位移的操作都是保存在ZK里面的圾旨，但是ZK實際上不適合這種高頻的讀寫更新操作，這樣的話會嚴(yán)重影響ZK集群的性能魏蔗，這一方面后來新版本中Kafka也把提交和保存位移用消息的方式來處理了砍的。

另外Kafka嚴(yán)重依賴ZK來實現(xiàn)元數(shù)據(jù)的管理和集群的協(xié)調(diào)工作，如果集群規(guī)模龐大莺治，主題和分區(qū)數(shù)量很多廓鞠，會導(dǎo)致ZK集群的元數(shù)據(jù)過多味混，集群壓力過大，直接影響到很多Watch的延時或者丟失诫惭。

OK翁锡，最后一個大家都問的問題，Kafka為什么快夕土？

嘿馆衔，這個我費，我背過好多次了怨绣！主要是3個方面：

順序IO

kafka寫消息到分區(qū)采用追加的方式角溃，也就是順序?qū)懭氪疟P，不是隨機(jī)寫入篮撑，這個速度比普通的隨機(jī)IO快非常多减细，幾乎可以和網(wǎng)絡(luò)IO的速度相媲美。

Page Cache和零拷貝

kafka在寫入消息數(shù)據(jù)的時候通過mmap內(nèi)存映射的方式赢笨，不是真正立刻寫入磁盤未蝌，而是利用操作系統(tǒng)的文件緩存PageCache異步寫入，提高了寫入消息的性能茧妒，另外在消費消息的時候又通過sendfile實現(xiàn)了零拷貝萧吠。

關(guān)于mmap和sendfile零拷貝我都專門寫過，可以看這里：阿里二面：什么是mmap桐筏？

批量處理和壓縮

Kafka在發(fā)送消息的時候不是一條條的發(fā)送的纸型，而是會把多條消息合并成一個批次進(jìn)行處理發(fā)送，消費消息也是一個道理梅忌，一次拉取一批次的消息進(jìn)行消費狰腌。

并且Producer、Broker牧氮、Consumer都使用了優(yōu)化后的壓縮算法琼腔，發(fā)送和消息消息使用壓縮節(jié)省了網(wǎng)絡(luò)傳輸?shù)拈_銷，Broker存儲使用壓縮則降低了磁盤存儲的空間蹋笼。