第8章kafka可靠性探究

第8章可靠性探究8.1.5為什么不支持讀寫分離在Kafka中，生產(chǎn)者寫入消息、消費(fèi)者讀取消息的操作都是與leader副本進(jìn)行交互的，從而實(shí)現(xiàn)的是一種主寫主讀的生產(chǎn)消費(fèi)模型。數(shù)據(jù)庫、Redis等都具備主寫主讀的功能，與此同時(shí)還支持主寫從讀的功能，主寫從讀也就是讀寫分離，為了與主寫主讀對(duì)應(yīng)，這里就以主寫從讀來稱呼。Kafka并不支持主寫從讀，這是為什么呢？從代碼層面上來說，雖然增加了代碼復(fù)雜度，但在Kafka中這種功能完全可以支持。對(duì)于這個(gè)問題，我們可以從“收益點(diǎn)”這個(gè)角度來做具體分析。主寫從讀可以讓從節(jié)點(diǎn)去分擔(dān)主節(jié)點(diǎn)的負(fù)載壓力，預(yù)防主節(jié)點(diǎn)負(fù)載過重而從節(jié)點(diǎn)卻空閑的情況發(fā)生。但是主寫從讀也有2個(gè)很明顯的缺點(diǎn)：數(shù)據(jù)一致性問題。數(shù)據(jù)從主節(jié)點(diǎn)轉(zhuǎn)到從節(jié)點(diǎn)必然會(huì)有一個(gè)延時(shí)的時(shí)間窗口，這個(gè)時(shí)間窗口會(huì)導(dǎo)致主從節(jié)點(diǎn)之間的數(shù)據(jù)不一致。某一時(shí)刻，在主節(jié)點(diǎn)和從節(jié)點(diǎn)中A數(shù)據(jù)的值都為x,之后將主節(jié)點(diǎn)中A的值修改為Y，那么在這個(gè)變更通知到從節(jié)點(diǎn)之前，應(yīng)用讀取從節(jié)點(diǎn)中的A數(shù)據(jù)的值并不為最新的Y，由此便產(chǎn)生了數(shù)據(jù)不一致的問題。延時(shí)問題。類似Redis這種組件，數(shù)據(jù)從寫入主節(jié)點(diǎn)到同步至從節(jié)點(diǎn)中的過程需要經(jīng)歷網(wǎng)絡(luò)一主節(jié)點(diǎn)內(nèi)存一網(wǎng)絡(luò)一從節(jié)點(diǎn)內(nèi)存這幾個(gè)階段，整個(gè)過程會(huì)耗費(fèi)一定的時(shí)間。而在Kafka中，主從同步會(huì)比Redis更加耗時(shí)，它需要經(jīng)歷網(wǎng)絡(luò)一主節(jié)點(diǎn)內(nèi)存一主節(jié)點(diǎn)磁盤一網(wǎng)絡(luò)一從節(jié)點(diǎn)內(nèi)存一從節(jié)點(diǎn)磁盤這幾個(gè)階段。對(duì)延時(shí)敏感的應(yīng)用而言，主寫從讀的功能并不太適用?，F(xiàn)實(shí)情況下，很多應(yīng)用既可以忍受一定程度上的延時(shí)，也可以忍受一段時(shí)間內(nèi)的數(shù)據(jù)不一致的情況，那么對(duì)于這種情況，Kafka是否有必要支持主寫從讀的功能呢？主讀從寫可以均攤一定的負(fù)載卻不能做到完全的負(fù)載均衡，比如對(duì)于數(shù)據(jù)寫壓力很大而讀壓力很小的情況，從節(jié)點(diǎn)只能分?jǐn)偤苌俚呢?fù)載壓力，而絕大多數(shù)壓力還是在主節(jié)點(diǎn)上。而在Kafka中卻可以達(dá)到很大程度上的負(fù)載均衡，而且這種均衡是在主寫主讀的架構(gòu)上實(shí)現(xiàn)的。我們來看一下Kafka的生產(chǎn)消費(fèi)模型，如圖8-23所示。如圖8-23所示，在Kafka集群中有3個(gè)分區(qū)，每個(gè)分區(qū)有3個(gè)副本，正好均勻地分布在3第8章可靠性探究I299個(gè)broker上，灰色陰影的代表leader副本，非灰色陰影的代表follower副本，虛線表示follower副本從leader副本上拉取消息。當(dāng)生產(chǎn)者寫入消息的時(shí)候都寫入leader副本，對(duì)于圖8-23中的情形，每個(gè)broker都有消息從生產(chǎn)者流入；當(dāng)消費(fèi)者讀取消息的時(shí)候也是從leader副本中讀取的，對(duì)于圖8-23中的情形，每個(gè)broker都有消息流出到消費(fèi)者。我們很明顯地可以看出，每個(gè)broker上的讀寫負(fù)載都是一樣的，這就說明Kafka可以通過主寫主讀實(shí)現(xiàn)主寫從讀實(shí)現(xiàn)不了的負(fù)載均衡。圖8-23展示是一種理想的部署情況，有以下幾種情況（包含但不僅限于〉會(huì)造成一定程度上的負(fù)載不均衡：⑴broker端的分區(qū)分配不均。當(dāng)創(chuàng)建主題的時(shí)候可能會(huì)出現(xiàn)某些broker分配到的分區(qū)數(shù)多而其他broker分配到的分區(qū)數(shù)少，那么自然而然地分配到的leader副本也就不均。（2生產(chǎn)者寫入消息不均。生產(chǎn)者可能只對(duì)某些broker中的leader副本進(jìn)行大量的寫入操作，而對(duì)其他broker中的leader副本不聞不問。（3）消費(fèi)者消費(fèi)消息不均。消費(fèi)者可能只對(duì)某些broker中的leader副本進(jìn)行大量的拉取操作，而對(duì)其他broker中的leader副本不聞不問。⑷leader副本的切換不均。在實(shí)際應(yīng)用中可能會(huì)由于broker巖機(jī)而造成主從副本的切換，或者分區(qū)副本的重分配等，這些動(dòng)作都有可能造成各個(gè)broker中l(wèi)eader副本的分配不均對(duì)此，我們可以做一些防范措施。針對(duì)第一種情況，在主題創(chuàng)建的時(shí)候盡可能使分區(qū)分配得均衡，好在Kafka中相應(yīng)的分配算法也是在極力地追求這一目標(biāo)，如果是開發(fā)人員自定義的分配，則需要注意這方面的內(nèi)容。對(duì)于第二和第三種情況，主寫從讀也無法解決。對(duì)于第四種情況，Kafka提供了優(yōu)先副本的選舉來達(dá)到leader副本的均衡，與此同時(shí)，也可以配合相應(yīng)的監(jiān)控、告警和運(yùn)維平臺(tái)來實(shí)現(xiàn)均衡的優(yōu)化。在實(shí)際應(yīng)用中，配合監(jiān)控、告警、運(yùn)維相結(jié)合的生態(tài)平臺(tái)，在絕大多數(shù)情況下Kafka都能做到很大程度上的負(fù)載均衡?？偟膩碚f，Kafka只支持主寫主讀有幾個(gè)優(yōu)點(diǎn)：可以簡化代碼的實(shí)現(xiàn)邏輯，減少出錯(cuò)的可能；將負(fù)載粒度細(xì)化均攤，與主寫從讀相比，不僅負(fù)載效能更好，而且對(duì)用戶可控；沒有延時(shí)的影響；在副本穩(wěn)定的情況下，不會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。為此，Kafka又何必再去實(shí)現(xiàn)對(duì)它而言毫無收益的主寫從讀的功能呢？這一切都得益于Kafka優(yōu)秀的架構(gòu)設(shè)計(jì)，從某種意義上來說，主寫從讀是由于設(shè)計(jì)上的缺陷而形成的權(quán)宣之計(jì)。8.2日志同步機(jī)制在分布式系統(tǒng)中，日志同步機(jī)制既要保證數(shù)據(jù)的一致性，也要保證數(shù)據(jù)的順序性。雖然有許多方式可以實(shí)現(xiàn)這些功能，但最簡單高效的方式還是從集群中選出一個(gè)leader來負(fù)責(zé)處理數(shù)據(jù)寫入的！I說序性。只要leader還處于存活狀態(tài)，那么follower只需按照leader中的寫入順序來進(jìn)行同步即可。300I深入理解Kafka:核心設(shè)計(jì)與實(shí)踐原理通常情況下，只要leader不著機(jī)我們就不需要關(guān)心環(huán)llower的同步問題。不過當(dāng)leader巖機(jī)時(shí)，我們就要從follower中選舉出一個(gè)新的leaderfollower的同步狀態(tài)可能落后leader很多，甚至還可能處于窯機(jī)狀態(tài)，所以必須確保選擇具有最新日志消息的follower作為新的leader。日志同步機(jī)制的一個(gè)基本原則就是：如果告知客戶端已經(jīng)成功提交了某條消息，那么即使leader巖機(jī)，也要保證新選舉出來的leader中能夠包含這條消息。這里就有一個(gè)需要權(quán)衡（tradeoff）的地方，如果leader在消息被提交前需要等待更多的follower確認(rèn)，那么在它巖機(jī)之后就可以有更多的follower替代它，不過這也會(huì)造成性能的下降。對(duì)于這種tradeo筐，一種常見的做法是“少數(shù)服從多數(shù)”，它可以用來負(fù)責(zé)提交決策和選舉決策。雖然Kafka不采用這種方式，但可以拿來探討和理解tradeoff的藝術(shù)。在這種方式下，如果我們有2f+l個(gè)副本，那么在提交之前必須保證有軒1個(gè)副本同步完消息。同時(shí)為了保證能正確選舉出新的leader，至少要保證有f+l個(gè)副本節(jié)點(diǎn)完成日志同步井從同步完成的副本中選舉出新的leader節(jié)點(diǎn)。并且在不超過f個(gè)副本節(jié)點(diǎn)失敗的情況下，新的leader需要保證不會(huì)丟失己經(jīng)提交過的全部消息。這樣在任意組合的f+l個(gè)副本中，理論上可以確保至少有一個(gè)副本能夠包含己提交的全部消息，這個(gè)副本的日志擁有最全的消息，因此會(huì)有資格被選舉為新的leader來對(duì)外提供服務(wù)?！吧贁?shù)服從多數(shù)”的方式有一個(gè)很大的優(yōu)勢，系統(tǒng)的延遲取決于最快的幾個(gè)節(jié)點(diǎn)，比如副本數(shù)為3，那么延遲就取決于最快的那個(gè)follower而不是最慢的那個(gè)（除了】eader，只需要另一個(gè)follower確認(rèn)即可〉。不過它也有一些劣勢，為了保證leader選舉的正常進(jìn)行，它所能容忍的失敗follower數(shù)比較少，如果要容忍l個(gè)follower失敗，那么至少要有3個(gè)副本，如果要容忍2個(gè)follower失敗，必須要有5個(gè)副本。也就是說，在生產(chǎn)環(huán)境下為了保證較高的容錯(cuò)率，必須要有大量的副本，而大量的副本又會(huì)在大數(shù)據(jù)量下導(dǎo)致性能的急劇下降。這也就是“少數(shù)服從多數(shù)”的這種Quorum模型常被用作共享集群配置（比如ZooKeeper），而很少用于主流的數(shù)據(jù)存儲(chǔ)中的原因。與“少數(shù)服從多數(shù)”相關(guān)的一致性協(xié)議有很多，比如Zab、Raft和ViewstampedReplication等。而Kafka使用的更像是微軟的PacificA算法。在Kafka中動(dòng)態(tài)維護(hù)著一個(gè)ISR集合，處于ISR集合內(nèi)的節(jié)點(diǎn)保持與leader相同的高水位CHW），只有位列其中的副本（unclean.leader.elect工on.enable配置為false）才有資格被選為新的leadera寫入消息時(shí)只有等到所有ISR集合中的副本都確認(rèn)收到之后才能被認(rèn)為已經(jīng)提交。位于ISR中的任何副本節(jié)點(diǎn)都有資格成為leader，選舉過程簡單（詳細(xì)內(nèi)容可以參考6.4.3節(jié)〉、開銷低，這也是Kafka選用此模型的重要因素。Kafka中包含大量的分區(qū)，leader副本的均衡保障了整體負(fù)載的均衡，所以這一因素也極大地影響Kafka的性能指標(biāo)。在采用ISR模型和（f+l）個(gè)副本數(shù)的配置下，一個(gè)Kafka分區(qū)能夠容忍最大f個(gè)節(jié)點(diǎn)失敗，相比于“少數(shù)服從多數(shù)”的方式所需的節(jié)點(diǎn)數(shù)大幅減少。實(shí)際上，為了能夠容忍f個(gè)節(jié)點(diǎn)失敗，第8章可靠性探究【301“少數(shù)服從多數(shù)”的方式和ISR的方式都需要相同數(shù)量副本的確認(rèn)信息才能提交消息。比如，為了容忍l個(gè)節(jié)點(diǎn)失敗，“少數(shù)服從多數(shù)”需要3個(gè)副本和l個(gè)follower的確認(rèn)信息，采用ISR的方式需要2個(gè)副本和l個(gè)follower的確認(rèn)信息。在需要相同確認(rèn)信息數(shù)的情況下，采用ISR的方式所需要的副本總數(shù)變少，復(fù)制帶來的集群開銷也就更低，“少數(shù)服從多數(shù)”的優(yōu)勢在于它可以繞開最慢副本的確認(rèn)信息，降低提交的延遲，而對(duì)Kafka而言，這種能力可以交由客戶端自己去選擇。另外，一般的同步策略依賴于穩(wěn)定的存儲(chǔ)系統(tǒng)來做數(shù)據(jù)恢復(fù)，也就是說，在數(shù)據(jù)恢復(fù)時(shí)日志文件不可丟失且不能有數(shù)據(jù)上的沖突。不過它們忽視了兩個(gè)問題：首先，磁盤故障是會(huì)經(jīng)常發(fā)生的，在持久化數(shù)據(jù)的過程中并不能完全保證數(shù)據(jù)的完整性；其次，即使不存在硬件級(jí)別的故障，我們也不希望在每次寫入數(shù)據(jù)時(shí)執(zhí)行同步刷盤（fsync）的動(dòng)作來保證數(shù)據(jù)的完整性，這樣會(huì)極大地影響性能。而Kafka不需要巖機(jī)節(jié)點(diǎn)必須從本地?cái)?shù)據(jù)日志、中進(jìn)行恢復(fù)，Kafka的同步方式允許宿機(jī)副本重新加入ISR集合，但在進(jìn)入ISR之前必須保證自己能夠重新同步完leader中的所有數(shù)據(jù)。8.3可靠性分析很多人問過筆者類似這樣的一些問題：怎樣可以確保Kafka完全可靠？如果這樣做就可以確保消息不丟失了嗎？筆者認(rèn)為：就可靠性本身而言，它并不是一個(gè)可以用簡單的“是”或“否”來衡量的一個(gè)指標(biāo)，而一般是采用幾個(gè)9來衡量的。任何東西不可能做到完全的可靠，即使能應(yīng)付單機(jī)故障，也難以應(yīng)付集群、數(shù)據(jù)中心等集體故障，即使躲得過天災(zāi)也未必躲得過人禍。就可靠性而言，我們可以基于一定的假設(shè)前提來做分析。本節(jié)要講述的是：在只考慮Kafka本身使用方式的前提下如何最大程度地提高可靠性。就Kafka而言，越多的副本數(shù)越能夠保證數(shù)據(jù)的可靠性，副本數(shù)可以在創(chuàng)建主題時(shí)配置，也可以在后期修改，不過副本數(shù)越多也會(huì)引起磁盤、網(wǎng)絡(luò)帶寬的浪費(fèi)，同時(shí)會(huì)引起性能的下降。一般而言，設(shè)置副本數(shù)為3即可滿足絕大多數(shù)場景對(duì)可靠性的要求，而對(duì)可靠性要求更高的場景下，可以適當(dāng)增大這個(gè)數(shù)值，比如國內(nèi)部分銀行在使用Kafka時(shí)就會(huì)設(shè)置副本數(shù)為5。與此同時(shí)，如果能夠在分配分區(qū)副本的時(shí)候引入基架信息（broker.rack參數(shù)），那么還要應(yīng)對(duì)機(jī)架整體巖機(jī)的風(fēng)險(xiǎn)。僅依靠副本數(shù)來支撐可靠性是遠(yuǎn)遠(yuǎn)不夠的，大多數(shù)人還會(huì)想到生產(chǎn)者客戶端參數(shù)acks。在2.3節(jié)中我們就介紹過這個(gè)參數(shù)：相比于0和Lacks=-1（客戶端還可以配置為all，它的含義與一l一樣，以下只以1來進(jìn)行陳述〉可以最大程度地提高消息的可靠性。對(duì)于acks=1的配置，生產(chǎn)者將消息發(fā)送到leader副本，leader副本在成功寫入本地日志之

后會(huì)告知生產(chǎn)者己經(jīng)成功提交，如圖8-24所示。如果此時(shí)ISR集合的follower副本還沒來得及拉取到leader中新寫入的消息，leader就看機(jī)了，那么此次發(fā)迭的消息就會(huì)丟失。302I深入理解Kafka:核心設(shè)計(jì)與實(shí)踐原理①肖塞目入Iea6ef副本2后，folfcwr胡本宰投取凱夏逢行同步用XMacks-l的階置情形氣〉。Producer寫入消恩3加4eaderfollDwerlfoilower?I斷厄原加Ik）gr1\HW[LEO2folloMriElog口(oUcwedX并道有舊a如盜學(xué)遂RMlowef避沒有來得及fetchSleader的At折消息.①肖塞目入Iea6ef副本2后，folfcwr胡本宰投取凱夏逢行同步用XMacks-l的階置情形氣〉。Producer寫入消恩3加4eaderfollDwerlfoilower?I斷厄原加Ik）gr1\HW[LEO2folloMriElog口(oUcwedX并道有舊a如盜學(xué)遂RMlowef避沒有來得及fetchSleader的At折消息.電30取就客機(jī)了follower?HWJLEO—001122⑤心的VE當(dāng)覽為酷的leader但是此時(shí)LE。仍為3,Producer發(fā)遙的洛懸電5蕓夫?qū)τ赼ck=一l的配置，生產(chǎn)者將消息發(fā)送到leader副本，leader副本在成功寫入本地日志之后還要等待ISR中的follower副本全部同步完成才能夠告知生產(chǎn)者已經(jīng)成功提交，即使此時(shí)leader副本君機(jī)，消息也不會(huì)丟失，如圖8-25所示。?leader寶生名機(jī)，再蓋從1SR中造翠出一個(gè)folio神日成為籍的ledilerhTW昆直當(dāng)通.消息部不嘗丟失國S-25acks--[的配宜情毋（成功）電fdlowodtojtower?HWfLEOHW|L￡O00112223334A4③舊10岫普部同輯完成西ffnw坦盤吾戶持成功有志在2.1.2節(jié)中，我們討論了消息發(fā)送的3種模式，即發(fā)后即忘、同步和異步。對(duì)于發(fā)后即忘的模式，不管消息有沒有被成功寫入，生產(chǎn)者都不會(huì)收到通知，那么即使消息寫入失敗也無從得知，因此發(fā)后即忘的模式不適合高可靠性要求的場景。如果要提升可靠性，那么生產(chǎn)者可以采用同步或異步的模式，在出現(xiàn)異常情況時(shí)可以及時(shí)獲得通知，以便可以做相應(yīng)的補(bǔ)救措施，比如選擇重試發(fā)送（可能會(huì)引起消息重復(fù)）。有些發(fā)送異常屬于可重試異常，比如NetworkException，這個(gè)可能是由瞬時(shí)的網(wǎng)絡(luò)故障而導(dǎo)致的，一般通過重試就可以解決。對(duì)于這類異常，如果直接拋給客戶端的使用方也未免過于興師動(dòng)眾，客戶端內(nèi)部本身提供了重試機(jī)制來應(yīng)對(duì)這種類型的異常，通過retries參數(shù)即可配置。默認(rèn)情況下，retries參數(shù)設(shè)置為0，即不進(jìn)行重試，對(duì)于高可靠性要求的場景，需要將這個(gè)值設(shè)置為大于0的值，在2.3節(jié)中也談到了與retries參數(shù)相關(guān)的還有一個(gè)retry.backoff.ms參數(shù)，它用來設(shè)定兩次重試之間的時(shí)間間隔，以此避免無效的頻繁重試。在配置retries和retry.backoff.ms之前，最好先估算一下可能的異?；謴?fù)時(shí)間，這樣可以設(shè)定總的重試時(shí)間大于這個(gè)異?；謴?fù)時(shí)間，以此來避免生產(chǎn)者過早地放棄重試。如果不知道retries參數(shù)應(yīng)該配置為多少，則可以參考KafkaAdminClient，在KafkaAdminClient中retries參數(shù)的默認(rèn)值為5。注意如果配置的retries參數(shù)值大于0，則可能引起一些負(fù)面的影響。首先同2.3節(jié)中談及的一樣，由于默認(rèn)的max.川.fl工ght.requests.per.connection參數(shù)值為5，這樣可能會(huì)影響消息的順序性，對(duì)此要么放棄客戶端內(nèi)部的重試功能，要么將max.in.flight.requests.per.connection參數(shù)設(shè)置為l，這樣也就放棄了吞吐。其次，有些應(yīng)用對(duì)于時(shí)延的要求很高，很多時(shí)候都是需要快速失敗的，設(shè)置retries>0會(huì)增加客戶端對(duì)于異常的反饋時(shí)延，如此可能會(huì)對(duì)應(yīng)用造成不良的影響。我們回頭再來看一下acks=寸的情形，它要求ISR中所有的副本都收到相關(guān)的消息之后才304I深入理解Kafka:核心設(shè)計(jì)與實(shí)踐原理能夠告知生產(chǎn)者己經(jīng)成功提交。試想一下這樣的情形，leader副本的消息流入速度很快，而follower副本的同步速度很慢，在某個(gè)臨界點(diǎn)時(shí)所有的follower副本都被剔除出了ISR集合，那么ISR中只有一個(gè)leader副本，最終acks=一】演變?yōu)閍cks=1的情形，如此也就加大了消息丟失的風(fēng)險(xiǎn)。Kafka也考慮到了這種情況，并為此提供了min.insync.replicas參數(shù)（默認(rèn)值為1）來作為輔助（配合acks=-1來使用〉，這個(gè)參數(shù)指定了ISR集合中最小的副本數(shù)，如果不滿足條件就會(huì)拋出NotEnoughReplicasException或NotEnoughReplicasAfterAppendException在正常的配置下，需要滿足副本數(shù)〉min.i口sync.replicas參數(shù)的值。一個(gè)典型的配置方案為：副本數(shù)配置為3,min.工nsync.replicas參數(shù)值配置為2o注意min.insync.replicas參數(shù)在提升可靠性的時(shí)候會(huì)從側(cè)面影響可用性。試想如果ISR中只有一個(gè)leader副本，那么最起碼還可以使用，而此時(shí)如果配置mXn.insync.replicas>l，則會(huì)使消息無法寫入。與可靠性和ISR集合有關(guān)的還有一個(gè)參數(shù)一一unclean.leader.election.enable。這個(gè)參數(shù)的默認(rèn)值為false，如果設(shè)置為true就意味著當(dāng)leader下線時(shí)候可以從非ISR集合中選舉出新的leader，這樣有可能造成數(shù)據(jù)的丟失。如果這個(gè)參數(shù)設(shè)置為false，那么也會(huì)影響可用性，非ISR集合中的副本雖然沒能及時(shí)同步所有的消息，但最起碼還是存活的可用副本。隨著Kafka版本的變更，有的參數(shù)被淘汰，也有新的參數(shù)加入進(jìn)來，而傳承下來的參數(shù)一般都很少會(huì)修改既定的默認(rèn)值，而unclean.leader.election.enable就是這樣一個(gè)反例，從版本開始，unclean.leader.el