資料工程面試：Kafka Share Groups 與 Consumer Groups 如何取捨？
題幹與適用情境
平台使用 Kafka 承載事件流與任務佇列。傳統 Consumer Group 讓同一組內每個分割區只交給一個消費者處理；團隊希望用 Kafka 4.1 的 Share Groups 取得更靈活的並發與佇列行為。請判斷哪些工作負載適合遷移，以及如何控制預覽功能風險。
面試官考察重點
- 能否區分分割區串流處理與共享佇列的交付語義。
- 能否解釋並發上限、取得記錄、確認、失敗重投與順序性影響。
- 能否把多租戶公平、積壓、冪等與可觀測性放進同一設計。
- 能否對預覽功能設定相容性、灰度、資料回放與回滾閘門。
回答前要釐清的問題
- 任務需要按 key 保序、分割區局部狀態，還是只要求每條訊息最終被處理？
- 單條處理失敗是立即重試、延遲重試，還是進入死信佇列？
- 租戶是否共享主題與消費者容量，能否提供穩定的租戶識別？
- 下游副作用是否冪等，能否接受重複處理或並發處理？
- 執行的 Kafka 版本、客戶端、運維工具與託管平台是否支援 Share Groups？
30 秒回答框架
Consumer Group 以分割區作為並行與順序邊界，適合串流聚合、分割區狀態與按 key 保序；Share Group 更接近共享佇列，多個消費者可以取得同一 topic-partition 的不同記錄，並由叢集限制每個分割區可取得的數量。我會先按業務語義分類，再驗證確認、失敗重投、冪等與公平性，最後在預覽環境灰度並保留原 Consumer Group 回滾路徑。
分步深入解答
第一步：從處理語義而不是 API 名稱開始
如果處理依賴分割區內順序、視窗狀態或同 key 的局部聚合，Consumer Group 的分割區分配較容易推理。如果任務彼此獨立、需要更多並發且可接受佇列式確認，Share Group 值得評估。不要只因「吞吐更高」就遷移。
第二步：比較並發與取得邊界
傳統群組的並發主要受分割區數量限制，一個分割區同一時間由一個成員處理。Share Group 允許多個消費者從同一 topic-partition 取得記錄，但叢集仍會限制每個分割區被取得的記錄數量，避免無限並發。需要量測取得批次、處理時間與下游容量的乘積。
第三步：定義確認、失敗與重投
遷移前必須明確訊息何時視為成功，失敗是否釋放給其他消費者，以及重投期間是否可能與舊處理並行。對外部寫入使用冪等鍵、去重表或可重複交易；不可恢復錯誤進入死信並保留原因、租戶與嘗試次數。
第四步：處理順序與狀態
Share Group 的佇列語義可能打破原來依賴分割區順序的假設。需要按 key 串行化的任務可保留 Consumer Group，或在應用層建立鍵級鎖與版本檢查。狀態儲存要記錄事件版本、處理者與重試狀態，避免並發更新覆蓋。
第五步：建立多租戶公平與背壓
共享主題中單一租戶的洪峰可能造成 noisy neighbor。為訊息攜帶穩定租戶識別，按租戶觀測等待時間、處理率與失敗率；必要時拆主題、設定應用層配額或限制每批取得。下游資料庫與外部 API 也要有獨立並發艙壁。
第六步：驗證預覽功能與運維鏈路
Kafka 文件標注 Share Groups 為 preview，預設未啟用。先驗證 broker、客戶端與 Admin 工具的版本相容、指標、故障恢復與升級路徑。用合成事件測試重啟、消費者減少、重複確認、broker 切換、積壓與死信。
第七步：設計遷移與回滾
先複製一小部分非關鍵任務到 Share Group，比較吞吐、p99 等待、重複率、失敗重投、租戶公平與下游錯誤。保留原主題或可重播的 offset 邊界；出現順序破壞、重複副作用或預覽元件異常時，暫停新流量並切回 Consumer Group。
高品質示範回答
我會先按語義分流：需要分割區順序、視窗狀態或按 key 聚合的事件留在 Consumer Group；獨立任務、允許並發與冪等重試的佇列候選遷移到 Share Group。傳統群組以分割區作為並行邊界，同一分割區由一個成員處理；Share Group 更像共享佇列，多個消費者可取得同一 topic-partition 的不同記錄，但每分割區仍有取得上限。遷移前定義確認與失敗重投、冪等鍵、死信與租戶公平指標，並為下游設定並發艙壁。由於 Share Groups 在 Kafka 4.1 文件中是 preview，我會先做版本與運維相容性驗證，再灰度非關鍵租戶，比較等待時間、重複率、lag、失敗重投、每租戶處理率與下游錯誤。保留可重播資料與原 Consumer Group 回滾路徑，任何順序或副作用回歸都立即暫停並回切。
常見錯誤
- 認為 Share Group 只是「更多消費者」，忽略交付與確認語義。
- 把需要分割區順序的狀態流直接遷移到共享佇列。
- 沒有冪等設計就接受失敗重投與並發處理。
- 只看總吞吐，不看租戶等待時間、重複率與下游飽和。
- 忽略 preview 版本的客戶端、運維工具與升級相容性。
- 遷移後刪除原資料，導致無法回放與回滾。
追問及應對
追問一：Share Group 會消除分割區嗎？
不會。topic-partition 仍是儲存與複製邊界；變化在於同一分割區的記錄可以由多個共享群組成員取得，且叢集為取得數量設上限。
追問二：還能保證同一個 key 的順序嗎？
不能直接假設。若業務依賴順序，應保留 Consumer Group，或在應用層按 key 串行化並用版本檢查證明並發不會覆蓋。
追問三：失敗訊息會怎樣？
要根據實作與設定確認是否重新可取得、是否延遲、是否可能並行重投。設計上要用冪等鍵、嘗試次數與死信原因保護副作用。
追問四：如何避免租戶洪峰占滿共享容量？
攜帶租戶識別並觀測每租戶等待與處理率，結合應用層配額、每批取得上限、拆主題或下游艙壁。公平目標應寫成可告警的指標。
追問五：為什麼不全量遷移？
串流處理與佇列處理的順序、狀態、重試與運維需求不同。預覽功能還增加版本與故障風險，應按工作負載分層，而不是追求單一模型。
追問六：如何回滾已處理的訊息？
保留可重播的原始事件與處理版本，停止 Share Group 新流量，恢復 Consumer Group 消費邊界。對已產生的外部副作用執行冪等補償或對帳，不能簡單重複寫入。