一、前言

自上次師兄遭受了面試官 「Kafka」 的暴擊追問后，回來發(fā)奮圖強，企圖“「吊打面試官」”，奈何還是面試官套路深啊，最近的面試，又被問到「知識盲點」了！讓我們一起來看看，可憐的師兄又遇到了哪些讓人頭禿的問題 {{{(>_

二、面試題

「關(guān)于消息隊列(基礎(chǔ))」

?

常用的消息隊列有哪些 ? 為何使用消息隊列 ? Kafka與傳統(tǒng)的消息隊列服務(wù)有什么不同?

?

「關(guān)于Kafak存儲機制與讀寫流程」

?

Kafka的讀寫流程
Kafka的文件結(jié)構(gòu) broker存儲數(shù)據(jù)有哪些？Kafka怎么保證partition的偏移量？follower參加讀寫嗎？Kafka為什么只讓leader進行讀寫？如果讓follower也可以讀寫，會怎么樣？

?

「關(guān)于Kafak數(shù)據(jù)可靠性的保證」

?

Kafak是怎么實現(xiàn)對offset的索引 ack設(shè)為1的時候，producer生產(chǎn)數(shù)據(jù)時候，leader接受到數(shù)據(jù)，返回ack之后，leader宕機了，那么數(shù)據(jù)是否就丟失了？ack配置成-1是不是數(shù)據(jù)一定會進磁盤？是不是不管怎么是設(shè)置ack還是有概率丟失消息?

?

「關(guān)于Kafak高可用性」

?

簡要描述Kafak數(shù)據(jù)高可用的原理是什么 一個topic三個broker一個leader，leader所在的broker掛了，選舉原則是什么？Kafka api low-level與high-level有什么區(qū)別，使用low-level api需要處理哪些細節(jié)？

??

以上，「便是和師兄聊到了一些他踩坑的面試題和一些同類型的面試題」，我進行了整理。說實話，如果不深入的了解Kafak，我想小伙伴們在面試時多半是要踩雷的，當(dāng)然也包括我！(ノへ￣、) 所以，為了避免被面試官瘋狂吊打，我們還做好充分準(zhǔn)備，不求”翻身做主“，但求旗鼓相當(dāng)，那樣Offer輕松到手豈不妙哉！

?

三、思路

還是和上一篇博客一樣 師兄大廠面試遇到面試官的 Kafka 暴擊三連問，快面哭了！我個人建議，大家最好先搭建一個技術(shù)棧完整的知識框架，這樣在面試時就能做到無懈可擊啦！

四、關(guān)于消息隊列

4.1 Kafka創(chuàng)建背景

Kafka是一個消息系統(tǒng)，原本開發(fā)自LinkedIn，用作LinkedIn的活動流(Activity Stream)和運營數(shù)據(jù)處理管道(Pipeline)的基礎(chǔ)。現(xiàn)在它已被多家不同類型的公司「作為多種類型的數(shù)據(jù)管道和消息系統(tǒng)」使用。

「活動流數(shù)據(jù)」是幾乎所有站點在對其網(wǎng)站使用情況做報表時都要用到的數(shù)據(jù)中最常規(guī)的部分。「這種數(shù)據(jù)通常的處理方式是先把各種活動以日志的形式寫入某種文件，然后周期性地對這些文件進行統(tǒng)計分析」。近年來，活動和運營數(shù)據(jù)處理已經(jīng)成為了網(wǎng)站軟件產(chǎn)品特性中一個至關(guān)重要的組成部分，這就需要一套稍微更加復(fù)雜的基礎(chǔ)設(shè)施對其提供支持，Kafka也就應(yīng)運而生。

4.2 為何使用消息隊列

• 「解耦」在項目啟動之初來預(yù)測將來項目會碰到什么需求，是極其困難的。消息系統(tǒng)在處理過程中間插入了一個隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實現(xiàn)這一接口。這允許你獨立的擴展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。

• 「冗余」有些情況下，處理數(shù)據(jù)的過程會失敗。除非數(shù)據(jù)被持久化，否則將造成丟失。消息隊列把數(shù)據(jù)進行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險。許多消息隊列所采用的“插入-獲取-刪除”范式中，在把一個消息從隊列中刪除之前，需要你的處理系統(tǒng)明確的指出該消息已經(jīng)被處理完畢，從而確保你的數(shù)據(jù)被安全的保存直到你使用完畢。

• 「擴展性」因為消息隊列解耦了你的處理過程，所以增大消息入隊和處理的頻率是很容易的，只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。擴展就像調(diào)大電力按鈕一樣簡單。

• 「靈活性 & 峰值處理能力」在訪問量劇增的情況下，應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時待命無疑是巨大的浪費。使用消息隊列能夠使關(guān)鍵組件頂住突發(fā)的訪問壓力，而不會因為突發(fā)的超負(fù)荷的請求而完全崩潰。

• 「可恢復(fù)性」系統(tǒng)的一部分組件失效時，不會影響到整個系統(tǒng)。消息隊列降低了進程間的耦合度，所以即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。

• 「順序保證」在大多使用場景下，數(shù)據(jù)處理的順序都很重要。大部分消息隊列本來就是排序的，并且能保證數(shù)據(jù)會按照特定的順序來處理。Kafka保證一個Partition內(nèi)的消息的有序性。

• 「緩沖」在任何重要的系統(tǒng)中，都會有需要不同的處理時間的元素。例如，加載一張圖片比應(yīng)用過濾器花費更少的時間。消息隊列通過一個緩沖層來幫助任務(wù)最高效率的執(zhí)行———寫入隊列的處理會盡可能的快速。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。

• 「異步通信」很多時候，用戶不想也不需要立即處理消息。消息隊列提供了異步處理機制，允許用戶把一個消息放入隊列，但并不立即處理它。想向隊列中放入多少消息就放多少，然后在需要的時候再去處理它們。

4.3 和常用消息隊列的對比

• 「RabbitMQ」RabbitMQ是使用Erlang編寫的一個開源的消息隊列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量級，更適合于企業(yè)級的開發(fā)。同時實現(xiàn)了Broker構(gòu)架，這意味著消息在發(fā)送給客戶端時先在中心隊列排隊。對路由，負(fù)載均衡或者數(shù)據(jù)持久化都有很好的支持。

• 「Redis」Redis是一個基于Key-Value對的NoSQL數(shù)據(jù)庫，開發(fā)維護很活躍。雖然它是一個Key-Value數(shù)據(jù)庫存儲系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個輕量級的隊列服務(wù)來使用。對于RabbitMQ和Redis的入隊和出隊操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個不同大小的數(shù)據(jù)。實驗表明：入隊時，當(dāng)數(shù)據(jù)比較小時Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊時，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊性能則遠低于Redis。

• 「ZeroMQ」ZeroMQ號稱最快的消息隊列系統(tǒng)，尤其針對大吞吐量的需求場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級/復(fù)雜的隊列，但是開發(fā)人員需要自己組合多種技術(shù)框架，技術(shù)上的復(fù)雜度是對這MQ能夠應(yīng)用成功的挑戰(zhàn)。ZeroMQ具有一個獨特的非中間件的模式，你不需要安裝和運行一個消息服務(wù)器或中間件，因為你的應(yīng)用程序?qū)缪葸@個服務(wù)器角色。你只需要簡單的引用ZeroMQ程序庫，可以使用NuGet安裝，然后你就可以愉快的在應(yīng)用程序之間發(fā)送消息了。但是ZeroMQ僅提供非持久性的隊列，也就是說如果宕機，數(shù)據(jù)將會丟失。其中，Twitter的Storm 0.9.0以前的版本中默認(rèn)使用ZeroMQ作為數(shù)據(jù)流的傳輸(Storm從0.9版本開始同時支持ZeroMQ和Netty作為傳輸模塊)。

• 「ActiveMQ」ActiveMQ是Apache下的一個子項目。類似于ZeroMQ，它能夠以代理人和點對點的技術(shù)實現(xiàn)隊列。同時類似于RabbitMQ，它少量代碼就可以高效地實現(xiàn)高級應(yīng)用場景。

• 「Kafka/Jafka」Kafka是Apache下的一個子項目，是一個高性能跨語言分布式發(fā)布/訂閱消息隊列系統(tǒng)，而Jafka是在Kafka之上孵化而來的，即Kafka的一個升級版。具有以下特性：快速持久化，可以在O(1)的系統(tǒng)開銷下進行消息持久化；高吞吐，在一臺普通的服務(wù)器上既可以達到10W/s的吞吐速率；完全的分布式系統(tǒng)，Broker、Producer、Consumer都原生自動支持分布式，自動實現(xiàn)負(fù)載均衡；支持Hadoop數(shù)據(jù)并行加載，對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實時處理的限制，這是一個可行的解決方案。Kafka通過Hadoop的并行加載機制統(tǒng)一了在線和離線的消息處理。Apache Kafka相對于ActiveMQ是一個非常輕量級的消息系統(tǒng)，除了性能非常好之外，還是一個工作良好的分布式系統(tǒng)。

4.4 總結(jié)

關(guān)于 Kafka 和傳統(tǒng)消息隊列有何不同，在上一篇文章中已經(jīng)做出部分解答，這里我就不再贅述。「一般情況下，Kafka應(yīng)用在大數(shù)據(jù)日志處理或?qū)崟r性(少量延遲)，可靠性(少量丟數(shù)據(jù))要求稍低的場景使用」。

五、關(guān)于Kafka存儲機制與讀寫流程

5.1 Kafka存儲機制

在Kafka 架構(gòu)深入已經(jīng)講明了這個問題，但這張圖的結(jié)構(gòu)更易于理解，如下。

• 「Broker」：消息中間件處理結(jié)點，一個Kafka節(jié)點就是一個broker，多個broker可以組成一個Kafka集群。
• 「Topic」：一類消息，例如page view日志、click日志等都可以以topic的形式存在，Kafka集群能夠同時負(fù)責(zé)多個topic的分發(fā)。
• 「Partition」：topic物理上的分組，一個topic可以分為多個partition，每個partition是一個有序的隊列。
• 「Segment」：partition物理上由多個segment組成。

Kafka用topic對消息進行歸類，每一個topic可以分為多個分區(qū)，分區(qū)中的消息不重復(fù)，每個分區(qū)又有很多個segment(段)，「segment是在磁盤上就是一對文件，包含index和log文件，兩種文件名相同，后綴不同」。

「每個topic的第一個segment的兩種文件都是00000000000000000000.index和00000000000000000000.log，后來新產(chǎn)生的文件名都以上一個segment中最后一條消息的offset(偏移量)結(jié)尾，不足20個字符的用0填充。」

「Tip：Kafka數(shù)據(jù)被消費后雖然不會被立即刪除，但不可能一直不刪除，Kafka根據(jù)兩個設(shè)置定時檢測做刪除操作」：

基于時間：log.retention.hours=168

基于大小：log.retention.bytes=1073741824

「滿足任何一個都會刪除之前的segment，記住不是刪除某一個消息，刪除的最小單位是segment。」

以上面的Segment文件為例，展示出Segment：00000000000000170410的index文件和log文件的對應(yīng)的關(guān)系，如下圖：

如上圖，「index索引文件存儲大量的元數(shù)據(jù)，log數(shù)據(jù)文件存儲大量的消息，索引文件中的元數(shù)據(jù)指向?qū)?yīng)數(shù)據(jù)文件中message的物理偏移地址。」

?

「如何根據(jù)索引文件元數(shù)據(jù)定位數(shù)據(jù)位置？」
如：index索引文件元數(shù)據(jù)[3,348]，在log數(shù)據(jù)文件中表示第3個消息，在全局partition中表示170410+3=170413個消息，該條消息在相應(yīng)log文件中的物理偏移地址為348。

「那么如何從partition中通過offset查找message呢？」
如：讀取offset=170418的消息，查找segment文件，其中，
α. 00000000000000000000.index為最開始的文件，
β. 00000000000000170410.index(start offset=170410+1=170411)，
γ. 00000000000000239430.index(start offset=239430+1=239431)，
因此，定位offset=170418在00000000000000170410.index索引文件中。其他后續(xù)文件可以依次類推，以偏移量命名并排列這些文件，然后根據(jù)二分查找法就可以快速定位到具體文件位置。其次，根據(jù)00000000000000170410.index文件中的[8,1325]定位到00000000000000170410.log文件中的1325的位置進行讀取。

「那么怎么知道何時讀完本條消息，否則就讀到下一條消息的內(nèi)容了？」
因為消息都具有固定的物理結(jié)構(gòu)，包括：offset(8 Bytes)、消息體的大小(4 Bytes)、crc32(4 Bytes)、magic(1 Byte)、attributes(1 Byte)、key length(4 Bytes)、key(K Bytes)、payload(N Bytes)等等字段，可以確定一條消息的大小，即讀取到哪里截止。

?

5.2 讀寫流程

「寫流程：」

1.連接ZK集群，從ZK中拿到對應(yīng)topic的partition信息和partition的Leader的相關(guān)信息

2.連接到對應(yīng)Leader對應(yīng)的broker

3.將消息發(fā)送到partition的Leader上

4.其他Follower從Leader上復(fù)制數(shù)據(jù)

5.依次返回ACK

6.直到所有ISR中的數(shù)據(jù)寫完成，才完成提交，整個寫過程結(jié)束

因為是描述寫流程，沒有將replica與ZK的心跳通訊表達出來，心跳通訊就是為了保證kafka高可用。一旦Leader掛了，或者Follower同步超時或者同步過慢，都會通過心跳將信息報告給ZK，由ZK做Leader選舉或者將Follower從ISR中移動到OSR中。

「讀流程：」

1.連接ZK集群，從ZK中拿到對應(yīng)topic的partition信息和partition的Leader的相關(guān)信息

2.連接到對應(yīng)Leader對應(yīng)的broker

3.consumer將自己保存的offset發(fā)送給Leader

4.Leader根據(jù)offset等信息定位到segment(索引文件和日志文件)

5.根據(jù)索引文件中的內(nèi)容，定位到日志文件中該偏移量對應(yīng)的開始位置讀取相應(yīng)長度的數(shù)據(jù)并返回給consumer

5.3 ?Kafka數(shù)據(jù)一致性

「數(shù)據(jù)一致性：Kafka是保存副本 leader讀寫，follower只備份；而 zookeeper是 leader讀寫，follower負(fù)責(zé)讀」 。

看到一位博主對 Kafka和Zookeeper 數(shù)據(jù)一致性 分析的很詳細，大家可以學(xué)習(xí)下，這里我參考了關(guān)于Kafka的部分。

「Kafka」，「只有l(wèi)eader 負(fù)責(zé)讀寫，follower只負(fù)責(zé)備份！！！」，「如果leader宕機的話,Kafaka動態(tài)維護了一個同步狀態(tài)的副本的集合(a set of in-sync replicas)」，簡稱「ISR」，「ISR中有f+1個節(jié)點，就可以允許在f個節(jié)點down掉的情況下不會丟失消息并正常提供服」。「ISR的成員是動態(tài)的，如果一個節(jié)點被淘汰了，當(dāng)它重新達到“同步中”的狀態(tài)時，他可以重新加入ISR。因此如果leader宕了，直接從ISR中選擇一個follower就行。」

Kafka在引入Replication之后，同一個Partition可能會有多個Replica，而這時需要「在這些Replication之間選出一個Leader」，「Producer和Consumer只與這個Leader交互」，「其它Replica作為Follower從Leader中復(fù)制數(shù)據(jù)」。「因為需要保證同一個Partition的多個Replica之間的數(shù)據(jù)一致性(其中一個宕機后其它Replica必須要能繼續(xù)服務(wù)并且即不能造成數(shù)據(jù)重復(fù)也不能造成數(shù)據(jù)丟失)」。

如果沒有一個Leader，所有Replica都可同時讀/寫數(shù)據(jù)，那就需要保證多個Replica之間互相(N×N條通路)同步數(shù)據(jù)，數(shù)據(jù)的一致性和有序性非常難保證，「大大增加了Replication實現(xiàn)的復(fù)雜性，同時也增加了出現(xiàn)異常的幾率」。

而引入Leader后，只有Leader負(fù)責(zé)數(shù)據(jù)讀寫，Follower只向Leader順序Fetch數(shù)據(jù)(N條通路)，系統(tǒng)更加簡單且高效。

「Kafka：由于Kafka的使用場景決定，其讀取數(shù)據(jù)時更關(guān)注數(shù)據(jù)的一致性。」

從leader讀取和寫入可以保證所有客戶端都得到相同的數(shù)據(jù)，否則可能存在一些在ISR中注冊的節(jié)點(replication-factor大于min.insync.replicas)，因未來得及更新副本而無法提供的數(shù)據(jù)。相應(yīng)的為了規(guī)避都從leader上讀取帶來的資源競爭，可以根據(jù)不同topic和不同partition設(shè)置不同的leader。

「如下所示：leader==>負(fù)責(zé)讀寫，follower 負(fù)責(zé)同步，只負(fù)責(zé)備份。」

六、關(guān)于kafka數(shù)據(jù)可靠性的保證

為保證 producer 發(fā)送的數(shù)據(jù)，能可靠的發(fā)送到指定的 topic，topic 的每個 partition 收到 producer 發(fā)送的數(shù)據(jù)后，都需要向 producer 發(fā)送 ack(acknowledgement 確認(rèn)收到)，如果 producer 收到 ack，就會進行下一輪的發(fā)送，否則重新發(fā)送數(shù)據(jù)。

6.1 副本數(shù)據(jù)同步策略

Kafka 選擇了第二種方案，原因如下：

同樣為了容忍 n 臺節(jié)點的故障，第一種方案需要 2n+1 個副本，而第二種方案只需要 n+1個副本，而 Kafka 的每個分區(qū)都有大量的數(shù)據(jù)，第一種方案會造成大量數(shù)據(jù)的冗余。

雖然第二種方案的網(wǎng)絡(luò)延遲會比較高，但網(wǎng)絡(luò)延遲對 Kafka 的影響較小。

6.2 ISR集合

采用第二種方案之后，設(shè)想以下情景：leader 收到數(shù)據(jù)，所有 follower 都開始同步數(shù)據(jù)，但有一個 follower，因為某種故障，遲遲不能與 leader 進行同步，那 leader 就要一直等下去，直到它完成同步，才能發(fā)送 ack。這個問題怎么解決呢？

Leader 維護了一個動態(tài)的 in-sync replica set (ISR)，意為和 leader 保持同步的 follower 集合。當(dāng) ISR 中的 follower 完成數(shù)據(jù)的同步之后，leader 就會給 follower 發(fā)送 ack。如果 follower長時間 未 向 leader 同 步 數(shù) 據(jù) ， 則 該 follower 將 被 踢 出 ISR ， 該 時 間 閾 值 由replica.lag.time.max.ms 參數(shù)設(shè)定。Leader 發(fā)生故障之后，就會從 ISR 中選舉新的 leader。

6.3 ACK應(yīng)答機制

對于某些不太重要的數(shù)據(jù)，對數(shù)據(jù)的可靠性要求不是很高，能夠容忍數(shù)據(jù)的少量丟失，所以沒必要等 ISR 中的 follower 全部接收成功。

所以 Kafka 為用戶提供了三種可靠性級別，用戶根據(jù)對可靠性和延遲的要求進行權(quán)衡，選擇以下的配置。

「acks 參數(shù)配置：」

「0」：producer 不等待 broker 的 ack，這一操作提供了一個最低的延遲，broker 一接收到還沒有寫入磁盤就已經(jīng)返回，當(dāng) broker 故障時有可能丟失數(shù)據(jù)；

「1」：producer 等待 broker 的 ack，partition 的 leader 落盤成功后返回 ack，「如果在 follower同步成功之前 leader 故障，那么將會丟失數(shù)據(jù)」；

「-1(all)」：producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盤成功后才返回 ack。「但是如果在 follower 同步完成后，broker 發(fā)送 ack 之前，leader 發(fā)生故障，那么會造成數(shù)據(jù)重復(fù)」。

6.4 故障處理細節(jié)

「LEO：指的是每個副本最大的 offset；HW：指的是消費者能見到的最大的 offset，ISR 隊列中最小的 LEO。」

(1)follower 故障 follower 發(fā)生故障后會被臨時踢出 ISR，待該 follower 恢復(fù)后，follower 會讀取本地磁盤記錄的上次的 HW，并將 log 文件高于 HW 的部分截取掉，從 HW 開始向 leader 進行同步。等該 follower 的 LEO 大于等于該 Partition 的 HW，即 follower 追上 leader 之后，就可以重新加入 ISR 了。

(2)leader 故障 leader 發(fā)生故障之后，會從 ISR 中選出一個新的leader，之后，為保證多個副本之間的數(shù)據(jù)一致性，其余的 follower 會先將各自的 log 文件高于 HW 的部分截掉，然后從新的 leader同步數(shù)據(jù)。

注意：這只能保證副本之間的數(shù)據(jù)一致性，并不能保證數(shù)據(jù)不丟失或者不重復(fù)。

七、關(guān)于Kafak高可用性

關(guān)于 Kafak高可用性，前面我已經(jīng)寫了部分，例如：「Kafka的存儲機制、如何保證數(shù)據(jù)一致性，ISR集合，ACK應(yīng)答機制等」，這些在面試時被問到都可以談一談，那就面試題，我這里再和大家講講 Kafka的選舉機制。

7.1 Leader 選舉機制

「Kafka的Leader是什么？」

首先Kafka會將接收到的消息分區(qū)(partition)，每個主題(topic)的消息有不同的分區(qū)。這樣一方面消息的存儲就不會受到單一服務(wù)器存儲空間大小的限制，另一方面消息的處理也可以在多個服務(wù)器上并行。

其次為了保證高可用，每個分區(qū)都會有一定數(shù)量的副本(replica)。這樣如果有部分服務(wù)器不可用，副本所在的服務(wù)器就會接替上來，保證應(yīng)用的持續(xù)性。

但是，「為了保證較高的處理效率，消息的讀寫都是在固定的一個副本上完成。這個副本就是所謂的Leader」，而其他副本則是Follower。而Follower則會定期地到Leader上同步數(shù)據(jù)。

「Leader選舉」

如果某個分區(qū)所在的服務(wù)器出了問題，不可用，Kafka會從該分區(qū)的其他的副本中選擇一個作為新的Leader。之后所有的讀寫就會轉(zhuǎn)移到這個新的Leader上。現(xiàn)在的問題是應(yīng)當(dāng)選擇哪個作為新的Leader。顯然，只有那些跟Leader保持同步的Follower才應(yīng)該被選作新的Leader。

Kafka會在Zookeeper上針對每個Topic維護一個稱為ISR(in-sync replica，已同步的副本)的集合，該集合中是一些分區(qū)的副本。只有當(dāng)這些副本都跟Leader中的副本同步了之后，Kafka才會認(rèn)為消息已提交，并反饋給消息的生產(chǎn)者。如果這個集合有增減，Kafka會更新Zookeeper上的記錄。

如果某個分區(qū)的Leader不可用，Kafka就會從ISR集合中選擇一個副本作為新的Leader。

顯然通過ISR，Kafka需要的冗余度較低，可以容忍的失敗數(shù)比較高。「假設(shè)某個topic有f+1個副本，Kafka可以容忍f個服務(wù)器不可用。」

「為什么不用少數(shù)服從多數(shù)的方法？」

少數(shù)服從多數(shù)是一種比較常見的一致性算法和Leader選舉法。它的含義是只有超過半數(shù)的副本同步了，系統(tǒng)才會認(rèn)為數(shù)據(jù)已同步；選擇Leader時也是從超過半數(shù)的同步的副本中選擇。這種算法需要較高的冗余度。譬如只允許一臺機器失敗，需要有三個副本；而如果只容忍兩臺機器失敗，則需要五個副本。而kafka的ISR集合方法，分別只需要兩個和三個副本。

「如果所有的ISR副本都失敗了怎么辦？」

此時有兩種方法可選，一種是等待ISR集合中的副本復(fù)活，一種是選擇任何一個立即可用的副本，而這個副本不一定是在ISR集合中。這兩種方法各有利弊，實際生產(chǎn)中按需選擇。如果要等待ISR副本復(fù)活，雖然可以保證一致性，但可能需要很長時間。而如果選擇立即可用的副本，則很可能該副本并不一致。

—?【 THE END 】—本公眾號全部博文已整理成一個目錄，請在公眾號里回復(fù)「m」獲取！

3T技術(shù)資源大放送！包括但不限于：Java、C/C++，Linux，Python，大數(shù)據(jù)，人工智能等等。在公眾號內(nèi)回復(fù)「1024」，即可免費獲取！！

總結(jié)

以上是生活随笔為你收集整理的kafka删除队列_没想到 Kafka 还会这样问，学会这些带你轻松搞定大厂面试！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。