Kafka 奪命連環(huán)11問
干啥啥不行，看小說第一名。這不，好好寫了一篇文章。
最近整理了一下文章目錄，因為好早之前就有兄弟跟我說之前文章找不到，我也懶得整理，現(xiàn)在好好整了一下，發(fā)現(xiàn)有一篇文章寫了一半我就放著了，抽空把他剛好補齊了一下，之前放著沒寫大概是很難想到從哪里湊這么多問題???
文章目錄的話去看公眾號菜單欄中間就有了，這樣大家以后方便點。
說說你對kafka的理解
kafka是一個流式數(shù)據(jù)處理平臺，他具有消息系統(tǒng)的能力，也有實時流式數(shù)據(jù)處理分析能力，只是我們更多的偏向于把他當做消息隊列系統(tǒng)來使用。
如果說按照容易理解來分層的話，大致可以分為3層：
第一層是Zookeeper，相當于注冊中心，他負責kafka集群元數(shù)據(jù)的管理，以及集群的協(xié)調(diào)工作，在每個kafka服務器啟動的時候去連接到Zookeeper，把自己注冊到Zookeeper當中
第二層里是kafka的核心層，這里就會包含很多kafka的基本概念在內(nèi)：
record：代表消息
topic：主題，消息都會由一個主題方式來組織，可以理解為對于消息的一個分類
producer：生產(chǎn)者，負責發(fā)送消息
consumer：消費者，負責消費消息
broker：kafka服務器
partition：分區(qū)，主題會由多個分區(qū)組成，通常每個分區(qū)的消息都是按照順序讀取的，不同的分區(qū)無法保證順序性，分區(qū)也就是我們常說的數(shù)據(jù)分片sharding機制，主要目的就是為了提高系統(tǒng)的伸縮能力，通過分區(qū)，消息的讀寫可以負載均衡到多個不同的節(jié)點上
Leader/Follower：分區(qū)的副本。為了保證高可用，分區(qū)都會有一些副本，每個分區(qū)都會有一個Leader主副本負責讀寫數(shù)據(jù)，F(xiàn)ollower從副本只負責和Leader副本保持數(shù)據(jù)同步，不對外提供任何服務
offset：偏移量，分區(qū)中的每一條消息都會根據(jù)時間先后順序有一個遞增的序號，這個序號就是offset偏移量
Consumer group：消費者組，由多個消費者組成，一個組內(nèi)只會由一個消費者去消費一個分區(qū)的消息
Coordinator：協(xié)調(diào)者，主要是為消費者組分配分區(qū)以及重平衡Rebalance操作
Controller：控制器，其實就是一個broker而已，用于協(xié)調(diào)和管理整個Kafka集群，他會負責分區(qū)Leader選舉、主題管理等工作，在Zookeeper第一個創(chuàng)建臨時節(jié)點/controller的就會成為控制器
第三層則是存儲層，用來保存kafka的核心數(shù)據(jù)，他們都會以日志的形式最終寫入磁盤中。
消息隊列模型知道嗎?kafka是怎么做到支持這兩種模型的?
對于傳統(tǒng)的消息隊列系統(tǒng)支持兩個模型：
- 點對點：也就是消息只能被一個消費者消費，消費完后消息刪除
- 發(fā)布訂閱：相當于廣播模式，消息可以被所有消費者消費
上面也說到過，kafka其實就是通過Consumer Group同時支持了這兩個模型。
如果說所有消費者都屬于一個Group，消息只能被同一個Group內(nèi)的一個消費者消費，那就是點對點模式。
如果每個消費者都是一個單獨的Group，那么就是發(fā)布訂閱模式。
實際上，Kafka通過消費者分組的方式靈活的支持了這兩個模型。
能說說kafka通信過程原理嗎?
- 首先kafka broker啟動的時候，會去向Zookeeper注冊自己的ID(創(chuàng)建臨時節(jié)點)，這個ID可以配置也可以自動生成，同時會去訂閱Zookeeper的brokers/ids路徑，當有新的broker加入或者退出時，可以得到當前所有broker信息
- 生產(chǎn)者啟動的時候會指定bootstrap.servers，通過指定的broker地址，Kafka就會和這些broker創(chuàng)建TCP連接(通常我們不用配置所有的broker服務器地址，否則kafka會和配置的所有broker都建立TCP連接)
- 隨便連接到任何一臺broker之后，然后再發(fā)送請求獲取元數(shù)據(jù)信息(包含有哪些主題、主題都有哪些分區(qū)、分區(qū)有哪些副本，分區(qū)的Leader副本等信息)
- 接著就會創(chuàng)建和所有broker的TCP連接
- 之后就是發(fā)送消息的過程
- 消費者和生產(chǎn)者一樣，也會指定bootstrap.servers屬性，然后選擇一臺broker創(chuàng)建TCP連接，發(fā)送請求找到協(xié)調(diào)者所在的broker
- 然后再和協(xié)調(diào)者broker創(chuàng)建TCP連接，獲取元數(shù)據(jù)
- 根據(jù)分區(qū)Leader節(jié)點所在的broker節(jié)點，和這些broker分別創(chuàng)建連接
- 最后開始消費消息
那么發(fā)送消息時如何選擇分區(qū)的?
主要有兩種方式：
- 輪詢，按照順序消息依次發(fā)送到不同的分區(qū)
- 隨機，隨機發(fā)送到某個分區(qū)
如果消息指定key，那么會根據(jù)消息的key進行hash，然后對partition分區(qū)數(shù)量取模，決定落在哪個分區(qū)上，所以，對于相同key的消息來說，總是會發(fā)送到同一個分區(qū)上，也是我們常說的消息分區(qū)有序性。
很常見的場景就是我們希望下單、支付消息有順序，這樣以訂單ID作為key發(fā)送消息就達到了分區(qū)有序性的目的。
如果沒有指定key，會執(zhí)行默認的輪詢負載均衡策略，比如第一條消息落在P0，第二條消息落在P1，然后第三條又在P1。
除此之外，對于一些特定的業(yè)務場景和需求，還可以通過實現(xiàn)Partitioner接口，重寫configure和partition方法來達到自定義分區(qū)的效果。
好，那你覺得為什么需要分區(qū)?有什么好處?
這個問題很簡單，如果說不分區(qū)的話，我們發(fā)消息寫數(shù)據(jù)都只能保存到一個節(jié)點上，這樣的話就算這個服務器節(jié)點性能再好最終也支撐不住。
實際上分布式系統(tǒng)都面臨這個問題，要么收到消息之后進行數(shù)據(jù)切分，要么提前切分，kafka正是選擇了前者，通過分區(qū)可以把數(shù)據(jù)均勻地分布到不同的節(jié)點。
分區(qū)帶來了負載均衡和橫向擴展的能力。
發(fā)送消息時可以根據(jù)分區(qū)的數(shù)量落在不同的Kafka服務器節(jié)點上，提升了并發(fā)寫消息的性能，消費消息的時候又和消費者綁定了關系，可以從不同節(jié)點的不同分區(qū)消費消息，提高了讀消息的能力。
另外一個就是分區(qū)又引入了副本，冗余的副本保證了Kafka的高可用和高持久性。
詳細說說消費者組和消費者重平衡?
Kafka中的消費者組訂閱topic主題的消息，一般來說消費者的數(shù)量最好要和所有主題分區(qū)的數(shù)量保持一致最好(舉例子用一個主題，實際上當然是可以訂閱多個主題)。
當消費者數(shù)量小于分區(qū)數(shù)量的時候，那么必然會有一個消費者消費多個分區(qū)的消息。
而消費者數(shù)量超過分區(qū)的數(shù)量的時候，那么必然會有消費者沒有分區(qū)可以消費。
所以，消費者組的好處一方面在上面說到過，可以支持多種消息模型，另外的話根據(jù)消費者和分區(qū)的消費關系，支撐橫向擴容伸縮。
當我們知道消費者如何消費分區(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很像，會導致整個消費群組停止工作，重平衡期間都無法消息消息。
另外，發(fā)生重平衡并不是只有這一種情況，因為消費者和分區(qū)總數(shù)是存在綁定關系的，上面也說了，消費者數(shù)量最好和所有主題的分區(qū)總數(shù)一樣。
那只要消費者數(shù)量、主題數(shù)量(比如用的正則訂閱的主題)、分區(qū)數(shù)量任何一個發(fā)生改變，都會觸發(fā)重平衡。
下面說說重平衡的過程。
重平衡的機制依賴消費者和協(xié)調(diào)者之間的心跳來維持，消費者會有一個獨立的線程去定時發(fā)送心跳給協(xié)調(diào)者，這個可以通過參數(shù)heartbeat.interval.ms來控制發(fā)送心跳的間隔時間。
- 每個消費者第一次加入組的時候都會向協(xié)調(diào)者發(fā)送JoinGroup請求，第一個發(fā)送這個請求的消費者會成為“群主”，協(xié)調(diào)者會返回組成員列表給群主
- 群主執(zhí)行分區(qū)分配策略，然后把分配結(jié)果通過SyncGroup請求發(fā)送給協(xié)調(diào)者，協(xié)調(diào)者收到分區(qū)分配結(jié)果
- 其他組內(nèi)成員也向協(xié)調(diào)者發(fā)送SyncGroup，協(xié)調(diào)者把每個消費者的分區(qū)分配分別響應給他們
那你跟我再具體講講分區(qū)分配策略?
主要有3種分配策略：
Range
不知道咋翻譯，這個是默認的策略。大概意思就是對分區(qū)進行排序，排序越靠前的分區(qū)能夠分配到更多的分區(qū)。
比如有3個分區(qū)，消費者A排序更靠前，所以能夠分配到P0\P1兩個分區(qū)，消費者B就只能分配到一個P2。
如果是4個分區(qū)的話，那么他們會剛好都是分配到2個。
但是這個分配策略會有點小問題，他是根據(jù)主題進行分配，所以如果消費者組訂閱了多個主題，那就有可能導致分區(qū)分配不均衡。
比如下圖中兩個主題的P0\P1都被分配給了A，這樣A有4個分區(qū)，而B只有2個，如果這樣的主題數(shù)量越多，那么不均衡就越嚴重。
RoundRobin
也就是我們常說的輪詢了，這個就比較簡單了，不畫圖你也能很容易理解。
這個會根據(jù)所有的主題進行輪詢分配，不會出現(xiàn)Range那種主題越多可能導致分區(qū)分配不均衡的問題。
P0->A，P1->B，P1->A。。。以此類推
Sticky
這個從字面看來意思就是粘性策略，大概是這個意思。主要考慮的是在分配均衡的前提下，讓分區(qū)的分配更小的改動。
比如之前P0\P1分配給消費者A，那么下一次盡量還是分配給A。
這樣的好處就是連接可以復用，要消費消息總是要和broker去連接的，如果能夠保持上一次分配的分區(qū)的話，那么就不用頻繁的銷毀創(chuàng)建連接了。
來吧!如何保證消息可靠性?
消息可靠性的保證基本上我們都要從3個方面來闡述(這樣才比較全面，無懈可擊)
生產(chǎn)者發(fā)送消息丟失
kafka支持3種方式發(fā)送消息，這也是常規(guī)的3種方式，發(fā)送后不管結(jié)果、同步發(fā)送、異步發(fā)送，基本上所有的消息隊列都是這樣玩的。
- 發(fā)送并忘記，直接調(diào)用發(fā)送send方法，不管結(jié)果，雖然可以開啟自動重試，但是肯定會有消息丟失的可能
- 同步發(fā)送，同步發(fā)送返回Future對象，我們可以知道發(fā)送結(jié)果，然后進行處理
- 異步發(fā)送，發(fā)送消息，同時指定一個回調(diào)函數(shù)，根據(jù)結(jié)果進行相應的處理
為了保險起見，一般我們都會使用異步發(fā)送帶有回調(diào)的方式進行發(fā)送消息，再設置參數(shù)為發(fā)送消息失敗不停地重試。
acks=all，這個參數(shù)有可以配置0|1|all。
0表示生產(chǎn)者寫入消息不管服務器的響應，可能消息還在網(wǎng)絡緩沖區(qū)，服務器根本沒有收到消息，當然會丟失消息。
1表示至少有一個副本收到消息才認為成功，一個副本那肯定就是集群的Leader副本了，但是如果剛好Leader副本所在的節(jié)點掛了，F(xiàn)ollower沒有同步這條消息，消息仍然丟失了。
配置all的話表示所有ISR都寫入成功才算成功，那除非所有ISR里的副本全掛了，消息才會丟失。
retries=N，設置一個非常大的值，可以讓生產(chǎn)者發(fā)送消息失敗后不停重試
kafka自身消息丟失
kafka因為消息寫入是通過PageCache異步寫入磁盤的，因此仍然存在丟失消息的可能。
因此針對kafka自身丟失的可能設置參數(shù)：
replication.factor=N，設置一個比較大的值，保證至少有2個或者以上的副本。
min.insync.replicas=N，代表消息如何才能被認為是寫入成功，設置大于1的數(shù)，保證至少寫入1個或者以上的副本才算寫入消息成功。
unclean.leader.election.enable=false，這個設置意味著沒有完全同步的分區(qū)副本不能成為Leader副本，如果是true的話，那些沒有完全同步Leader的副本成為Leader之后，就會有消息丟失的風險。
消費者消息丟失
消費者丟失的可能就比較簡單，關閉自動提交位移即可，改為業(yè)務處理成功手動提交。
因為重平衡發(fā)生的時候，消費者會去讀取上一次提交的偏移量，自動提交默認是每5秒一次，這會導致重復消費或者丟失消息。
enable.auto.commit=false，設置為手動提交。
還有一個參數(shù)我們可能也需要考慮進去的：
auto.offset.reset=earliest，這個參數(shù)代表沒有偏移量可以提交或者broker上不存在偏移量的時候，消費者如何處理。earliest代表從分區(qū)的開始位置讀取，可能會重復讀取消息，但是不會丟失，消費方一般我們肯定要自己保證冪等，另外一種latest表示從分區(qū)末尾讀取，那就會有概率丟失消息。
綜合這幾個參數(shù)設置，我們就能保證消息不會丟失，保證了可靠性。
OK，聊聊副本和它的同步原理吧?
Kafka副本的之前提到過，分為Leader副本和Follower副本，也就是主副本和從副本，和其他的比如Mysql不一樣的是，Kafka中只有Leader副本會對外提供服務，F(xiàn)ollower副本只是單純地和Leader保持數(shù)據(jù)同步，作為數(shù)據(jù)冗余容災的作用。
在Kafka中我們把所有副本的集合統(tǒng)稱為AR(Assigned Replicas)，和Leader副本保持同步的副本集合稱為ISR(InSyncReplicas)。
ISR是一個動態(tài)的集合，維持這個集合會通過replica.lag.time.max.ms參數(shù)來控制，這個代表落后Leader副本的最長時間，默認值10秒，所以只要Follower副本沒有落后Leader副本超過10秒以上，就可以認為是和Leader同步的(簡單可以認為就是同步時間差)。
另外還有兩個關鍵的概念用于副本之間的同步：
HW(High Watermark)：高水位，也叫做復制點，表示副本間同步的位置。如下圖所示，0~4綠色表示已經(jīng)提交的消息，這些消息已經(jīng)在副本之間進行同步，消費者可以看見這些消息并且進行消費，4~6黃色的則是表示未提交的消息，可能還沒有在副本間同步，這些消息對于消費者是不可見的。
LEO(Log End Offset)：下一條待寫入消息的位移
hw
副本間同步的過程依賴的就是HW和LEO的更新，以他們的值變化來演示副本同步消息的過程，綠色表示Leader副本，黃色表示Follower副本。
首先，生產(chǎn)者不停地向Leader寫入數(shù)據(jù)，這時候Leader的LEO可能已經(jīng)達到了10，但是HW依然是0，兩個Follower向Leader請求同步數(shù)據(jù)，他們的值都是0。
然后，消息還在繼續(xù)寫入，Leader的LEO值又發(fā)生了變化，兩個Follower也各自拉取到了自己的消息，于是更新自己的LEO值，但是這時候Leader的HW依然沒有改變。
此時，F(xiàn)ollower再次向Leader拉取數(shù)據(jù)，這時候Leader會更新自己的HW值，取Follower中的最小的LEO值來更新。
之后，Leader響應自己的HW給Follower，F(xiàn)ollower更新自己的HW值，因為又拉取到了消息，所以再次更新LEO，流程以此類推。
你知道新版本Kafka為什么拋棄了Zookeeper嗎?
我認為可以從兩個個方面來回答這個問題：
首先，從運維的復雜度來看，Kafka本身是一個分布式系統(tǒng)，他的運維就已經(jīng)很復雜了，那除此之外，還需要重度依賴另外一個ZK，這對成本和復雜度來說都是一個很大的工作量。
其次，應該是考慮到性能方面的問題，比如之前的提交位移的操作都是保存在ZK里面的，但是ZK實際上不適合這種高頻的讀寫更新操作，這樣的話會嚴重影響ZK集群的性能，這一方面后來新版本中Kafka也把提交和保存位移用消息的方式來處理了。
另外Kafka嚴重依賴ZK來實現(xiàn)元數(shù)據(jù)的管理和集群的協(xié)調(diào)工作，如果集群規(guī)模龐大，主題和分區(qū)數(shù)量很多，會導致ZK集群的元數(shù)據(jù)過多，集群壓力過大，直接影響到很多Watch的延時或者丟失。
OK，最后一個大家都問的問題，Kafka為什么快?
嘿，這個我費，我背過好多次了!主要是3個方面：
順序IO
kafka寫消息到分區(qū)采用追加的方式，也就是順序?qū)懭氪疟P，不是隨機寫入，這個速度比普通的隨機IO快非常多，幾乎可以和網(wǎng)絡IO的速度相媲美。
Page Cache和零拷貝
kafka在寫入消息數(shù)據(jù)的時候通過mmap內(nèi)存映射的方式，不是真正立刻寫入磁盤，而是利用操作系統(tǒng)的文件緩存PageCache異步寫入，提高了寫入消息的性能，另外在消費消息的時候又通過sendfile實現(xiàn)了零拷貝。
關于mmap和sendfile零拷貝我都專門寫過，可以看這里：阿里二面：什么是mmap?
批量處理和壓縮
Kafka在發(fā)送消息的時候不是一條條的發(fā)送的，而是會把多條消息合并成一個批次進行處理發(fā)送，消費消息也是一個道理，一次拉取一批次的消息進行消費。
并且Producer、Broker、Consumer都使用了優(yōu)化后的壓縮算法，發(fā)送和消息消息使用壓縮節(jié)省了網(wǎng)絡傳輸?shù)拈_銷，Broker存儲使用壓縮則降低了磁盤存儲的空間。
我是艾小仙，過兩天準備噴人。
