第8章kafka可靠性探究

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

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