Kafka 面試通常會問哪些問題？

你已經知道 Kafka 是分散式日誌，但擔心面試官會比日常使用再深入一層。這正是這類問題的方向，因此本節會依照面試官通常採用的順序講解相關術語，並指出每個術語背後的追問題。

• 主題與分區。主題會拆分為多個分區，每個分區都是只能附加且具順序的日誌。追問：Kafka 為何透過增加分區來擴展寫入能力，而不是讓單一日誌變得更快？
• 位移量。消費者在分區中的位置。追問：已提交的位移量由誰儲存？如果消費者在提交前當機，會發生什麼事？
• 消費者群組。群組內的消費者會共享一個主題的分區，而同一時間內，每個分區最多只能指派給群組中的一個消費者。追問：如果群組的消費者數量多於分區數量，輸送量會如何變化？
• 代理伺服器與控制器。代理伺服器儲存分區；控制器負責領導者選舉與中繼資料。追問：Kafka 將中繼資料從 ZooKeeper 移至 KRaft 後，有哪些改變？
• 生產者與鍵。帶有鍵的訊息會依鍵的雜湊值落在選定的分區；沒有鍵的訊息則分散至各分區。追問：這兩種方式中，哪一種能維持單一客戶事件的順序？

回答時要說明運作機制，而不只是口號。說分區能實現平行處理只是基本要求；進一步解釋順序只存在於分區內，因此鍵會決定排序範圍，才是能讓你晉級下一輪的答案。

多數應試者會在這個層面失分，因為相關術語很簡單，取捨卻不簡單。面試官通常會提出一項保證，並要求你透過各項設定實現它。

• 至多一次與至少一次。若在處理前提交位移量，訊息可能遺失；若先處理再提交，同一訊息便可能處理兩次。請說明每種順序能承受哪種故障，以及你的系統偏好哪一種。
• 冪等生產者與恰好一次。冪等生產者會在分區內對重試操作去除重複；交易則將這項能力擴展至多個分區，並涵蓋「消費、轉換、生產」流程中的消費者位移量。你也要準備說明恰好一次不會涵蓋哪些範圍：交易以外的下游資料庫寫入，仍須由你處理。
• acks、複寫因子與同步副本。acks=all會等待同步副本集合；min.insync.replicas則設定該集合縮小到什麼程度時必須拒絕寫入。面試官常會問你為持久性付出了什麼代價：代理伺服器故障期間的延遲與可用性。
• 保留與壓縮。依時間或大小設定的保留政策會刪除舊區段；日誌壓縮則保留每個鍵的最新記錄。追問：哪一種適合支援鍵值儲存區的變更日誌？為什麼？
• 重新平衡。當消費者加入或離開時，系統會重新指派分區。追問：長時間的重新平衡會對延遲敏感型服務造成什麼影響？協作式重新平衡與靜態成員資格又如何減輕問題？

有個實用習慣：每當你提到一項設定，都要說明它能防止哪種故障，以及會增加什麼成本。這種回答結構能讓你一口氣答完原問題與追問題。

資深職位的面試流程會用情境取代定義題，觀察你的推理方式。典型題目是：一名後端工程師正在面試支付公司的平台職位，並被要求設計一條事件管線；同一帳戶的每筆交易都必須依序處理，輸送量必須隨流量成長，而且代理伺服器中斷時不能遺失資料。出色的答案會依帳戶 id 設定訊息鍵，讓同一帳戶的事件進入相同分區；根據預期尖峰估算分區數量，並為成長預留空間；設定複寫與 acks=all以確保持久性；以及解釋消費者如何提交位移量，讓當機後的處理方式是重播而非跳過。

其他常見情境包括：消費者處理落後時，如何偵測延遲並趕上進度；當你後悔某個主題的分區數量時，為何重新分區會破壞鍵的排序；有問題的訊息導致消費者當機時，如何用無效訊息佇列模式將其隔離；生產者與消費者之間的結構描述變更，以及結構描述登錄庫能帶來什麼價值。面試官不是在尋找唯一正確的架構，而是希望你指出限制條件、選擇相應機制，並明確說出其中的取捨。

面試前應該大聲練習這些題目，而不是只閱讀答案。透過會持續追問的 AI 面試官排練情境題，正是模擬面試頁面上練習模式的用途；更完整的職位與主題題庫則位於依職位與主題分類的面試題。

如果是對話式面試，可以，但必須遵守誠信界線。SubcueAI 的原生 macOS 與 Windows 桌面應用程式會擷取面試官的音訊及你的麥克風聲音，並在本機浮動視窗中顯示簡短的答案建議。因此，當面試官詢問 min.insync.replicas能防範什麼情況時，你可以在畫面上看到相關機制，再用自己的話解釋。瀏覽器擴充功能也能在瀏覽器分頁中的通話提供相同功能，而且只會擷取會議分頁的音訊。兩者都不會將機器人加入通話，也不會向會議頁面注入任何內容；設定步驟請參閱教學頁面。

這些限制比宣傳內容更重要。受監考的程式測驗、錄製畫面的測驗，或使用公司管理的筆記型電腦進行的測驗，都不在適用範圍內；若即時程式練習要求你在受觀察的情況下實作消費者，則必須由你自行完成。助手最適合協助上述術語與取捨問題，最不適合任何需要在評量平台中輸入內容的情況。使用前，請先提供履歷，讓建議反映你實際參與的 Kafka 工作；該個人資料位於履歷建立工具。