Kafka 奪命連環(huán)11問

作者：艾小仙 2021-10-26 15:56:57

開發(fā)

架構(gòu)

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

衡陽縣網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián),衡陽縣網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為衡陽縣成百上千提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢，請找那個(gè)售后服務(wù)好的衡陽縣做網(wǎng)站的公司定做！

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

最近整理了一下文章目錄，因?yàn)楹迷缰熬陀行值芨艺f之前文章找不到，我也懶得整理，現(xiàn)在好好整了一下，發(fā)現(xiàn)有一篇文章寫了一半我就放著了，抽空把他剛好補(bǔ)齊了一下，之前放著沒寫大概是很難想到從哪里湊這么多問題???

文章目錄的話去看公眾號菜單欄中間就有了，這樣大家以后方便點(diǎn)。

說說你對kafka的理解

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

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

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

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

record：代表消息

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

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

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

broker：kafka服務(wù)器

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

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

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

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

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

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

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

消息隊(duì)列模型知道嗎?kafka是怎么做到支持這兩種模型的?

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

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

上面也說到過，kafka其實(shí)就是通過Consumer Group同時(shí)支持了這兩個(gè)模型。

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

如果每個(gè)消費(fèi)者都是一個(gè)單獨(dú)的Group，那么就是發(fā)布訂閱模式。

實(shí)際上，Kafka通過消費(fèi)者分組的方式靈活的支持了這兩個(gè)模型。

能說說kafka通信過程原理嗎?

1. 首先kafka broker啟動(dòng)的時(shí)候，會去向Zookeeper注冊自己的ID(創(chuàng)建臨時(shí)節(jié)點(diǎn))，這個(gè)ID可以配置也可以自動(dòng)生成，同時(shí)會去訂閱Zookeeper的brokers/ids路徑，當(dāng)有新的broker加入或者退出時(shí)，可以得到當(dāng)前所有broker信息
2. 生產(chǎn)者啟動(dòng)的時(shí)候會指定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. 消費(fèi)者和生產(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é)點(diǎn)所在的broker節(jié)點(diǎn)，和這些broker分別創(chuàng)建連接
9. 最后開始消費(fèi)消息

那么發(fā)送消息時(shí)如何選擇分區(qū)的?

主要有兩種方式：

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

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

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

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

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

好，那你覺得為什么需要分區(qū)?有什么好處?

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

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

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

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

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

詳細(xì)說說消費(fèi)者組和消費(fèi)者重平衡?

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

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

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

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

當(dāng)我們知道消費(fèi)者如何消費(fèi)分區(qū)的時(shí)候，就顯然會有一個(gè)問題出現(xiàn)了，消費(fèi)者消費(fèi)的分區(qū)是怎么分配的，有先加入的消費(fèi)者時(shí)候怎么辦?

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

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

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

另外，發(fā)生重平衡并不是只有這一種情況，因?yàn)橄M(fèi)者和分區(qū)總數(shù)是存在綁定關(guān)系的，上面也說了，消費(fèi)者數(shù)量最好和所有主題的分區(qū)總數(shù)一樣。

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

下面說說重平衡的過程。

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

1. 每個(gè)消費(fèi)者第一次加入組的時(shí)候都會向協(xié)調(diào)者發(fā)送JoinGroup請求，第一個(gè)發(fā)送這個(gè)請求的消費(fèi)者會成為“群主”，協(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)者把每個(gè)消費(fèi)者的分區(qū)分配分別響應(yīng)給他們

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

主要有3種分配策略：

Range

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

比如有3個(gè)分區(qū)，消費(fèi)者A排序更靠前，所以能夠分配到P0\P1兩個(gè)分區(qū)，消費(fèi)者B就只能分配到一個(gè)P2。

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

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

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

RoundRobin

也就是我們常說的輪詢了，這個(gè)就比較簡單了，不畫圖你也能很容易理解。

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

P0->A，P1->B，P1->A。。。以此類推

Sticky

這個(gè)從字面看來意思就是粘性策略，大概是這個(gè)意思。主要考慮的是在分配均衡的前提下，讓分區(qū)的分配更小的改動(dòng)。

比如之前P0\P1分配給消費(fèi)者A，那么下一次盡量還是分配給A。

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

來吧!如何保證消息可靠性?

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

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

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

• 發(fā)送并忘記，直接調(diào)用發(fā)送send方法，不管結(jié)果，雖然可以開啟自動(dòng)重試，但是肯定會有消息丟失的可能
• 同步發(fā)送，同步發(fā)送返回Future對象，我們可以知道發(fā)送結(jié)果，然后進(jìn)行處理
• 異步發(fā)送，發(fā)送消息，同時(shí)指定一個(gè)回調(diào)函數(shù)，根據(jù)結(jié)果進(jìn)行相應(yīng)的處理

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

acks=all，這個(gè)參數(shù)有可以配置0|1|all。

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

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

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

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

kafka自身消息丟失

kafka因?yàn)橄懭胧峭ㄟ^PageCache異步寫入磁盤的，因此仍然存在丟失消息的可能。

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

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

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

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

消費(fèi)者消息丟失

消費(fèi)者丟失的可能就比較簡單，關(guān)閉自動(dòng)提交位移即可，改為業(yè)務(wù)處理成功手動(dòng)提交。

因?yàn)橹仄胶獍l(fā)生的時(shí)候，消費(fèi)者會去讀取上一次提交的偏移量，自動(dòng)提交默認(rèn)是每5秒一次，這會導(dǎo)致重復(fù)消費(fèi)或者丟失消息。

enable.auto.commit=false，設(shè)置為手動(dòng)提交。

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

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

綜合這幾個(gè)參數(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是一個(gè)動(dòng)態(tài)的集合，維持這個(gè)集合會通過replica.lag.time.max.ms參數(shù)來控制，這個(gè)代表落后Leader副本的最長時(shí)間，默認(rèn)值10秒，所以只要Follower副本沒有落后Leader副本超過10秒以上，就可以認(rèn)為是和Leader同步的(簡單可以認(rèn)為就是同步時(shí)間差)。

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

HW(High Watermark)：高水位，也叫做復(fù)制點(diǎn)，表示副本間同步的位置。如下圖所示，0~4綠色表示已經(jīng)提交的消息，這些消息已經(jīng)在副本之間進(jìn)行同步，消費(fèi)者可以看見這些消息并且進(jìn)行消費(fèi)，4~6黃色的則是表示未提交的消息，可能還沒有在副本間同步，這些消息對于消費(fèi)者是不可見的。

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

hw

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

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

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

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

之后，Leader響應(yīng)自己的HW給Follower，F(xiàn)ollower更新自己的HW值，因?yàn)橛掷〉搅讼ⅲ栽俅胃翷EO，流程以此類推。

你知道新版本Kafka為什么拋棄了Zookeeper嗎?

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

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

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

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

OK，最后一個(gè)大家都問的問題，Kafka為什么快?

嘿，這個(gè)我費(fèi)，我背過好多次了!主要是3個(gè)方面：

順序IO

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

Page Cache和零拷貝

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

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

批量處理和壓縮

Kafka在發(fā)送消息的時(shí)候不是一條條的發(fā)送的，而是會把多條消息合并成一個(gè)批次進(jìn)行處理發(fā)送，消費(fèi)消息也是一個(gè)道理，一次拉取一批次的消息進(jìn)行消費(fèi)。

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

我是艾小仙，過兩天準(zhǔn)備噴人。

當(dāng)前名稱：Kafka奪命連環(huán)11問
轉(zhuǎn)載來于：http://uogjgqi.cn/article/cohicio.html