題幹與適用情境
你負責一個有狀態 Kafka Streams 應用，目前使用 classic group protocol。升級到 Kafka 4.2 後，團隊希望使用 broker 驅動的 Streams Rebalance Protocol，減少執行個體加入、離開或故障時的全域協調停頓。面試官要求你提出遷移計畫、相容邊界與失敗回滾。
假設應用執行在 Kafka Streams 4.2.x，已有 changelog 與 repartition topics，不能接受無計畫的完整重建。官方文件說明新協定由 broker 持續計算任務分配，使用獨立 streams group；Kafka 4.2 新叢集預設啟用，但 client 仍需設定 group.protocol=streams。
面試官考察點
- 能否解釋 broker 驅動協調如何減少 client 全域同步點，而不只是背設定名稱。
- 能否區分新建 streams group、classic group 線上升級與離線遷移的不同可行性。
- 是否檢查 broker、client 版本及 4.2.0 的 KAFKA-20254 風險。
- 是否知道保留的是 committed offsets，其他 group metadata 會重建，不能承諾所有執行狀態無損保留。
- 能否把不支援的 static membership、topology update、regex 等能力轉成上線門檻。
普通回答是「改設定並滾動重啟」。強回答會先判斷版本與功能缺口，再選擇新 group 或維護窗口遷移，記錄 offset、changelog、repartition topics 與恢復時間目標。
回答前需要釐清的問題
- 目前 Kafka 與 Streams client 是否至少 4.2？否則不能直接啟用完整協定。
- 現有應用是否依賴 static membership、線上 topology update、regex subscription 或 standby／rack-aware assignment？任一依賴都可能阻止遷移。
- 能否安排所有執行個體停止並等待 group 為空？官方 4.2 遷移路徑只支援 offline migration。
- 目前版本是 4.2.0 還是 4.2.1 以上？4.2.0 的 offline migration 有已知 broker bug，修復在 4.2.1。
- 是否允許建立新的 application.id？新 group 可隔離風險，但會重新建立狀態並改變 offset 管理。
這些答案決定方案：不能停機時不能聲稱支援 classic 到 streams 的線上遷移；依賴未支援功能時應保留 classic protocol 或先重構應用。
30 秒回答框架
「我先確認 broker 與 client 都是 4.2.x，並盤點應用是否使用新協定尚不支援的功能。Streams Rebalance Protocol 把任務協調放到 broker，減少 client 全域 barrier，但遷移不是普通滾動發布：官方路徑要求 group 為空後切換 group.protocol=streams，只有 committed offsets 會保留，changelog 與 repartition topics 繼續存在，其餘 metadata 會重建。我會避開 4.2.0，優先 4.2.1 以上；遷移前記錄 offsets 與狀態檢查點，遷移後驗證恢復、延遲與 rebalance 指標，失敗就切回 classic 或用新的 application.id 重建。」
分步深入解答
1. 說明協定改變了什麼
classic Streams group 在 client 計算成員任務分配，成員變化時容易形成全域協調點。新協定把 streams group 的成員中繼資料與任務分配放到 broker，應用透過專用 heartbeat 與 streams group 協調。官方文件將它描述為 broker-driven，並提供獨立的 streams group 狀態與 Admin API。
2. 先做能力盤點
Kafka 4.2 目前協定有明確限制：static membership 不可用；顯著 topology update 需要新 streams group；只提供 sticky task assignor，warmup tasks 與 rack-aware assignment 不可用；pattern subscription 不支援；classic 與 streams 之間沒有線上遷移。把這些列成發布前檢查表，避免遷移後才發現設定被忽略。
3. 選擇遷移路徑
官方 offline 路徑是：停止所有執行個體，等待 session.timeout.ms 到期或明確 leave，使 group 為空；設定 group.protocol=streams；再啟動執行個體。只有 committed offsets 會在 broker 端保留，changelog 與 repartition topics 仍作為普通內部 topic 存在，其他 group metadata 會重新建立。
停止全部執行個體
↓
確認 streams group 為空並記錄 committed offsets
↓
升級 broker/client 到相容版本
↓
設定 group.protocol=streams
↓
啟動執行個體，觀察恢復與 rebalance 指標如果業務不能接受維護窗口，保留 classic protocol，或使用新的 application.id 做平行驗證。不要把 classic consumer 的 rolling upgrade 經驗直接套到 Streams Rebalance Protocol。
4. 處理版本風險
Kafka 官方升級指南指出，4.2.0 的 classic 到 streams offline migration 受到 KAFKA-20254 broker-side bug 影響，建議不要在 4.2.0 執行；修復已包含在 4.2.1。面試回答應把 4.2.1 作為最低遷移版本，而不是只說「Kafka 4.2 已支援」。
5. 設計狀態與 offset 驗證
遷移前記錄每個輸入 topic 的 committed offsets、changelog topic 狀態與處理延遲。遷移後驗證：新 group 能從預期 offset 繼續；state store 能從 changelog 恢復；repartition topic 仍存在且分割區數一致；重複處理與遺失記錄符合既定語義。將結果與遷移前基線比較，而不是只看程序是否啟動。
6. 監控與回滾
使用 streams group 專用狀態、rebalance count/rate、恢復時長、處理延遲與錯誤率作為觀測面。若恢復超時或結果驗證失敗，停止新 group，保留 committed offsets 與日誌，回滾設定到 classic；若 classic group 已清空，必須依據備份或新的 application.id 重新規劃，不能假設 group metadata 會自動回來。
高品質示範回答
「我不會把這次遷移當成普通滾動發布。先確認 broker、client 都是 4.2.x，並檢查應用是否使用 static membership、線上 topology update、regex subscription、warmup 或 rack-aware assignment 依賴。由於官方只支援 offline migration，我會選 4.2.1 以上，在維護窗口停止全部執行個體，確認 group 為空，記錄 committed offsets 與 state store 檢查點，再設定 group.protocol=streams 啟動。
「遷移後我會驗證 offsets 能繼續消費、changelog 能恢復 state store、repartition topics 未遺失，並觀察 streams group 狀態、rebalance 指標、恢復時長與業務延遲。只有 committed offsets 會保留，其他 group metadata 會重建；4.2.0 還有 KAFKA-20254 風險，所以不能把 4.2.0 當成安全版本。若驗證失敗，就停止新 group，回到 classic 或使用新的 application.id 重建，並保留證據以便複盤。」
常見錯誤
- 錯誤表現：把
group.protocol=streams當成可滾動切換 → 失敗原因：Streams protocol 不支援線上遷移 → 修正方法：安排 group 為空的維護窗口。 - 錯誤表現：在 4.2.0 直接遷移 → 失敗原因：官方升級指南記錄 KAFKA-20254 → 修正方法：使用包含修復的 4.2.1 以上。
- 錯誤表現：承諾所有 group 狀態自動保留 → 失敗原因：只有 committed offsets 保留，其餘 metadata 會重建 → 修正方法：分別記錄 offset、state store 與 topic 驗證項。
- 錯誤表現：忽略 static membership 或 topology update → 失敗原因：新協定目前不支援這些能力 → 修正方法：遷移前做功能盤點，必要時保持 classic。
追問及應對
業務不能停機，能否兩批執行個體滾動切換？
不能把官方 Streams migration 路徑描述成線上滾動切換。若不能停機，先保留 classic，或建立新的 application.id 做雙寫／影子驗證，再由業務層切流承擔狀態重建成本。
committed offsets 保留了，為什麼還要驗證 state store？
offset 只說明下一筆從哪裡讀，不代表本地狀態已完整恢復。changelog replay、版本不相容或處理失敗都可能讓 state store 與 offset 不一致，必須做狀態與業務結果驗證。
4.2.0 已經 GA，為什麼仍要避開？
GA 表示功能發布，不等於每條遷移路徑都沒有已知缺陷。官方升級指南明確指出 offline migration 的 KAFKA-20254，修復在 4.2.1；遷移版本應依據修復版本而非只看 GA 標籤。
現有應用依賴正則訂閱怎麼辦？
新 streams protocol 目前不支援 pattern-based topic subscription。保持 classic，或把主題發現與訂閱邏輯改成顯式列表後再評估遷移，不能只改 group protocol。
如何判斷是否需要新的 application.id？
若必須平行驗證、舊 group 不能安全清空，或需要隔離狀態恢復風險，可以用新的 application.id 建立獨立 group；代價是重新消費、重建 state store 與額外資源，應先估算恢復時間與儲存成本。
參考資料
- Apache Kafka Streams Rebalance Protocol developer guide。
- Apache Kafka 4.2 Streams Upgrade Guide。
- Apache Kafka 4.2.0 Release Announcement。