基礎題目

1杖小、Apache Kafka 是什么?

Apach Kafka 是一款分布式流處理框架奶赔，用于實時構(gòu)建流處理應用。它有一個核心 的功能廣為人知痰滋，即作為企業(yè)級的消息引擎被廣泛使用摘能。

你一定要先明確它的流處理框架地位，這樣能給面試官留 下一個很專業(yè)的印象敲街。

2团搞、什么是消費者組?

消費者組是 Kafka 獨有的概念，如果面試官問這 個多艇，就說明他對此是有一定了解的莺丑。我先給出標準答案：
1、定義：即消費者組是 Kafka 提供的可擴展且具有容錯性的消費者機制墩蔓。
2梢莽、原理：在 Kafka 中，消費者組是一個由多個消費者實例 構(gòu)成的組奸披。多個實例共同訂閱若干個主題昏名，實現(xiàn)共同消費。同一個組下的每個實例都配置有 相同的組 ID阵面，被分配不同的訂閱分區(qū)轻局。當某個實例掛掉的時候洪鸭，其他實例會自動地承擔起 它負責消費的分區(qū)。

此時仑扑，又有一個小技巧給到你:消費者組的題目览爵，能夠幫你在某種程度上掌控下面的面試方
向。

• 如果你擅長位移值原理镇饮，就不妨再提一下消費者組的位移提交機制;
• 如果你擅長 Kafka Broker蜓竹，可以提一下消費者組與 Broker 之間的交互;
• 如果你擅長與消費者組完全不相關的 Producer，那么就可以這么說:“消費者組要消 費的數(shù)據(jù)完全來自于 Producer 端生產(chǎn)的消息储藐，我對 Producer 還是比較熟悉的俱济。”

3钙勃、在 Kafka 中蛛碌，ZooKeeper 的作用是什么?

這是一道能夠幫助你脫穎而出的題目。碰到這個題目辖源，請在心中暗笑三聲蔚携。

目前，Kafka 使用 ZooKeeper 存放集群元數(shù)據(jù)克饶、成員管理酝蜒、Controller 選舉，以及其他一些管理類任務彤路。之后秕硝，等 KIP-500 提案完成后芥映，Kafka 將完全不再依賴 于 ZooKeeper洲尊。

記住，一定要突出“目前”奈偏，以彰顯你非常了解社區(qū)的演進計劃坞嘀。“存放元數(shù)據(jù)”是指主題 分區(qū)的所有數(shù)據(jù)都保存在 ZooKeeper 中惊来，且以它保存的數(shù)據(jù)為權威丽涩，其他“人”都要與它 保持對齊〔靡希“成員管理”是指 Broker 節(jié)點的注冊矢渊、注銷以及屬性變更，等 等枉证“校“Controller 選舉”是指選舉集群 Controller，而其他管理類任務包括但不限于主題 刪除室谚、參數(shù)配置等毡鉴。

不過崔泵，拋出 KIP-500 也可能是個雙刃劍。碰到非常資深的面試官猪瞬，他可能會進一步追問你 KIP-500 是做的憎瘸。一言以蔽之:KIP-500 思想，是使用社區(qū)自研的基于 Raft 的共識算法陈瘦， 替代 ZooKeeper幌甘，實現(xiàn) Controller 自選舉。

4甘晤、解釋下 Kafka 中位移(offset)的作用

在 Kafka 中含潘，每個 主題分區(qū)下的每條消息都被賦予了一個唯一的 ID 數(shù)值，用于標識它在分區(qū)中的位置线婚。這個 ID 數(shù)值遏弱，就被稱為位移，或者叫偏移量塞弊。一旦消息被寫入到分區(qū)日志漱逸，它的位移值將不能 被修改。

答完這些之后游沿，你還可以把整個面試方向轉(zhuǎn)移到你希望的地方饰抒。常見方法有以下 3 種:

1. 如果你深諳 Broker 底層日志寫入的邏輯，可以強調(diào)下消息在日志中的存放格式;
2. 如果你明白位移值一旦被確定不能修改诀黍，可以強調(diào)下“Log Cleaner 組件都不能影響位 移值”這件事情;
3. 如果你對消費者的概念還算熟悉袋坑，可以再詳細說說位移值和消費者位移值之間的區(qū)別。

5眯勾、闡述下 Kafka 中的領導者副本(Leader Replica)和追隨者副本 (Follower Replica)的區(qū)別

這道題表面上是考核你對 Leader 和 Follower 區(qū)別的理解枣宫，但很容易引申到 Kafka 的同步 機制上。因此吃环，我建議你主動出擊也颤，一次性地把隱含的考點也答出來，也許能夠暫時把面試 官“唬住”郁轻，并體現(xiàn)你的專業(yè)性翅娶。

你可以這么回答:Kafka 副本當前分為領導者副本和追隨者副本。只有 Leader 副本才能 對外提供讀寫服務好唯，響應 Clients 端的請求竭沫。Follower 副本只是采用拉(PULL)的方 式，被動地同步 Leader 副本中的數(shù)據(jù)骑篙，并且在 Leader 副本所在的 Broker 宕機后蜕提，隨時 準備應聘 Leader 副本。

通常來說替蛉，回答到這個程度贯溅，其實才只說了 60%拄氯，因此，我建議你再回答兩個額外的加分 項它浅。

• 強調(diào) Follower 副本也能對外提供讀服務译柏。自 Kafka 2.4 版本開始，社區(qū)通過引入新的 Broker 端參數(shù)姐霍，允許 Follower 副本有限度地提供讀服務鄙麦。
• 強調(diào) Leader 和 Follower 的消息序列在實際場景中不一致。很多原因都可能造成 Leader 和 Follower 保存的消息序列不一致镊折，比如程序 Bug胯府、網(wǎng)絡問題等。這是很嚴重 的錯誤恨胚，必須要完全規(guī)避骂因。你可以補充下，之前確保一致性的主要手段是高水位機制赃泡， 但高水位值無法保證 Leader 連續(xù)變更場景下的數(shù)據(jù)一致性寒波，因此，社區(qū)引入了 Leader Epoch 機制升熊，來修復高水位值的弊端俄烁。關于“Leader Epoch 機制”，國內(nèi)的資料不是 很多级野，它的普及度遠不如高水位页屠，不妨大膽地把這個概念秀出來，力求驚艷一把蓖柔。

實操題目

6辰企、如何設置 Kafka 能接收的最大消息的大小?

這道題除了要回答消費者端的參數(shù)設置之外，一定要加上 Broker 端的設置渊抽，這樣才算完整蟆豫。畢竟议忽，如果 Producer 都不能向 Broker 端發(fā)送數(shù)據(jù)很大的消息懒闷，又何來消費一說呢? 因此，你需要同時設置 Broker 端參數(shù)和 Consumer 端參數(shù)栈幸。

• Broker 端參數(shù):message.max.bytes愤估、max.message.bytes(主題級別)和 replica.fetch.max.bytes。
• Consumer 端參數(shù):fetch.message.max.bytes速址。

Broker 端的最后一個參數(shù)比較容易遺漏玩焰。我們必須調(diào)整 Follower 副本能夠接收的最大消 息的大小，否則芍锚，副本同步就會失敗昔园。因此蔓榄，把這個答出來的話，就是一個加分項默刚。

7甥郑、監(jiān)控 Kafka 的框架都有哪些?

面試官其實是在 考察你對監(jiān)控框架的了解廣度，或者說荤西，你是否知道很多能監(jiān)控 Kafka 的框架或方法澜搅。下 面這些就是 Kafka 發(fā)展歷程上比較有名氣的監(jiān)控系統(tǒng)。

1. Kafka Manager:應該算是最有名的專屬 Kafka 監(jiān)控框架了邪锌，是獨立的監(jiān)控系統(tǒng)勉躺。
2. Kafka Monitor:LinkedIn 開源的免費框架，支持對集群進行系統(tǒng)測試觅丰，并實時監(jiān)控測
   試結(jié)果饵溅。
3. CruiseControl:也是 LinkedIn 公司開源的監(jiān)控框架，用于實時監(jiān)測資源使用率妇萄，以及 提供常用運維操作等概说。無 UI 界面，只提供 REST API嚣伐。
4. JMX 監(jiān)控:由于 Kafka 提供的監(jiān)控指標都是基于 JMX 的糖赔，因此，市面上任何能夠集成 JMX 的框架都可以使用轩端，比如 Zabbix 和 Prometheus放典。
5. 已有大數(shù)據(jù)平臺自己的監(jiān)控體系:像 Cloudera 提供的 CDH 這類大數(shù)據(jù)平臺，天然就提 供 Kafka 監(jiān)控方案基茵。
6. JMXTool:社區(qū)提供的命令行工具奋构，能夠?qū)崟r監(jiān)控 JMX 指標。答上這一條拱层，屬于絕對 的加分項弥臼，因為知道的人很少，而且會給人一種你對 Kafka 工具非常熟悉的感覺根灯。如果 你暫時不了解它的用法径缅，可以在命令行以無參數(shù)方式執(zhí)行一下kafka-run-class.sh kafka.tools.JmxTool，學習下它的用法烙肺。

8纳猪、Broker 的 Heap Size 如何設置?

如何設置 Heap Size 的問題，其實和 Kafka 關系不大桃笙，它是一類非常通用的面試題目氏堤。一 旦你應對不當，面試方向很有可能被引到 JVM 和 GC 上去搏明，那樣的話鼠锈，你被問住的幾率就 會增大闪檬。因此，我建議你簡單地介紹一下 Heap Size 的設置方法购笆，并把重點放在 Kafka Broker 堆大小設置的最佳實踐上谬以。

比如盯串，你可以這樣回復:任何 Java 進程 JVM 堆大小的設置都需要仔細地進行考量和測 試盼樟。一個常見的做法是茅逮，以默認的初始 JVM 堆大小運行程序钉汗，當系統(tǒng)達到穩(wěn)定狀態(tài)后索抓，手動觸發(fā)一次 Full GC涩堤，然后通過 JVM 工具查看 GC 后的存活對象大小吉拳。之后烈涮，將堆大小設 置成存活對象總大小的 1.5~2 倍娃循。對于 Kafka 而言炕檩，這個方法也是適用的。不過捌斧，業(yè)界有 個最佳實踐笛质，那就是將 Broker 的 Heap Size 固定為 6GB。經(jīng)過很多公司的驗證捞蚂，這個大 小是足夠且良好的妇押。

9、如何估算 Kafka 集群的機器數(shù)量?

這道題目考查的是機器數(shù)量和所用資源之間的關聯(lián)關系姓迅。所謂資源敲霍，也就是 CPU、內(nèi)存丁存、磁盤和帶寬肩杈。

通常來說，CPU 和內(nèi)存資源的充足是比較容易保證的解寝，因此扩然，你需要從磁盤空間和帶寬占用兩個維度去評估機器數(shù)量。

在預估磁盤的占用時聋伦，你一定不要忘記計算副本同步的開銷夫偶。如果一條消息占用 1KB 的磁 盤空間，那么嘉抓，在有 3 個副本的主題中索守，你就需要 3KB 的總空間來保存這條消息晕窑。顯式地 將這些考慮因素答出來抑片，能夠彰顯你考慮問題的全面性，是一個難得的加分項杨赤。

對于評估帶寬來說敞斋，常見的帶寬有 1Gbps 和 10Gbps截汪，但你要切記，這兩個數(shù)字僅僅是最大值植捎。因此衙解，你最好和面試官確認一下給定的帶寬是多少。然后焰枢，明確闡述出當帶寬占用接 近總帶寬的 90% 時蚓峦，丟包情形就會發(fā)生。這樣能顯示出你的網(wǎng)絡基本功济锄。

10暑椰、Leader 總是 -1，怎么破?

在生產(chǎn)環(huán)境中荐绝，你一定碰到過“某個主題分區(qū)不能工作了”的情形一汽。使用命令行查看狀態(tài)的 話，會發(fā)現(xiàn) Leader 是 -1低滩，于是召夹，你使用各種命令都無濟于事，最后只能用“重啟大 法”恕沫。

但是监憎，有沒有什么辦法，可以不重啟集群婶溯，就能解決此事呢?這就是此題的由來枫虏。

我直接給答案:刪除 ZooKeeper 節(jié)點 /controller，觸發(fā) Controller 重選舉爬虱。 Controller 重選舉能夠為所有主題分區(qū)重刷分區(qū)狀態(tài)隶债，可以有效解決因不一致導致的 Leader 不可用問題。我?guī)缀蹩梢詳喽ㄅ荏荩斆嬖嚬賳柍龃祟}時死讹，要么就是他真的不知道怎么 解決在向你尋求答案，要么他就是在等你說出這個答案曲梗。所以赞警，千萬別一上來就說“來個重 啟”之類的話。

炫技式題目

11虏两、LEO愧旦、LSO、AR定罢、ISR笤虫、HW 都表示什么含義?

• LEO:Log End Offset。日志末端位移值或末端偏移量，表示日志下一條待插入消息的 位移值琼蚯。舉個例子酬凳，如果日志有 10 條消息，位移值從 0 開始遭庶，那么宁仔，第 10 條消息的位 移值就是 9。此時峦睡，LEO = 10翎苫。
• LSO:Log Stable Offset。這是 Kafka 事務的概念榨了。如果你沒有使用到事務拉队，那么這個 值不存在(其實也不是不存在，只是設置成一個無意義的值)阻逮。該值控制了事務型消費 者能夠看到的消息范圍粱快。它經(jīng)常與 Log Start Offset，即日志起始位移值相混淆叔扼，因為 有些人將后者縮寫成 LSO事哭，這是不對的。在 Kafka 中瓜富，LSO 就是指代 Log Stable Offset鳍咱。
• AR:Assigned Replicas。AR 是主題被創(chuàng)建后与柑，分區(qū)創(chuàng)建時被分配的副本集合谤辜，副本個 數(shù)由副本因子決定。
• ISR:In-Sync Replicas价捧。Kafka 中特別重要的概念丑念，指代的是 AR 中那些與 Leader 保 持同步的副本集合。在 AR 中的副本可能不在 ISR 中结蟋，但 Leader 副本天然就包含在 ISR 中脯倚。關于 ISR，還有一個常見的面試題目是如何判斷副本是否應該屬于 ISR嵌屎。目前的判斷 依據(jù)是:Follower 副本的 LEO 落后 Leader LEO 的時間推正，是否超過了 Broker 端參數(shù) replica.lag.time.max.ms 值。如果超過了宝惰，副本就會被從 ISR 中移除植榕。
• HW:高水位值(High watermark)。這是控制消費者可讀取消息范圍的重要字段尼夺。一 個普通消費者只能“看到”Leader 副本上介于 Log Start Offset 和 HW(不含)之間的 所有消息尊残。水位以上的消息是對消費者不可見的炒瘸。關于 HW，問法有很多夜郁，我能想到的 最高級的問法什燕，就是讓你完整地梳理下 Follower 副本拉取 Leader 副本粘勒、執(zhí)行同步機制 的詳細步驟竞端。這就是我們的第 20 道題的題目，一會兒我會給出答案和解析庙睡。

12事富、Kafka 能手動刪除消息嗎?
其實，Kafka 不需要用戶手動刪除消息乘陪。它本身提供了留存策略统台，能夠自動刪除過期消息。 當然啡邑，它是支持手動刪除消息的贱勃。因此，你最好從這兩個維度去回答谤逼。

• 對于設置了 Key 且參數(shù) cleanup.policy=compact 的主題而言贵扰，我們可以構(gòu)造一條 <Key，null> 的消息發(fā)送給 Broker流部，依靠 Log Cleaner 組件提供的功能刪除掉該 Key 的消息戚绕。
• 對于普通主題而言，我們可以使用 kafka-delete-records 命令枝冀，或編寫程序調(diào)用 Admin.deleteRecords 方法來刪除消息舞丛。這兩種方法殊途同歸，底層都是調(diào)用 Admin 的 deleteRecords 方法果漾，通過將分區(qū) Log Start Offset 值抬高的方式間接刪除消息球切。

13、__consumer_offsets 是做什么用的?

這是一個內(nèi)部主題绒障，公開的官網(wǎng)資料很少涉及到欧聘。因此，我認為端盆，此題屬于面試官炫技一類 的題目怀骤。你要小心這里的考點:該主題有 3 個重要的知識點，你一定要全部答出來焕妙，才會顯得對這塊知識非常熟悉蒋伦。

它是一個內(nèi)部主題，無需手動干預焚鹊，由 Kafka 自行管理痕届。當然韧献，我們可以創(chuàng)建該主題。

它的主要作用是負責注冊消費者以及保存位移值研叫〈敢ぃ可能你對保存位移值的功能很熟悉， 但其實該主題也是保存消費者元數(shù)據(jù)的地方嚷炉。千萬記得把這一點也回答上渊啰。另外，這里 的消費者泛指消費者組和獨立消費者申屹，而不僅僅是消費者組绘证。

Kafka 的 GroupCoordinator 組件提供對該主題完整的管理功能，包括該主題的創(chuàng)建哗讥、 寫入嚷那、讀取和 Leader 維護等。

14杆煞、分區(qū) Leader 選舉策略有幾種?

分區(qū)的 Leader 副本選舉對用戶是完全透明的魏宽，它是由 Controller 獨立完成的。你需要回答的是决乎，在哪些場景下队询，需要執(zhí)行分區(qū) Leader 選舉。每一種場景對應于一種選舉策略瑞驱。當前娘摔，Kafka 有 4 種分區(qū) Leader 選舉策略。

• OfflinePartition Leader 選舉:每當有分區(qū)上線時唤反，就需要執(zhí)行 Leader 選舉凳寺。所謂的分區(qū)上線，可能是創(chuàng)建了新分區(qū)彤侍，也可能是之前的下線分區(qū)重新上線肠缨。這是最常見的分區(qū) Leader 選舉場景。
• ReassignPartition Leader 選舉:當你手動運行 kafka-reassign-partitions 命令盏阶，或者是調(diào)用 Admin 的 alterPartitionReassignments 方法執(zhí)行分區(qū)副本重分配時晒奕，可能觸發(fā)此類選舉。假設原來的 AR 是[1名斟，2脑慧，3]，Leader 是 1砰盐，當執(zhí)行副本重分配后闷袒，副本集 合 AR 被設置成[4，5岩梳，6]囊骤，顯然晃择，Leader 必須要變更，此時會發(fā)生 Reassign Partition Leader 選舉也物。
• PreferredReplicaPartition Leader 選舉:當你手動運行 kafka-preferred-replica- election 命令宫屠，或自動觸發(fā)了 Preferred Leader 選舉時，該類策略被激活滑蚯。所謂的 Preferred Leader浪蹂，指的是 AR 中的第一個副本。比如 AR 是[3膘魄，2乌逐，1]竭讳，那么创葡， Preferred Leader 就是 3。
• ControlledShutdownPartition Leader 選舉:當 Broker 正常關閉時绢慢，該 Broker 上 的所有 Leader 副本都會下線灿渴，因此，需要為受影響的分區(qū)執(zhí)行相應的 Leader 選舉胰舆。

這 4 類選舉策略的大致思想是類似的骚露，即從 AR 中挑選首個在 ISR 中的副本，作為新 Leader缚窿。當然棘幸，個別策略有些微小差異。不過倦零，回答到這種程度误续，應該足以應付面試官 了。畢竟扫茅，微小差別對選舉 Leader 這件事的影響很小蹋嵌。

15、Kafka 的哪些場景中使用了零拷貝(Zero Copy)?

Zero Copy 是特別容易被問到的高階題目葫隙。在 Kafka 中栽烂，體現(xiàn) Zero Copy 使用場景的地方有兩處:基于 mmap 的索引和日志文件讀寫所用的 TransportLayer。

先說第一個恋脚。索引都是基于 MappedByteBuffer 的腺办，也就是讓用戶態(tài)和內(nèi)核態(tài)共享內(nèi)核態(tài) 的數(shù)據(jù)緩沖區(qū)，此時糟描，數(shù)據(jù)不需要復制到用戶態(tài)空間怀喉。不過，mmap 雖然避免了不必要的 拷貝蚓挤，但不一定就能保證很高的性能磺送。在不同的操作系統(tǒng)下驻子，mmap 的創(chuàng)建和銷毀成本可 能是不一樣的。很高的創(chuàng)建和銷毀開銷會抵消 Zero Copy 帶來的性能優(yōu)勢估灿。由于這種不確 定性崇呵，在 Kafka 中，只有索引應用了 mmap馅袁，最核心的日志并未使用 mmap 機制域慷。

再說第二個。TransportLayer 是 Kafka 傳輸層的接口汗销。它的某個實現(xiàn)類使用了 FileChannel 的 transferTo 方法犹褒。該方法底層使用 sendfile 實現(xiàn)了 Zero Copy。對 Kafka 而言弛针，如果 I/O 通道使用普通的 PLAINTEXT叠骑，那么，Kafka 就可以利用 Zero Copy 特 性削茁，直接將頁緩存中的數(shù)據(jù)發(fā)送到網(wǎng)卡的 Buffer 中宙枷，避免中間的多次拷貝。相反茧跋，如果 I/O 通道啟用了 SSL慰丛，那么，Kafka 便無法利用 Zero Copy 特性了瘾杭。

深度思考題

16诅病、Kafka 為什么不支持讀寫分離?

這道題目考察的是你對 Leader/Follower 模型的思考。

Leader/Follower 模型并沒有規(guī)定 Follower 副本不可以對外提供讀服務粥烁。很多框架都是允 許這么做的贤笆，只是 Kafka 最初為了避免不一致性的問題，而采用了讓 Leader 統(tǒng)一提供服 務的方式页徐。

不過苏潜，在開始回答這道題時，你可以率先亮出觀點:自 Kafka 2.4 之后变勇，Kafka 提供了有限度的讀寫分離恤左，也就是說，F(xiàn)ollower 副本能夠?qū)ν馓峁┳x服務搀绣。

說完這些之后飞袋，你可以再給出之前的版本不支持讀寫分離的理由。

• 場景不適用链患。讀寫分離適用于那種讀負載很大巧鸭，而寫操作相對不頻繁的場景，可 Kafka 不屬于這樣的場景麻捻。
• 同步機制纲仍。Kafka 采用 PULL 方式實現(xiàn) Follower 的同步呀袱，因此，F(xiàn)ollower 與 Leader 存 在不一致性窗口郑叠。如果允許讀 Follower 副本夜赵，就勢必要處理消息滯后(Lagging)的問題。

17乡革、如何調(diào)優(yōu) Kafka?

回答任何調(diào)優(yōu)問題的第一步寇僧，就是確定優(yōu)化目標，并且定量給出目標!這點特別重要沸版。對于 Kafka 而言嘁傀，常見的優(yōu)化目標是吞吐量、延時视粮、持久性和可用性细办。每一個方向的優(yōu)化思路都 是不同的，甚至是相反的馒铃。

確定了目標之后蟹腾，還要明確優(yōu)化的維度痕惋。有些調(diào)優(yōu)屬于通用的優(yōu)化思路区宇，比如對操作系統(tǒng)、 JVM 等的優(yōu)化;有些則是有針對性的值戳，比如要優(yōu)化 Kafka 的 TPS议谷。我們需要從 3 個方向去考慮

• Producer 端:增加 batch.size、linger.ms堕虹，啟用壓縮卧晓，關閉重試等。
• Broker 端:增加 num.replica.fetchers赴捞，提升 Follower 同步 TPS逼裆，避免 Broker Full GC 等。
• Consumer:增加 fetch.min.bytes 等

18赦政、Controller 發(fā)生網(wǎng)絡分區(qū)(Network Partitioning)時胜宇，Kafka 會怎 么樣?

這道題目能夠誘發(fā)我們對分布式系統(tǒng)設計、CAP 理論恢着、一致性等多方面的思考桐愉。不過，針 對故障定位和分析的這類問題掰派，我建議你首先言明“實用至上”的觀點从诲，即不論怎么進行理論分析，永遠都要以實際結(jié)果為準靡羡。一旦發(fā)生 Controller 網(wǎng)絡分區(qū)系洛，那么俊性，第一要務就是 查看集群是否出現(xiàn)“腦裂”，即同時出現(xiàn)兩個甚至是多個 Controller 組件描扯。這可以根據(jù) Broker 端監(jiān)控指標 ActiveControllerCount 來判斷磅废。

現(xiàn)在，我們分析下荆烈，一旦出現(xiàn)這種情況拯勉，Kafka 會怎么樣。

由于 Controller 會給 Broker 發(fā)送 3 類請求憔购，即LeaderAndIsrRequest宫峦、 StopReplicaRequest 和 UpdateMetadataRequest，因此玫鸟，一旦出現(xiàn)網(wǎng)絡分區(qū)导绷，這些請求將不能順利到達 Broker 端。這將影響主題的創(chuàng)建屎飘、修改妥曲、刪除操作的信息同步，表現(xiàn)為 集群仿佛僵住了一樣钦购，無法感知到后面的所有操作檐盟。因此，網(wǎng)絡分區(qū)通常都是非常嚴重的問 題押桃，要趕快修復葵萎。

19、Java Consumer 為什么采用單線程來獲取消息?

在回答之前唱凯，如果先把這句話說出來羡忘，一定會加分:Java Consumer 是雙線程的設計。一 個線程是用戶主線程磕昼，負責獲取消息;另一個線程是心跳線程卷雕，負責向 Kafka 匯報消費者 存活情況。將心跳單獨放入專屬的線程票从，能夠有效地規(guī)避因消息處理速度慢而被視為下線 的“假死”情況漫雕。

單線程獲取消息的設計能夠避免阻塞式的消息獲取方式。單線程輪詢方式容易實現(xiàn)異步非阻塞式纫骑，這樣便于將消費者擴展成支持實時流處理的操作算子蝎亚。因為很多實時流處理操作算子都不能是阻塞式的。另外一個可能的好處是先馆，可以簡化代碼的開發(fā)发框。多線程交互的代碼是非常容易出錯的。

20、簡述 Follower 副本消息同步的完整流程

首先梅惯，F(xiàn)ollower 發(fā)送 FETCH 請求給 Leader宪拥。接著，Leader 會讀取底層日志文件中的消 息數(shù)據(jù)铣减，再更新它內(nèi)存中的 Follower 副本的 LEO 值她君，更新為 FETCH 請求中的 fetchOffset 值。最后葫哗，嘗試更新分區(qū)高水位值缔刹。Follower 接收到 FETCH 響應之后，會把 消息寫入到底層日志劣针，接著更新 LEO 和 HW 值校镐。

Leader 和 Follower 的 HW 值更新時機是不同的，F(xiàn)ollower 的 HW 更新永遠落后于 Leader 的 HW捺典。這種時間上的錯配是造成各種不一致的原因鸟廓。