本篇內(nèi)容介紹了“KAFKA的ISR的伸縮過程是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)是專業(yè)的牙克石網(wǎng)站建設(shè)公司，牙克石接單;提供成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站,網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行牙克石網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!

一、前言

知識(shí)點(diǎn)總結(jié)

二、概述

我們了解ISR列表是不斷伸縮的，在副本失效后及時(shí)踢出ISR列表，在副本趕上進(jìn)度之后重新將副本加入到ISR列表中，后面我們就會(huì)按照這個(gè)思路來看下其中細(xì)節(jié)。

三、什么是失效副本？

功能失效：節(jié)點(diǎn)宕機(jī)，在該節(jié)點(diǎn)上的副本都屬于功能失效副本。
同步失效：follower副本所在的broker因?yàn)閹捇蛘哓?fù)載等因素?zé)o法及時(shí)完成同步，導(dǎo)致被踢出ISR。

四、ISR伸縮控制參數(shù)了解嗎？

在0.9x版本之前，有一個(gè)控制參數(shù)：replica.lag.max.messages 默認(rèn)值為4000，表示如果follower的消息個(gè)數(shù)落后leader個(gè)數(shù)4000，那么就會(huì)被踢出ISR列表；
我們可以想一下這種直接指定條數(shù)的方式是否合理呢？顯然是不合理的，原因入下：
高吞吐的場景：瞬間就幾萬條消息，可能follower就滯后個(gè)幾秒鐘就被判定為失效從而被踢出，可能導(dǎo)致ISR列表頻繁的變動(dòng)，以及元數(shù)據(jù)的頻繁更新。
低吞吐的場景：可能一天就幾條消息，那可能follower都滯后好幾天了依舊存在于ISR中，那ISR不就失去意義了嗎？

因此0.9x版本開始，移除了該參數(shù)，取而代之的參數(shù)是replica.lag.time.max.ms 該參數(shù)默認(rèn)值是10000ms，也就是10s。
也就是說如果follower在10s都沒能追上leader的LEO，就會(huì)被認(rèn)定為失效，從而踢出IS列表。

五、ISR是如何將失效副本剔除的？

我們知道了ISR是如何判定失效副本后，再來看下，到底是怎么把這個(gè)失效的副本踢出去的呢？
1、每個(gè)broker在啟動(dòng)的時(shí)候都會(huì)啟動(dòng)兩個(gè)定時(shí)任務(wù)：

• isr-expiration：定時(shí)檢查當(dāng)前broker上的eader對(duì)應(yīng)的副本失效信息，也就是看當(dāng)前Leader的ISR列表中是否存在失效副本，默認(rèn)執(zhí)行周期為replica.lag.time.max.ms / 2 = 5s。

• isr-change-propagation：定時(shí)檢查內(nèi)存isrChangeSet中是否有新的變更數(shù)據(jù)，固定執(zhí)行周期為2.5s

2、判斷副本失效:
isr-expiration任務(wù)會(huì)根據(jù)當(dāng)前時(shí)間now，減去某follower的 lastCaughtUpTimeMs，如果大于replica.lag.time.max.ms值，則說明失效。
而lastCaughtUpTimeMs這個(gè)值，在follower的LEO與leader的LEO相等時(shí)(Leader中維護(hù)了follower的LEO信息)，被更新。
也就是說，只有當(dāng)follower完全追上了Leader才更新，而不是每Fetch一次就更新。

關(guān)于為什么不是每次Fetch的時(shí)候就更新該值呢？
我們試想一下，如果leader的寫入速率遠(yuǎn)大于follower的同步速率，可能leader已經(jīng)寫了10w條數(shù)據(jù)了，follower由于網(wǎng)絡(luò)/負(fù)載為原因還在慢悠悠的同步，但是因?yàn)镕etch請(qǐng)求是正常發(fā)送的，就每次都更新lastCaughtUpTimeMs值，從而認(rèn)為該follower是有效的，那這不就導(dǎo)致leader和follower之間在這種場景下存在巨大的數(shù)據(jù)差異了嘛？從而影響數(shù)據(jù)的可靠性。

3、這個(gè)ISR變化的信息如何傳遞呢？

1. 由leader所在的broker的isr-expiration定時(shí)任務(wù)，去檢查失效副本和更新zk的/state節(jié)點(diǎn)數(shù)據(jù)，同時(shí)寫入isrChangeSet。

2. isr-change-propagation去檢查isrChangeSet是否有新增數(shù)據(jù)，如果有，則往zk中的/isr_change_notification節(jié)點(diǎn)下創(chuàng)建子節(jié)點(diǎn)。

3. 而Controller對(duì)這個(gè)節(jié)點(diǎn)有一個(gè)Watcher，如果發(fā)現(xiàn)新增了子節(jié)點(diǎn)，那么Controller就會(huì)重新從zk中獲取到最新的元數(shù)據(jù)，然后通知所有Broker更新元數(shù)據(jù)。

從上述過程中，我們還可以知道，實(shí)際上這個(gè)變更的數(shù)據(jù)會(huì)在內(nèi)存中停留一段時(shí)間，假如這個(gè)時(shí)候我們對(duì)應(yīng)的broker宕機(jī)了，那么不就是改了zk卻沒有讓其他broker更新元數(shù)據(jù)嗎？
其實(shí)不是，因?yàn)檫@種情況下，broker宕機(jī)會(huì)觸發(fā)controller在zk下的brokers/ids下對(duì)應(yīng)的節(jié)點(diǎn)被刪除，因此Controller也會(huì)讓其他的broker更新元數(shù)據(jù)，所以無論如何都會(huì)更新。

最后我們來總結(jié)一下整個(gè)ISR剔除的過程：
每個(gè)leader在啟動(dòng)的時(shí)候都會(huì)啟動(dòng)兩個(gè)定時(shí)檢查任務(wù)，每隔一段時(shí)間檢查是否存在失效副本。
如果某個(gè)follower的lastCaughtUpTimeMs > 10s那么就會(huì)被判定為失效副本
如果定時(shí)任務(wù)掃描到存在失效副本時(shí)，就會(huì)往zk的/state節(jié)點(diǎn)下更新最新的ISR列表數(shù)據(jù)，同時(shí)將變更數(shù)據(jù)寫入到內(nèi)存中的isrChangeSet中。
然后另外一個(gè)傳播任務(wù)會(huì)定時(shí)檢查isrChangeSet是否存在需要變更的任務(wù)，如果感知到就往zk的/isr_change_notification節(jié)點(diǎn)下創(chuàng)建子節(jié)點(diǎn)。
最終由Controller感知到節(jié)點(diǎn)的變化，然后從zk中獲取最新的元數(shù)據(jù)，然后通知所有的Broker更新元數(shù)據(jù)，完成整個(gè)ISR列表的數(shù)據(jù)更新。

六、追趕上的副本是如何重新加入ISR中的？

在看完第五小節(jié)之后，第六小節(jié)就會(huì)顯得非常簡單，無非是需要知道什么時(shí)候一個(gè)副本會(huì)重新判定為同步副本呢？ 那就是：當(dāng)前失效follower的LEO等于leaderHW的時(shí)候，即被判斷可以重新加入ISR。

那么隨之而來的一個(gè)問題就是在哪兒去判斷followerLEO == leaderHW的呢？
這里和上面的剔除ISR成員不一樣，并不是由定時(shí)任務(wù)去檢測的，而是在處理完Fetch請(qǐng)求的時(shí)候，如果判斷Fetch請(qǐng)求是follower發(fā)過來的的（replicaId >= 0），那么就會(huì)去看下當(dāng)前這個(gè)follower的LEO是多少（其實(shí)就是Fetch請(qǐng)求帶過來的），是不是趕上了當(dāng)前的leaderHW，如果是的那么就執(zhí)行擴(kuò)張ISR操作。
擴(kuò)張ISR操作流程就和上面流程一樣了，先寫zk下的/state數(shù)據(jù)，然后寫isrChangeSet，最后由Controller感知到數(shù)據(jù)變化，更新集群元數(shù)據(jù)。
我們所需要記住的主要差別點(diǎn)在于，ISR列表的擴(kuò)張是在Fetch請(qǐng)求的時(shí)候去判斷和執(zhí)行的。

七、整個(gè)伸縮過程總結(jié)

最后，我們用圖示來加深一點(diǎn)印象。
1、失效副本（圖源：《深入理解kafka》）：

2、踢出ISR列表：

八、性能優(yōu)化

我們由上可知，ISR的伸縮是需要涉及到zk和Controller以及各個(gè)Broker的元數(shù)據(jù)更新的，因此如果太過頻繁會(huì)造成性能問題。
所以kafka在在判斷ISR伸縮之前，還會(huì)判斷兩個(gè)條件，以此來降低頻率：

• 上次ISR集合發(fā)生變化距離現(xiàn)在已經(jīng)超過5s。

• 上一次寫入zk的時(shí)候，距離現(xiàn)在已經(jīng)超過60s。

如果一個(gè)副本剛追上Leader加入到ISR，但是因?yàn)槎虝r(shí)間內(nèi)沒有追上LEO，5s之后又被檢查到是失效副本，不是又要被踢出去，要更新元數(shù)據(jù)，這樣就太頻繁了。 因此就有了上面兩個(gè)限制，就起碼給了多60s的讓新加入的follower去追上Leader的LEO。

“KAFKA的ISR的伸縮過程是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！