資料工程面試：Kafka 4.3.1 如何治理 Kafka Streams 的 RocksDB 原生記憶體洩漏？

題目

生產叢集從 Kafka 4.3.0 升級到 4.3.1 前，你如何確認 Kafka Streams 的 RocksDB 原生記憶體洩漏已被控制，並避免升級本身造成資料風險？

場景與適用邊界

題目針對 Kafka Streams 使用 RocksDB 狀態儲存的滾動升級。Apache Kafka 官方說明 4.3.1 於 2026 年 6 月 25 日發布，是修復版本，修復約 15 個問題，其中包括 KAFKA-20616 所述的 Kafka Streams RocksDB 原生記憶體洩漏。回答應討論證據、容量、發布和回滾，不應把版本號當成「所有記憶體問題都消失」的保證。

面試官可能先確認：目前執行 Kafka 4.3.0 還是其他版本？狀態儲存規模、重啟恢復時間、堆外記憶體預算和最大允許延遲是多少？是否能逐步遷移 Streams 執行個體？

面試官考察點

考察你能否把上游修復資訊轉成可執行的串流處運維方案：定位原生記憶體與堆內記憶體的邊界，建立升級前基線，用小批量發布驗證洩漏斜率，並保護狀態恢復、處理進度和回滾路徑。

30 秒回答框架

先核對 4.3.1 的發布說明、變更清單和受影響元件；再採集升級前的 RSS、堆外記憶體、RocksDB 狀態大小、GC、處理延遲和重啟恢復基線；然後按一個 Streams 執行個體灰度、觀察固定視窗、逐步擴大範圍；異常時停止擴散並回滾到已驗證版本，同時保留 changelog 和狀態目錄的一致性證據。

分步深入解答

證據確認：鎖定二進位檔、映像和設定版本，記錄 4.3.1 發布說明、升級說明以及 KAFKA-20616 的修復關聯，避免只依據口頭傳言。
基線建立：按執行個體記錄 JVM 堆、程序 RSS、容器工作集、RocksDB 狀態目錄大小、檔案控制代碼、GC、consumer lag、處理吞吐和恢復時長；原生洩漏通常表現為 RSS 或工作集持續增長而堆指標穩定。
試驗設計：使用與生產相近的狀態大小和寫入更新模式，固定觀測視窗，比較升級前後單位輸入量的 RSS 增長斜率；同時驗證重啟、恢復和再平衡。
滾動發布：先升級一個非關鍵執行個體，確認 task 狀態、changelog 追趕和 lag 在門檻內，再按機架或分割區分批推進；升級期間限制並行重啟，避免同時觸發大量狀態恢復。
容量與告警：為 RSS、工作集、堆外預算和 RocksDB 狀態增長設定告警，分清「短時恢復峰值」和「穩定執行後的持續斜率」，為每個執行個體預留恢復餘量。
回滾與資料安全：升級失敗時暫停後續批次，回到已驗證版本；保留 changelog offset、task 狀態、lag 和版本映射，確認回滾不會讓舊程序讀取不相容狀態，必要時從 changelog 重建並核對結果。

高品質示範回答

我先把問題定義成「版本修復是否讓原生記憶體增長斜率回到可接受範圍」，而不是看到 4.3.1 就宣布安全。官方發布資訊指出 4.3.1 修復約 15 個問題，並特別列出 Kafka Streams RocksDB 原生記憶體洩漏；我會把該說明、升級說明和實際建置產物摘要放入變更記錄。

升級前按執行個體採集堆、RSS、容器工作集、RocksDB 狀態大小、GC、lag、吞吐和恢復時長。先在接近生產的狀態規模上執行固定視窗，比較每百萬筆輸入對應的 RSS 增長。生產採用單一執行個體灰度，確認 task 重啟、changelog 追趕、再平衡和 lag 都在門檻內，再按故障域擴大。告警同時觀察絕對值和斜率，避免把恢復期間的短時峰值誤判為洩漏。

text

canary_gate:
  rss_growth_per_million_records: <= baseline_slope * 1.2
  consumer_lag: <= 2 minutes
  restore_time: <= baseline_restore_time * 1.25
  task_errors: 0
rollback:
  stop_rollout: true
  preserve_changelog_offsets: true
  preserve_version_mapping: true

如果灰度出現持續 RSS 增長、恢復逾時或任務錯誤，我會停止發布並回滾到上一版本，保留 offset、狀態和日誌證據；只有重新證明狀態可恢復、結果可比對後才繼續。這樣把上游修復、觀測指標和資料安全連成一個可稽核的升級閉環。

常見錯誤

只引用「4.3.1 修復記憶體洩漏」，不給出發布說明、受影響元件和現場基線。
只看 JVM heap，把 RocksDB 原生記憶體和容器工作集排除在外。
一次重啟整個叢集，導致狀態恢復、再平衡和 lag 同時失控。
把短時恢復峰值當成洩漏，或只看絕對 RSS 而不看增長斜率。
沒有停止擴散、回滾和 changelog/offset 一致性證據。

高品質回答應同時給出版本證據、可重複試驗、灰度門檻、容量告警和資料恢復方案。只說「升級並觀察監控」無法證明風險已被控制。

追問及應對

為什麼 RSS 上升但 JVM heap 沒有上升？

RocksDB 等元件使用程序外的原生記憶體和檔案映射，JVM heap 只涵蓋 Java 堆。應同時查看程序 RSS、容器工作集、狀態目錄和 RocksDB 相關指標，並結合輸入量計算增長斜率。

灰度執行個體的 lag 暫時升高，是否立即回滾？

先按預先定義的視窗和閾值判斷。若 lag 在狀態恢復後回落且 RSS 斜率正常，可以繼續觀察；若 lag 持續超標、恢復時間突破門檻或伴隨任務錯誤，應停止擴散並回滾。

回滾時如何避免狀態不相容？

保留版本到 task 的映射、changelog offset、狀態目錄和設定摘要；先在隔離執行個體驗證舊版本讀取現有狀態的能力，必要時使用 changelog 重建，並對關鍵輸出做比對後再恢復流量。

一句話總結

把 4.3.1 當作有官方證據的候選修復，再用原生記憶體基線、灰度門檻和可驗證回滾證明 Kafka Streams 的風險確實下降。