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

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

一、前言

知識點總結(jié)

---

二、概述

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

---

三、什么是失效副本？

功能失效：節(jié)點宕機，在該節(jié)點上的副本都屬于功能失效副本。
同步失效：follower副本所在的broker因為帶寬或者負載等因素無法及時完成同步，導(dǎo)致被踢出ISR。

---

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

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

---

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

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

2、踢出ISR列表：

---

八、性能優(yōu)化

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

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

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

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

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

文章名稱：KAFKA的ISR的伸縮過程是什么
轉(zhuǎn)載來源：http://www.chinadenli.net/article44/geeshe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、網(wǎng)站營銷、移動網(wǎng)站建設(shè)、ChatGPT、網(wǎng)站制作、品牌網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)