題干與適用場景
一個多租戶 Kafka 叢集仍執行 ZooKeeper，團隊計畫遷移到 KRaft 並升級到 Kafka 4.2。叢集使用交易生產者、Kafka Streams 和 Connect，不能接受訊息遺失、重複提交或長時間停機。請設計遷移前檢查、滾動升級、元資料版本門禁、客戶端相容性、故障復原和回滾方案。
面試官考察點
- 能否先識別 Kafka 4.2 只支援 KRaft，避免把升級當成普通 broker 替換。
- 能否區分軟體版本、metadata.version 與遷移狀態。
- 能否識別 4.2.0 Streams 離線遷移缺陷和交易生產者滾動升級修復，選擇 4.2.1。
- 能否覆蓋控制器仲裁、broker、客戶端、Connect 和 Streams 的驗證邊界。
- 能否說明何時可回滾、何時元資料升級後只能前進。
回答前需要釐清的問題
- 目前 Kafka、ZooKeeper、客戶端和 Streams 版本分別是什麼？是否已達到 KRaft 遷移要求？
- 交易生產者的冪等、交易逾時和未完成交易數量如何觀測？
- 叢集是否有跨區域副本、MirrorMaker 或可驗證的復原叢集？
- 是否使用 Streams Rebalance Protocol、Share Groups 或其他 4.2 新功能？
- 業務可以接受怎樣的滾動窗口、消費者再平衡和回滾時間？
30 秒回答
我會先把 4.2 視為架構遷移：ZooKeeper 叢集必須先遷到 KRaft，不能直接升級。目標版本選擇 4.2.1，避免 4.2.0 已知的 Streams 離線遷移缺陷和交易生產者滾動升級問題。遷移前凍結高風險變更，盤點客戶端、交易、Streams 狀態和復原副本；先滾動升級軟體，觀察行為和效能，再單獨提升 metadata.version。每一步都設定訊息端到端、交易提交、消費者延遲、控制器仲裁和 Streams 狀態校驗。失敗時停在尚未提升元資料的階段，或按支援路徑恢復到相容版本，不把已發生的元資料變更當作可逆開關。
分步驟深入解答
1. 畫出版本與狀態矩陣
Kafka 4.2 只支援 KRaft，ZooKeeper 模式必須先遷移。軟體版本、元資料版本和控制器仲裁狀態是三個獨立維度。先確認目前版本至少滿足遷移前提，記錄 broker、controller、客戶端、Connect、Streams 和協定版本；將每個狀態寫入可稽核清單。
ZooKeeper 叢集 -> KRaft 遷移完成 -> 滾動升級 broker/controller -> 驗證 -> 提升 metadata.version
| | | |
+-- 不滿足前提 --+--------------------+--------> 停止，不進入下一階段2. 選擇修復版本與遷移順序
使用 4.2.1 作為目標版本。官方升級說明列出 4.2.1 修復了交易生產者滾動升級可能觸發的 UnsupportedVersionException，也修復了 Streams Rebalance Protocol 的離線遷移缺陷；4.2.0 不應執行受影響的 classic 到 streams group 遷移。先升級工具鏈和客戶端相容矩陣，再按一次一個 broker 的方式滾動升級，避免同時改變多個故障域。
3. 處理元資料與控制器門禁
滾動升級完成後先觀察叢集行為和效能，再執行 kafka-features.sh 提升目標 metadata.version。門禁包括 controller quorum 穩定、選主無異常、元資料傳播延遲、ISR 和磁碟健康。4.2 文件說明該版本沒有元資料變更時可支援降級，但不能把所有未來版本都視為可降級；每個目標版本都要檢查 metadata 相容性。
4. 驗證交易、Streams 與 Connect
交易驗證覆蓋生產者 epoch、提交和 abort、重啟復原、重複訊息和交易逾時。Streams 驗證覆蓋狀態儲存復原、再平衡、changelog、處理語義和離線遷移路徑；Connect 驗證 offset、任務重啟和外部系統冪等。對每類客戶端做端到端生產—消費校驗，不能只看 broker 健康。
5. 觀測與故障演練
記錄 controller 選舉、元資料版本、broker 日誌、請求錯誤、交易狀態、消費者延遲、Streams 狀態復原、Connect 任務和磁碟增長。演練 broker 重啟、controller 失聯、交易生產者中斷、Streams 遷移失敗和客戶端版本不相容；每個故障都要有停止升級和復原條件。
6. 回滾與復原邊界
在提升 metadata.version 前，保留舊版本二進位檔、設定、快照和復原叢集，並定義唯讀驗證窗口。若滾動升級階段失敗，可停在尚未提升元資料的相容版本並復原 broker；一旦發生不支援降級的元資料變更，回滾應轉為恢復相容快照或新叢集重建，不應強行替換二進位檔。業務復原優先保證交易和 offset 一致性，再恢復吞吐。
高品質示範回答
我先確認目標不是普通版本升級：Kafka 4.2 移除了 ZooKeeper 支援，舊叢集必須先完成 KRaft 遷移。我選 4.2.1，因為官方升級說明明確列出交易生產者滾動升級和 Streams 離線遷移修復。遷移前盤點 broker、controller、客戶端、Connect、Streams、交易和復原副本，建立版本與狀態矩陣。
執行時一次滾動一個 broker，先驗證 controller quorum、ISR、延遲和行為，再提升 metadata.version。交易驗證檢查 epoch、commit、abort、重啟和重複；Streams 檢查狀態儲存、changelog、再平衡和遷移；Connect 檢查 offset 與任務復原。整個過程記錄元資料版本、選舉、延遲和錯誤率。元資料升級前失敗可停在相容階段；升級後若不支援降級，按快照或復原叢集重建，不強行回退二進位檔。
常見錯誤
- 直接把 ZooKeeper broker 替換成 Kafka 4.2，忽略 KRaft 前置遷移。
- 只看 broker 存活，不驗證交易、Streams 狀態、Connect offset 和端到端訊息。
- 在未觀察滾動升級結果前立即提升
metadata.version。 - 使用 4.2.0 執行官方已知存在風險的 Streams 離線遷移。
- 把 metadata.version 當成普通設定，認為隨時可以降級。
- 沒有復原叢集、快照和停止升級的明確門禁。
追問及應對
為什麼不能直接升級 ZooKeeper 叢集到 Kafka 4.2？
Kafka 4.2 只支援 KRaft，ZooKeeper 模式已移除。必須先完成遷移並驗證控制器仲裁，再進入 4.2 的滾動升級路徑。
什麼時候提升 metadata.version？
所有 broker/controller 軟體升級並穩定執行後，確認 quorum、ISR、客戶端錯誤和效能指標，再單獨提升；這樣能把程式問題與協定啟用問題分開。
元資料升級後發現 Streams 狀態復原失敗怎麼辦？
立即停止繼續提升版本，保留現場和日誌，按支援的復原快照或新叢集重建路徑復原。不要直接降級二進位檔或刪除 changelog 來掩蓋狀態不一致。