為什麼不直接寫 DB

直接寫 DB（SQLite / PostgreSQL）的問題是 ingestion 速度被 DB 寫入速度限制。DB 寫入慢（鎖定、WAL flush、索引更新）時，HTTP handler 的 goroutine 等在 Storage.Store() 上 — goroutine 積壓 → 記憶體上升 → 最終 OOM 或 response timeout。

Queue 的解決方式是把「接收」和「寫入」分開：接收端只做 JSON 驗證 + 寫入 queue（微秒級），處理端從 queue 讀取 + 寫入 DB（毫秒級）。接收端的吞吐量不再受 DB 限制。

取捨

自用工具場景不需要 queue — 單 collector + SQLite 的直接寫入足夠。Queue 的引入條件是「直接寫 DB 的背壓開始頻繁觸發」。

候選類型

選型判斷

已有 Redis → 先用 Redis Streams（零新增元件）。Go 為主的技術棧 → NATS JetStream（Go 原生 client、單 binary 部署）。需要跨消費者群組或日誌級持久化 → Kafka。

引入條件

Queue 的引入是架構複雜度的顯著上升（一個元件變三個）。明確的觸發條件：

• 背壓（429 回應）頻繁觸發（每天 > 100 次）且持續（不只是瞬間 burst）
• 寫入延遲的 P95 超過 500ms（DB 成為瓶頸）
• 需要多個 consumer（同一批事件要送到不同的下游 — analytics DB、alert engine、archive）

監控系統的 Queue 架構

1SDK ──→ Collector (ingestion only)
2           │
3           ├─ 驗證 JSON Schema
4           ├─ Redaction
5           └─ 寫入 Queue
6                 │
7                 ├── Worker A → PostgreSQL（主 storage）
8                 ├── Worker B → 降採樣 → Summary tables
9                 └── Worker C → Rule engine → Alert

Collector 瘦身為 ingestion-only — 只做接收、驗證、redaction 和寫入 queue。Storage 寫入、降採樣、rule engine 都移到 worker 群。Collector 的吞吐瓶頸從 DB 寫入變成 queue 寫入（queue 的寫入吞吐通常是 DB 的 10-100 倍）。

下一步路由

• 突發流量的分類 → 突發流量的分類
• 降級策略 → 降級策略
• 規模分級的完整應對 → 規模分級應對表
• Queue 的選型和操作實務 → backend 非同步佇列

事件本身

2025 末 CoreWeave 收購 Bufstream。Bufstream 來自 Buf 公司、Buf 從 Google 開源的 Protobuf 生態系做起、發展出 Schema Registry 跟相容 Kafka 的串流基礎設施。CoreWeave 從 Crypto 轉型成 GPU 算力租借巨頭、2024 上市、市值規模達數百億美元。

這起收購接在 2024 年 WarpStream 被 Confluent 收購、Aiven 跟 AutoMQ 各自鞏固位置之後、屬於串流市場整併週期的一環。

理解 Bufstream 的策略路徑、需要先理解 Schema vs non-Schema（raw bytes）的長期爭論。資料庫領域奠基者之一 Mike Stonebraker（圖靈獎得主）近年先後公開批評 MapReduce 脫離 Schema 是設計缺失、streaming 上沒有 Schema 也屬同類議題。Buf 的整套主張—從 Protobuf 生態系到 Buf Schema Registry 再到 Bufstream—延續 Schema 派立場：Schema 應當是企業內部所有微服務通訊、資料儲存與串流處理的「唯一真實來源」。Bufstream 是 schema-first 哲學在 streaming 層的延伸、不是純粹的技術產品。

主流公開討論集中在「又一筆 M&A」的表面敘事。本篇焦點在這起收購揭露的兩個結構性趨勢、以及對資料工程師職涯的意涵。

串流市場的整併週期

什麼是 Kafka？它是一個資料管路工具、讓不同系統之間的資料即時流動（例如使用者下訂單後、訂單資料即時流給庫存系統、出貨系統、會計系統）。Kafka 是 LinkedIn 開源的、市場上有多家廠商基於 Kafka 賣商業服務。

2024-2025 年這個 Kafka 商業服務市場玩家收斂明顯：

• 2024 年 WarpStream（一家做 Diskless Kafka 架構的新創）被 Confluent 收購
• 2025 年 Bufstream（Buf 公司的 Kafka 服務）被 CoreWeave 收購
• 未來幾年可能還有後續整併

市場進入殘酷的 整併週期（一個市場成熟之後、玩家數量會從多收斂到少、靠併購完成）—新進者沒有獨家差異化資產就很難留下。

Buf 在 streaming（即時資料流動）賽道的位置就反映這個結構。Buf 持有的差異化是 Schema（資料的結構描述、確保系統之間溝通有共識）哲學深度、但在 streaming 層缺三個關鍵資產：

• 自有銷售通路：Confluent 由 Kafka 原作者創辦、自帶銷售管道跟 Kafka 社群信任；Buf 沒有這個
• Diskless 架構先發優勢：Diskless 是把 Kafka 從「自己管硬碟」改成「丟到雲端便宜物件儲存（如 AWS S3）」、成本可顯著低於傳統架構；WarpStream 是 Diskless 先驅、AutoMQ 也已起步、Bufstream 後發
• 自有生態系：Aiven（北歐託管多種開源資料服務的公司）已建立託管平台、客戶在 Aiven 上同時用多個服務；Buf 沒有這層

在這個競爭格局裡、Bufstream 進市場時已處於 紅海（已經被大家搶得頭破血流的成熟市場）後段、繼續競爭的邊際報酬遞減、整併出場是合理選項。這是整併週期的標準劇本—新進者缺差異化、整併或收掉是兩條主要出路。

對想進串流市場的新創來說、這個整併週期的意涵是：在 Confluent 主導 + Diskless 已有先發 + 託管市場 Aiven 卡位之後、第四個進場的差異化空間有限。要進這個市場、得帶顛覆性差異化（例如新一代非 Kafka 的串流架構、或極端垂直化的應用層）、否則整併是合理預期出路。

算力廠商垂直整合資料基礎設施

CoreWeave 出手的動機跟傳統 SaaS 公司買競爭對手不一樣。傳統 SaaS 買競爭對手是為了市佔率（買掉對手讓自己市佔變大）。CoreWeave 這種算力廠商買 streaming 工具的動機完全不同—是為了把「資料管路」這層放進自己控制範圍、不要被第三方廠商卡脖子。

為什麼？因為訓練大型 AI 模型的經濟結構很特殊：

訓練一個 AI 模型需要數以萬計的 GPU 節點同時運作。每個 GPU 一小時租金可能上千美元、數萬個 GPU 同時跑、一小時的營收規模驚人。但這些 GPU 一邊跑訓練、一邊產生海量資料：

• 遙測資料（每個 GPU 的健康狀況、溫度、效能指標）
• 模型權重快照（訓練過程的階段性備份、Disaster Recovery 用）
• 梯度更新紀錄（演算法每一步調整模型的紀錄）
• 線上評估指標（模型表現好不好的即時數字）

這些資料必須即時傳輸跟儲存。如果資料管路（也就是 streaming）出問題、GPU 就只能等資料、不能算—GPU 閒置一秒就是一秒的營收損失。

舉個算式：

• 假設 CoreWeave 一個 GPU 一小時租金 5 美元、一個訓練集群有 1 萬個 GPU
• 集群每小時營收 = 5 × 10,000 = 5 萬美元
• 如果 streaming 故障讓 GPU 閒置 1 小時、損失 5 萬美元
• 如果第三方 streaming 廠商的 SLA（服務等級協議、保證最低可用性）寫的是「99.9% 可用」、意思是一年最多可以閒置 8.76 小時、損失上限 43 萬美元

對按小時計費的算力服務商來說、streaming 不是「可選的工具」、是「直接決定營收的命脈」（剛需、客戶非要不可的需求）。CoreWeave 收 Bufstream 的本質、是把 streaming 從「外部第三方依賴」轉為「內部自己控制的基礎設施」、避免外部 SLA 成為訓練流程的瓶頸。

這個動機跟 CoreWeave 過去收購軌跡一致—Weights & Biases（AI 訓練的觀測平台）、Conductor AI（AI 工作流編排）、Bufstream（streaming）—都是 vertical AI stack（從硬體到應用的整套垂直 AI 平台）的拼圖、目標是對抗 AWS Bedrock、Azure ML 這些 Hyperscaler（超大規模雲端廠商）的 AI 平台堆疊。

當算力廠商成為主要併購買方、市場整併方向就會偏向「服務 AI workload（AI 工作負載）的基礎設施」、不是傳統 IT 基礎設施。這個訊號對未來幾年資料基礎設施的併購輪廓很有參考價值—下一輪會被買的目標、可能是 observability（系統觀測工具）、storage（儲存系統）、metadata 管理工具等、同樣對 AI workload 是剛需的工具。

Diskless Kafka 的未來與市場格局

這起收購最大的市場討論點是 Diskless Kafka 的未來。

傳統 Kafka 設計：每台 Kafka 伺服器都有自己的硬碟、資料寫進來先存在本地硬碟、再複製到其他伺服器當備份。可靠但成本高—要買一堆 Kafka 專用的高效能硬碟伺服器、而且還要存好幾份。

Diskless 架構：Kafka 伺服器不存本地硬碟了、直接把資料丟到便宜的雲端物件儲存（像 AWS S3）。成本可顯著低於傳統架構、但效能、延遲是技術挑戰。

既然 Kafka 依然是資料工程中無可替代的角色、而在 紅海 競爭下「成本」已經成為最大亮點、市場上能選的大型方案收斂到剩下：

至於 Apache Kafka 社群版 Diskless 架構、預期仍需數個版本週期才能達到生產就緒—開源社群協調速度比商業公司慢、但技術方向跟商業版的成本壓力一致。

兩個趨勢的疊加效應

「整併週期」跟「算力廠商垂直整合」兩個趨勢同時發生並互相強化。整併週期的買方需要明確的「為什麼買」理由、算力廠商剛好提供了這個理由：垂直整合資料基礎設施、避免外部 SLA 拖累自己的單位營收。

兩個趨勢疊加產生的次生效應：

• 整併市場的買方結構從「同業 + PE」變成「同業 + PE + 算力廠商」
• 被併購標的的估值判讀要納入「對算力廠商的戰略價值」、不只「同業 ARR multiple」
• 留下的獨立玩家面對「同業 + 算力廠商雙重收購壓力」、自主路線越來越難維持

長期影響

長期看：

整併週期：串流市場玩家會繼續往少數玩家收斂、新進者很難找空間、除非有顛覆性差異化（例如新一代非 Kafka 串流架構）。

算力廠商垂直整合：CoreWeave 不會是最後一個—未來會有更多算力廠商收購資料基礎設施（streaming、observability、storage）。原因是按小時計費的 GPU 服務不能受制於第三方—任何資料管路延遲都是直接的營收損失。

對資料工程師：資料工程的戰略位置從「服務內部 BI / 報表」升級為「直接影響 GPU 利用率與訓練吞吐量」。過去資料工程屬於後端營運層、影響範圍限於內部報表與分析；現在因為 AI 訓練對資料流動是剛需、資料管路效能直接決定 GPU 利用率、進而決定算力服務商的單位營收。

對資料工程師職涯的訊號

過去資料工程屬於後端營運層、影響範圍限於內部報表與分析。現在因為 AI 訓練對資料流動是剛需、資料工程的影響範圍延伸到算力服務商的單位營收與訓練吞吐量。CoreWeave 願意以併購規模投資串流基礎設施、反映該層對算力商業模式是不可外包的依賴項。

職涯方向訊號：

• 往「服務 AI workload 的資料基礎設施」走：GPU 遙測、模型快照、梯度紀錄、評估指標的 streaming
• 累積跨服務的整合能力：訊息佇列、Object Storage、Observability 的銜接
• 理解上游算力商業化的 GTM：知道為什麼算力廠商要垂直整合、就能判斷自己該往哪走

預警訊號：何時要重新評估這個分析

關鍵假設要監控：

假設一：AI 訓練對 streaming IO 的剛需會持續。 監控訊號：訓練模式變革（例如純檔案系統訓練、不需要 streaming），或新硬體大幅降低 IO 瓶頸（例如 PCIe 6.0、CXL）。如果剛需減弱、算力廠商不再有垂直整合動機。

假設二：串流市場真的進到整併末段。 監控訊號：新一輪融資金額、新公司獲投情況。如果有新一波創新出現（例如 Iceberg-style 開放標準改變整個市場結構）、整併可能逆轉成新一輪百家爭鳴。

假設三：開源 Apache Kafka Diskless 會醞釀成功。 監控訊號：Apache Kafka 社群版 KIP 提案的合併進度。如果開源版本成熟、商業版的價值會被擠壓。

下面任一具體訊號出現、要重新評估這套分析：

判讀框架

這個框架的可遷移性：當任何按用量計費的基礎服務商（算力、頻寬、儲存）開始垂直整合相鄰基礎設施時、同樣可以套這個結構問—「整併到哪一段了」「為什麼這個 buyer 出現」「對下游從業者意味著什麼」。

延伸閱讀

• FDE 軍備競賽：SaaS 三支柱鬆動下的結構性轉變 — 上游模型供應商的商業化壓力
• Claude for Legal 之後：應用層、新創、知識工作者的三層擠壓 — 應用層怎麼被擠壓
• Backend 模組的 訊息佇列章節 — Kafka 技術細節
• 整併週期、剛需、紅海 卡片

本文是 Kafka overview「進階主題」的 implementation-layer deep article，承接 overview「Consumer lag 暴增」與「Rebalance storm」兩段判讀原則的展開。Overview 給判讀方向，本文給 protocol 機制、診斷指令與故障演練。

Rebalance 是 consumer group 重新分配 partition 所有權的協調過程

Rebalance 是 consumer group coordinator 把 topic 的 partition 重新分配給 group 內 consumer 的協調動作，承擔「在成員數變動時維持每個 partition 恰好被一個 consumer 消費」這個責任。觸發條件是 group membership 改變：consumer 加入、consumer 離開、consumer 被判定失效，或 topic partition 數增加。Rebalance 完成前，受影響的 partition 暫停消費，這段空窗就是 rebalance 對 lag 的直接代價。

Consumer group 是 Kafka 把「一份 event stream 分給多個 worker 平行處理」與「同一份 stream 給多個獨立應用各自 replay」兩種需求統一的抽象。同一個 group 內的 consumer 瓜分 partition、彼此不重複消費；不同 group 各自維護 offset、互不干擾。Rebalance 只在 group 內部發生，調整的是 group 內 partition 對 consumer 的 mapping。本文聚焦 group 內 rebalance 的機制與診斷，group 概念本身見 consumer group 知識卡。

實機觀察 partition 如何在兩個 consumer 間分配：同一 group 起兩個 consumer，coordinator 把 3 個 partition 拆給它們。

1GROUP    CONSUMER-ID    CLIENT-ID    #PARTITIONS  CURRENT-ASSIGNMENT
2live-cg  consumer-A-... consumer-A   2            orders:0,1
3live-cg  consumer-B-... consumer-B   1            orders:2
4
5GROUP    ASSIGNMENT-STRATEGY  STATE    #MEMBERS
6live-cg  range                Stable   2

consumer-A 拿到 partition 0、1，consumer-B 拿到 partition 2，STATE 是 Stable 代表 rebalance 已收斂。ASSIGNMENT-STRATEGY 顯示 range，是預設的 partition 分配演算法。

Eager 與 cooperative incremental 是兩種 rebalance protocol

Rebalance protocol 決定「rebalance 期間 consumer 要不要交出手上全部 partition」，這個選擇直接決定 rebalance 的 stop-the-world 範圍。Kafka 提供兩種：eager 與 cooperative incremental。

Eager rebalance 是早期預設行為：rebalance 觸發時，group 內所有 consumer 先放棄手上全部 partition（revoke all），等 coordinator 算完新分配後再各自重新 assign。代價是 rebalance 期間整個 group 完全停止消費，即使某個 consumer 的 partition 在新舊分配中根本沒變，它也得先放掉再拿回。Group 規模越大、partition 越多，這個全停窗口越痛。

Cooperative incremental rebalance 改成「只 revoke 真正要換手的 partition」。Consumer 先回報自己想保留的 partition，coordinator 算出哪些 partition 需要從 A 搬到 B，只有這些 partition 經歷一次 revoke + reassign，其餘 partition 持續消費不中斷。代價是一次完整 rebalance 可能需要兩輪（第一輪 revoke、第二輪 assign），但每輪只影響少數 partition，整體可用性遠高於 eager。Kafka 2.4 起的 CooperativeStickyAssignor 實作這套協議。

實機驗證 cooperative-sticky 可由 consumer 端 config 啟用，ASSIGNMENT-STRATEGY 欄位反映實際生效的策略：

1kafka-console-consumer.sh --topic orders --bootstrap-server localhost:9092 \
2  --group coop-cg \
3  --consumer-property partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor

1GROUP    ASSIGNMENT-STRATEGY  STATE    #MEMBERS
2coop-cg  cooperative-sticky   Stable   1

選 protocol 的判準是 group 規模與消費中斷的容忍度：

對 partition 數上百、consumer 數十的 group，eager 的全停窗口會讓每次 deploy 都產生明顯 lag spike。Walmart 每天 trillions of message、25K+ consumer 跑在 K8s，pod scaling 與 deploy 觸發的 rebalance 是最大痛點（3.C17）；這種規模下 eager 的全停代價無法接受，cooperative 把中斷限縮到換手 partition 是基本要求。但 Walmart 進一步發現，即使換成 cooperative，partition-consumer 1:1 模型本身在 K8s 規模仍撞到擴張極限，最終把 consumer 解耦成 stateless service。Protocol 選擇降低單次 rebalance 代價，架構解耦才解決 rebalance 頻率本身。

切換 protocol 不能直接全量改：eager 與 cooperative 的 consumer 不能在同一 group 共存。滾動升級時，consumer 需先支援兩種 protocol、再分批切換 config，否則混用會導致 rebalance 失敗或 assignment 不一致。

三個 timeout 各自負責不同的失效判定

Consumer 存活由三個 timeout 共同把關，每個負責不同層次的失效訊號，混為一談是 rebalance 誤判的主要來源。

session.timeout.ms 是 coordinator 等待 consumer heartbeat 的上限。Consumer 背景執行緒週期性送 heartbeat，coordinator 在這個時間內沒收到就判定 consumer 死亡、觸發 rebalance。預設 45 秒（早期版本 10 秒）。值太小，短暫 GC pause 或網路抖動就誤判離線；值太大，真正死掉的 consumer 要拖很久才被踢出，lag 持續累積。

heartbeat.interval.ms 是 consumer 送 heartbeat 的頻率，必須明顯小於 session.timeout.ms，慣例設成 1/3。它決定 coordinator 多快能感知 consumer 變化，也決定 rebalance 訊號的傳播速度。值太大，session window 內 heartbeat 次數不足，容錯空間消失。

max.poll.interval.ms 是兩次 poll() 呼叫之間的上限，負責偵測「consumer 活著但卡住」。Consumer 主執行緒在 poll() 之間處理拉到的訊息，如果單批處理太久（下游 I/O 慢、batch 太大、業務邏輯重）超過這個時間，coordinator 判定 consumer 失去處理能力、把它踢出 group。預設 5 分鐘。它跟 session.timeout.ms 的分工是：heartbeat 偵測「行程是否還在」，max.poll.interval 偵測「行程是否還在前進」。

這三個值的常見錯配，是把處理變慢誤當成 consumer 死亡。下游 DB 變慢導致每批處理超過 max.poll.interval.ms，consumer 被踢出觸發 rebalance，partition 搬到別的 consumer，那個 consumer 同樣被同一個慢下游拖垮，再次被踢，形成連環 rebalance。這種情況調 session.timeout.ms 沒用，因為 heartbeat 執行緒一直正常送；要調的是 max.poll.interval.ms 或縮小 max.poll.records 讓單批更快做完。

Static group membership 讓 consumer 重啟不觸發 rebalance

Static membership 給 consumer 一個固定身分 group.instance.id，讓 coordinator 在 consumer 短暫離線後保留它的 partition 分配，承擔「滾動重啟與短暫中斷不觸發 rebalance」的責任。沒有 static membership 時，consumer 每次重啟都產生一個新的 member id，coordinator 視為「舊成員離開、新成員加入」、觸發兩次 rebalance。

設定方式是給每個 consumer 一個跨重啟穩定的 group.instance.id。Coordinator 看到帶 instance id 的 consumer 離線時，不立即 revoke 它的 partition，而是等到 session.timeout.ms 真正超時才判定永久離線。在這個窗口內 consumer 帶同一個 instance id 回來，直接接回原本的 partition，不觸發 rebalance。

實機驗證 group.instance.id 生效後，--members 輸出多出 GROUP-INSTANCE-ID 欄位：

1kafka-console-consumer.sh --topic orders --bootstrap-server localhost:9092 \
2  --group static-cg --consumer-property group.instance.id=static-member-1

1GROUP      CONSUMER-ID            GROUP-INSTANCE-ID  CLIENT-ID  #PARTITIONS
2static-cg  static-member-1-...    static-member-1    static-A   3

static membership 的關鍵搭配是把 session.timeout.ms 設得比預期的重啟時間長。K8s 滾動更新一個 pod 重啟可能 10-30 秒，session.timeout.ms 要涵蓋這段，否則 pod 還在重啟、coordinator 已判定永久離線、partition 已搬走，static membership 失去意義。代價是真正死掉的 consumer 也要拖到 session.timeout.ms 才被踢出，這段 partition 無人消費。Static membership 用「容忍較長的真實故障偵測延遲」換「消除重啟造成的 rebalance」，適合重啟頻繁但硬故障罕見的環境。

用 kafka-consumer-groups.sh 讀 lag 分布

診斷 lag 的起點是 kafka-consumer-groups.sh --describe，它逐 partition 列出 current offset、log end offset 與兩者差值 lag，承擔「定位 lag 集中在哪、規模多大」的責任。Lag 是某 partition 已產出的最新 offset 減去 consumer 已 commit 的 offset，代表還沒被消費的訊息量。

實機製造 lag：produce 30 筆訊息、consumer 只消費 12 筆就停掉，--describe 顯示逐 partition 的消費進度落後：

1kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group analytics-cg

1GROUP         TOPIC   PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG  CONSUMER-ID
2analytics-cg  orders  0          9               9               0    -
3analytics-cg  orders  1          3               9               6    -
4analytics-cg  orders  2          0               12              12   -

這份輸出本身就是診斷的第一個分岔點：lag 是均勻分布還是集中在少數 partition。這裡 partition 0 lag=0、partition 1 lag=6、partition 2 lag=12，明顯集中在後兩個 partition，指向 partition 層的不平衡而非整體 consumer 不足。

--state 看 group 的健康狀態與分配策略，--members --verbose 看每個 consumer 實際拿到哪些 partition：

1kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group live-cg --state

1GROUP    COORDINATOR (ID)     ASSIGNMENT-STRATEGY  STATE    #MEMBERS
2live-cg  localhost:9092 (1)   range                Stable   2

STATE 的取值是診斷訊號：Stable 代表分配已收斂正常消費；PreparingRebalance / CompletingRebalance 代表正在 rebalance；Empty 代表 group 沒有 active member（offset 還在但沒人消費），對應上面 lag 輸出裡 CONSUMER-ID 全是 - 的情況。看到 lag 持續累積又長期停在 rebalance 狀態，問題就在 rebalance 本身而非消費速度。

Lag 均勻分布與集中單一 partition 指向不同根因

Lag 的分布形狀是診斷的主軸：均勻分布指向消費總能力不足，集中在少數 partition 指向 key 分布或單 partition 的局部問題。同樣是 lag 高，這兩種形狀的修法完全相反，先讀分布再決定方向。

Lag 均勻分布在所有 partition，代表 consumer group 整體消費速度跟不上 producer 寫入速度。根因在消費側的總吞吐：consumer 數量不足、單 consumer 處理慢（CPU / GC / 下游 I/O）、或 producer 突發流量超過 group 設計容量。修法是擴消費能力：加 consumer（上限是 partition 數）、優化單筆處理、或對下游加 batch。如果 lag 隨時間線性成長且各 partition 同步成長，是穩態的容量不足，要重新評估 partition 數與 consumer 數。

Lag 集中在少數 partition、其餘 partition lag 接近零，代表負載不均，根因通常在 key 分布。Producer 用 key 決定 partition（hash(key) % partition_count），如果某些 key 是熱點（例如某個大客戶的 id、某個 null key 全落同一 partition），對應 partition 的訊息量遠高於其他，負責它的 consumer 再快也追不上，而其他 consumer 閒著。加 consumer 不解決這個問題，因為瓶頸 partition 仍只能被一個 consumer 消費。修法在 key 設計：拆熱點 key、加 salt 打散、或對熱點走獨立 topic。

Airbnb 的 logging pipeline 遇到的正是 partition 層 skew：event size 從幾百 bytes 到幾百 KB、QPS 跨數個量級，Spark 一個 partition 對一個 task，造成 data skew，catch-up 一個 4 小時 lag 要再花 4 小時（3.C15）。它的解法揭露一個關鍵判準：partition 數不該等同 consumer parallelism。當 lag 集中在少數重 partition，加 consumer 受限於 partition 數的天花板無效，要把 parallelism 從 partition 數解耦、按 event volume × size 重新分派 work。這把「lag 集中」的診斷從 key 分布延伸到了 work 分派模型本身。

判讀順序固定：先 --describe 看分布形狀，再決定往「擴容」還是「重分布」走。跳過分布判讀直接加 consumer，遇到熱點 partition 場景會白花資源還解不了 lag。

Production 故障演練

Case 1：consumer 處理慢被踢出 group 形成 rebalance 連環

徵兆：consumer log 反覆出現 Member ... sending LeaveGroup request 與 Attempt to heartbeat failed since group is rebalancing；lag 持續成長；group STATE 在 Stable 與 PreparingRebalance 之間反覆跳；同一批 partition 在不同 consumer 間反覆搬移。

根因：下游 I/O 變慢（DB 連線池打滿、外部 API 延遲升高），consumer 單批 poll() 後處理超過 max.poll.interval.ms（預設 5 分鐘），coordinator 判定該 consumer 失去處理能力、踢出 group、觸發 rebalance。partition 搬到另一個 consumer，後者面對同樣慢的下游、同樣超時被踢，rebalance 連環觸發，每次 rebalance 又讓所有 consumer 暫停消費，lag 加速惡化。

修法：

1. 確認瓶頸是處理慢而非 heartbeat 中斷：consumer log 若有正常 heartbeat 但仍被踢，問題在 max.poll.interval.ms 不是 session.timeout.ms。
2. 縮小 max.poll.records：一次拉少一點，讓單批在 max.poll.interval.ms 內做完，這是不改下游就能止血的第一步。
3. 拉高 max.poll.interval.ms：給單批更長處理時間，但這只是延後而非解決，要搭配下游修復。
4. 修復下游根因：DB 連線池、外部 API 超時、batch 寫入策略，這才是消除連環 rebalance 的根本。

Case 2：lag 集中單一 partition、加 consumer 無效

徵兆：--describe 顯示一兩個 partition lag 數十萬、其餘 partition lag 接近零；加了 consumer 之後 lag 不降，新 consumer 處於閒置（--members 顯示它分到的 partition 都沒 lag）。

根因：producer 的 key 分布有熱點，大量訊息落在同一 partition。Partition 是 Kafka 平行消費的最小單位，一個 partition 只能被 group 內一個 consumer 消費，熱點 partition 的消費速度被單 consumer 鎖死，加再多 consumer 都分不到這個 partition 的工作。

修法：

1. --describe 確認 lag 集中形狀，排除「整體容量不足」的均勻分布情境。
2. 找出熱點 key：抽樣訊息看 key 分布，常見是 null key（全落同一 partition）或單一大租戶 id。
3. 重設計 key：對熱點加 salt 打散到多 partition，或讓熱點走獨立 topic 用更多 partition。
4. 若 work 本身有 skew（單筆訊息處理成本差異大），把 parallelism 從 partition 數解耦，按工作量重新分派，如 Airbnb 的 balanced reader（3.C15）。

key 重分布需要 producer 端配合改 key 策略，對既有 topic 是破壞性變更（舊訊息 key 不變），通常搭配新 topic 切換。本文未實機驗證 producer key 重設計的線上切換流程，依官方分區語義說明。

Case 3：deploy 每次都產生 lag spike

徵兆：每次滾動部署 consumer 服務，lag 在部署窗口內明顯上升、部署完成後緩慢回落；group STATE 在部署期間進入 rebalance；部署越頻繁，累積 lag 越明顯。

根因：每個 consumer pod 重啟，coordinator 看到舊 member 離開、新 member 加入，觸發 rebalance；若用 eager protocol，每次 rebalance 全 group 停止消費；滾動部署逐個重啟 N 個 pod 就觸發 N 次 rebalance，每次全停，lag 在這串全停窗口中累積。

修法：

1. 啟用 static membership：給每個 consumer 固定 group.instance.id，重啟時帶同一身分回來、不觸發 rebalance。
2. 把 session.timeout.ms 設得比 pod 重啟時間長：涵蓋 K8s 重啟一個 pod 的 10-30 秒，否則 static membership 在窗口內失效。
3. 切換到 cooperative incremental protocol：即使仍有 rebalance，只有換手 partition 中斷，未換手 partition 持續消費。
4. 控制部署並行度：一次重啟太多 pod 會放大同時 rebalance 的影響，分批滾動。

Walmart 在 25K+ consumer 規模下，正是 pod scaling / deploy / heartbeat fail 三類事件持續觸發 rebalance lag spike（3.C17）；static membership 與 cooperative 降低單次代價，但它最終把 consumer 解耦成可獨立 auto-scale 的 stateless service，從架構層消除 rebalance 與 partition 數的綁定。

Case 4：scale-to-zero 後冷啟動 lag

徵兆：低流量時段 consumer 被縮到 0，流量回來時 lag 已累積一批、需要一段 catch-up；autoscaler 若看 CPU / memory 反應遲鈍，因為 sink 多為 I/O bottleneck、CPU 平坦不觸發擴容。

根因：event-driven workload 的工作量是 backlog（lag）而非 resource usage。用 CPU / memory 當 scaling signal，在 I/O-bound 的 sink consumer 上失靈：訊息堆積但 CPU 不高，autoscaler 不動，lag 持續成長。

修法：

1. 用 consumer lag 當 scaling signal：lag 超過閾值就擴 consumer、lag 清空就縮，直接對齊工作量。
2. 接受 scale-to-zero 的冷啟動 lag 為設計取捨：minReplicaCount=0 省下 idle 成本，代價是流量回來時的 catch-up 窗口，對非即時 sink 可接受。
3. 設 lag 閾值與擴容步長：閾值太高 catch-up 久、太低頻繁擴縮，依 SLA 對 backlog 的容忍度設定。

Trivago 跨 3 region 跑 50+ Kafka sink、每個 always-on 用 1 CPU + 1 GB，CPU/mem autoscaling 對 I/O-bound sink 無效；改用 KEDA 以 consumer lag 為 scaling signal、minReplicaCount=0 達到 scale-to-zero，daily replica-hour 從 50 降到 1-2（3.C22）。這個案例的判準是 resource usage 不等於工作量，event-driven 場景該看 backlog signal。

Capacity 與 cost

Rebalance 與 lag 的容量規劃圍繞三個變數：partition 數、consumer 數、單次 rebalance 的中斷成本。partition 數是消費平行度的天花板，consumer 數超過 partition 數時多出的 consumer 閒置，所以 partition 數要按峰值需要的平行度規劃，但 partition 過多會推高 metadata 壓力與 rebalance 計算成本。

實務 default：partition 數按峰值平行度設、保留成長餘量但不過度分區；consumer 數對齊 partition 數、用 lag 而非 CPU 當 autoscaling signal；rebalance 頻繁的環境優先 static membership + cooperative，再評估是否需要把 consumer 從 partition 解耦。加 partition 是單向操作（無法縮回），且改變既有 key 的 partition 對應，要在規劃期一次設足而非事後頻繁調整。

整合與下一步

Rebalance 與 lag 診斷接在 consumer 設計與交付語義之上：commit 策略決定 lag 的計算基準與 rebalance 後的重複消費風險，交付語義決定 rebalance 中斷期間訊息是否可能丟失或重放。

跟 consumer 設計對位

3.4 consumer 設計 涵蓋 commit 策略（auto vs manual）、commit 時機與 partition 分配的整體設計。本文的 rebalance 是 consumer 設計在「成員變動」維度的展開，lag 是 commit 進度的可觀測量。commit 策略選錯會在 rebalance 後放大重複消費或丟失。

跟交付與復原語義對位

3.6 processing 與 recovery 語義 涵蓋 rebalance 中斷期間的 at-least-once / at-most-once 行為。rebalance revoke partition 時，未 commit 的進度會在新 consumer 接手後重放（at-least-once）；commit 太早則可能在 rebalance 中丟失（at-most-once）。idempotency 與 replay 的整體設計見 6.12 idempotency / replay。

相關案例

• 3.C15 Airbnb Spark Streaming — partition-task 1:1 造成 data skew、parallelism 從 partition 數解耦
• 3.C17 Walmart MPS — 25K+ consumer 在 K8s 的 rebalance storm、consumer 解耦成 stateless service
• 3.C22 Trivago KEDA — consumer lag 驅動 scale-to-zero、backlog signal 取代 resource usage

相關連結

• 上游 vendor 頁：Apache Kafka
• 知識卡：consumer lag、consumer group、partition
• 下游能力：3.4 consumer 設計、3.6 processing 與 recovery 語義

本文是跨 vendor migration playbook、cross-link 到 RabbitMQ 跟 Kafka。跟同類產品的 drop-in 或 operational 遷移不同、本篇是 paradigm shift — 兩端不是「同類 broker 的不同實作」、是 不同責任模型的 messaging system：RabbitMQ 是「處理即承諾」的 work queue、Kafka 是「寫入即承諾、可長期 replay」的 event log。

RabbitMQ → Kafka 不是把 queue 換成 topic

RabbitMQ 跟 Kafka 都被歸在「message queue」這個傘狀詞下、但兩者承擔的責任不同。RabbitMQ 的可靠性建立在 consumer 處理完才 ack、未 ack 的訊息 broker 重新投遞；訊息一旦被成功消費就從 queue 移除、broker 是「任務分派 + 重試」的中介。Kafka 的可靠性建立在 訊息寫進 partition log 就持久化、consumer 各自維護 offset；訊息在 retention 期內一直留著、broker 是「事件儲存 + 多方各自讀取」的 log。

把 RabbitMQ「migration」成 Kafka 的字面理解通常是：queue 對 topic、exchange 對 producer key、consumer 對 consumer group。這個對映在 transport 層成立、在責任層不成立。RabbitMQ 一個 message 被 ack 後就消失、Kafka 一個 message 寫進 log 後對所有 consumer group 都還在；RabbitMQ 的 routing 由 broker 端 exchange + binding 決定、Kafka 的「routing」由 producer 端 partition key 決定、broker 不做內容路由。先確認這層差異、再決定哪些 workload 值得遷。

6 維 diff dimension audit

跨 vendor 遷移前先盤點 source 跟 target 在六個維度的落差、用最大落差維度決定 playbook 結構、而不是反過來套既有模板。RabbitMQ → Kafka 的 audit 結果：

三個維度 High：paradigm、application change、data topology。其中 paradigm 是主導維度 —— application change 跟 data topology 的落差都是 paradigm 落差的下游結果。consumer 要重寫，是因為「ack 後即刪」變成「offset 不刪」；資料拓樸要重劃，是因為「broker 路由到 queue」變成「producer 決定 partition」。

主導維度是 paradigm、對映 Type E paradigm shift 結構：先講「字面 migration 不成立」、再講適配度（什麼能遷什麼不能）、再講 application 重設計與部分 cutover、最後是長期混合架構。application change 跟 data topology 這兩個高維度不另起 playbook、而是落在 application 重設計段與故障演練段裡展開。

為什麼 paradigm 是主導、不是 application change

application change 看起來工作量最大（consumer / producer 都要改），直覺會把它當主導維度。但 application change 的方向跟難度是由 paradigm 決定的：如果只是 AMQP client 換 Kafka client、心智模型不變，那 application change 是機械式翻譯、屬於 Schema/API 維度。實際上 consumer 不只是換 SDK、是要把「處理完才 ack、失敗就 nack 重投」的設計改成「拉一批、處理、commit offset、失敗自己重試或寫 DLQ topic」—— 這是責任模型的改變，不是 API 的改變。所以主結構走 paradigm、application change 是它的展開。

什麼 workload 真該遷、什麼不該

判讀的核心問題是：這個 workload 需要的是「處理一次就完成的任務」、還是「被多方各自讀取、可回放的事件」。

任務分派場景不該遷。寄信、轉檔、生成縮圖這類 workload 的本質是「有一個工人池、把任務做完就結束」、RabbitMQ 的 manual ack + prefetch + DLX 對這條路徑是貼合的設計。把它搬到 Kafka 會引入不需要的複雜度：partition 數要規劃、consumer group rebalance 要管、offset commit 時機要自己設計、而換來的 replay 能力在「任務做完就丟」的場景根本用不到。單純 work queue 不需要 Kafka 是這篇 playbook 最該先說清楚的判讀。

事件流場景該遷。當同一份事件要被 analytics pipeline、search index sync、audit log、下游微服務各自消費、而且各自進度不同、偶爾要回放過去 N 天重算 —— RabbitMQ 的「ack 後即刪」就會逼出「為每個 consumer 複製一份 queue」的反模式，這正是 Kafka 的 consumer group + retention 要解的問題。

複雜 routing 場景要重新設計、不是平移。RabbitMQ 的 topic exchange 用 order.*.created 這種 binding pattern 在 broker 端做內容路由、consumer 訂閱 binding 就收到符合的訊息。Kafka broker 不做內容路由，要嘛把路由邏輯前移到 producer（按內容決定寫哪個 topic / partition key），要嘛 consumer 端全收後自己 filter。直接平移會發現 Kafka 沒有 exchange 這個概念，routing 拓樸必須重新設計。

為什麼會考慮這個 paradigm shift

實務上從 RabbitMQ 評估遷往 Kafka 通常由三條 driver 觸發：

1. 同一事件要 fan-out 給愈來愈多 consumer：初期一個 queue 一個 worker、後來下游團隊一個個來要「也給我一份」。RabbitMQ 要嘛加 fanout exchange + 每團隊一個 queue、要嘛 consumer 互搶。Kafka 的 consumer group 天然支援「N 個獨立團隊各自從頭讀」、這是最常見的 driver。
2. 需要 replay 重算：下游邏輯出 bug、要重跑過去 7 天的事件修資料；RabbitMQ ack 後訊息已刪、無從回放。Kafka retention 期內可以從任意 offset 重讀。
3. 吞吐量壓到 RabbitMQ 的設計邊界：單 queue 的 throughput 受限於單一 queue 的處理模型、量大時要拆 queue 手動分流；Kafka 的 partition 並行是 first-class。

這三條 driver 都指向 event streaming 的特性、不是「Kafka 普遍比較好」。任務隊列場景套不上這三條 driver、就不該被這個評估帶著走。

Migration 結構：application 重設計 + 部分 cutover + 長期混合

RabbitMQ → Kafka 不是一次性 cutover，是按 workload 拆分、漸進遷移、長期共存：

1. Phase 0：workload 盤點 — 把現有 queue / exchange 逐一分類「適合 Kafka（event 性質）」vs「保留 RabbitMQ（task 性質）」。盤點輸出是清單，不是「全遷」。
2. Phase 1：application code 重設計 — 對判定要遷的 workload，重寫 producer（exchange routing → topic + partition key）跟 consumer（manual ack → offset commit + 自管重試 / DLQ）。這是 paradigm 翻譯，不是 SDK 替換。
3. Phase 2：dual-write 並行 — producer 同時寫 RabbitMQ 跟 Kafka、新 consumer 從 Kafka shadow consume 驗證行為對齊、舊 consumer 持續從 RabbitMQ 消費。
4. Phase 3：cutover 個別 workload — shadow 驗證通過後、把該 workload 的真正消費切到 Kafka、停掉 RabbitMQ 端的對應 consumer 與 dual-write。
5. Phase 4：長期混合 — task 性質的 workload 永遠留在 RabbitMQ、event 性質的在 Kafka。兩者共存是終態、不是過渡。

整體不是「把 RabbitMQ 換成 Kafka」、是「把適合 event log 的部分搬到 Kafka、其餘留在 RabbitMQ」。多數環境的終態是兩者並存。

Application 重設計範例：manual ack → offset commit

RabbitMQ consumer 的核心是 每個 message 處理完顯式 ack、broker 才認定投遞成功；失敗就 nack、broker 重投或進 DLX。Kafka consumer 沒有 per-message ack 的概念、是 批次拉取、處理、commit offset；commit 的是「讀到哪了」、不是「哪幾條成功了」。

 1# RabbitMQ 端：manual ack、per-message 成敗
 2channel.basic_qos(prefetch_count=10)
 3
 4def on_message(ch, method, properties, body):
 5    try:
 6        process(body)
 7        ch.basic_ack(delivery_tag=method.delivery_tag)
 8    except Exception:
 9        # 拒絕並不重新入列、由 DLX 接住
10        ch.basic_nack(delivery_tag=method.delivery_tag, requeue=False)
11
12channel.basic_consume(queue="orders", on_message_callback=on_message)
13channel.start_consuming()

 1# Kafka 端：批次 poll、處理後 commit offset
 2consumer = KafkaConsumer(
 3    "orders",
 4    group_id="orders-worker",
 5    enable_auto_commit=False,        # 關掉 auto commit、自己控制時機
 6    auto_offset_reset="earliest",
 7    max_poll_records=10,             # 對應 RabbitMQ 的 prefetch
 8)
 9
10for batch in iter_batches(consumer):
11    for msg in batch:
12        try:
13            process(msg.value)
14        except Exception:
15            send_to_dlq_topic(msg)   # 自建 DLQ topic、Kafka broker 不提供 DLX
16    consumer.commit()                # commit 的是 offset、不是個別 message

差異的關鍵不在 API 形狀、在責任邊界：

• RabbitMQ 一條失敗就 nack 一條、其餘正常 ack；Kafka commit 的是 offset 這個「水位線」、水位線以下視為已處理。失敗的單條訊息無法「跳過不 commit 但繼續往後」—— 要嘛阻塞、要嘛自己寫 DLQ topic 後讓 offset 照常前進。
• RabbitMQ 重試由 broker 負責（重投 / DLX）；Kafka 重試要 application 自己設計（原地重試 / 寫 retry topic / 寫 DLQ topic）。
• RabbitMQ prefetch 控制「broker 一次推幾條未 ack 的給我」；Kafka max.poll.records 控制「我一次 poll 拉幾條」—— 方向相反，一個是 broker push、一個是 consumer pull。

Production 故障演練

Case 1：manual ack 觀念帶到 offset commit、誤判「已處理」

徵兆：cutover 後某 worker crash 重啟、發現一批訊息被重複處理；或反過來、一批訊息明明沒處理成功卻再也讀不到。RabbitMQ 端跑了多年的 ack 邏輯搬過來就出事。

根因：把 RabbitMQ 的「per-message ack」心智直接套到 Kafka 的 offset commit。常見錯法是 enable.auto.commit=true + 預設 auto.commit.interval.ms、消費迴圈還沒處理完、背景 thread 已經把 offset commit 出去了 —— crash 後 offset 已前進、未處理的訊息永遠跳過（資料遺失）。或反過來、處理完才 commit 但 commit 失敗、重啟後從舊 offset 重讀（重複處理）。RabbitMQ 的 ack 是「這一條我處理完了」、Kafka 的 commit 是「這個 offset 之前我都讀過了」—— 後者是水位線、不是逐條確認。

修法：

1. 關掉 auto commit、手動 commit：enable.auto.commit=false、在一批訊息確實處理完之後才 commit()。
2. 接受 at-least-once、設計 idempotency：Kafka 的預設語意是 at-least-once、重啟重讀無法完全避免、consumer 端要用 message key + dedup store 顯式去重。對應 6.12 idempotency / replay。
3. commit 時機對齊處理邊界：批次處理完才 commit、不要一邊處理一邊讓背景 commit 跑在前面。

Case 2：routing key → partition key、ordering 邊界悄悄改變

徵兆：cutover 後同一個訂單的 created / paid / shipped 事件偶爾亂序到達 consumer；RabbitMQ 端用 consistent hash exchange 跑了兩年、同一訂單的事件一直是有序的。

根因：RabbitMQ 用 consistent hash exchange 把同 key 的訊息路由到同一個 queue、單一 consumer 順序處理就有序。Kafka 的 ordering 保證範圍是 單一 partition 內、跨 partition 無序。如果 producer 沒設 partition key、或設了但 key 選得不對（例如用 event type 當 key 而不是 order id）、同一訂單的事件就散到不同 partition、被不同 consumer 並行處理、ordering 就斷了。RabbitMQ 的 ordering 邊界是「queue」、Kafka 的 ordering 邊界是「partition key」—— 邊界從 broker 端的 binding 移到了 producer 端的 key 選擇。

修法：

1. ordering 單位當 partition key：需要保序的單位（order id / user id）設成 partition key、同 key 落同 partition。
2. 盤點現有 RabbitMQ 的保序假設：哪些 queue 隱含「同 key 有序」、把那個 key 顯式提升為 Kafka partition key。
3. 接受 partition 數限制並行：保序的代價是同 key 只能單一 partition、partition 數是並行上限；保序需求跟並行度需要一起設計。對應 Partition 卡。

Case 3：DLX → 自建 DLQ topic、毒訊息卡住整個 partition

徵兆：某條訊息 application 處理永遠拋例外、consumer 不斷在這條上重試、整個 partition 後面的訊息全卡住、consumer lag 暴增；RabbitMQ 端這種毒訊息會被 nack 進 DLX、不影響後面。

根因：RabbitMQ 有原生 DLX、處理失敗的訊息 nack 後自動進 dead-letter exchange、queue 繼續往下。Kafka broker 沒有 DLX 概念、也沒有「跳過這一條」的機制 —— offset 是連續水位線、要往後就得處理掉當前這條。如果 application 在毒訊息上無限重試、offset 永遠不前進、後面所有訊息餓死。把 RabbitMQ「broker 幫我處理毒訊息」的假設帶過來、就會卡死。

修法：

1. 自建 DLQ topic：consumer 端設重試上限、超過上限把訊息寫進專屬的 orders.DLQ topic、然後 commit offset 讓主流程前進。對應 Dead-letter queue 卡。
2. retry topic 分層：仿 RabbitMQ 的延遲重試、可以設 orders.retry.5s / orders.retry.1m 多層 retry topic、由獨立 consumer 延遲後重投主 topic。
3. DLQ 要有人看：自建 DLQ topic 不像 RabbitMQ management UI 有現成可視化、要主動監控 DLQ topic 的訊息數、否則毒訊息靜默堆積。

Case 4：prefetch → max.poll.records，poll 間隔超時觸發 rebalance

徵兆：consumer 處理一批訊息花的時間偏長、Kafka 突然判定這個 consumer 死了、觸發 rebalance、partition 被重新分配、同一批訊息被另一個 consumer 重複處理；RabbitMQ 端用 prefetch 控制併發從沒這問題。

根因：RabbitMQ prefetch 只控制「broker 一次最多推幾條未 ack 給這個 consumer」、處理多久 broker 不管。Kafka 用 max.poll.interval.ms 監控「兩次 poll 之間最多隔多久」、如果一批 max.poll.records 拉太多、處理超過 max.poll.interval.ms 還沒回來 poll、broker 認定 consumer 卡死、踢出 group 觸發 rebalance。把 prefetch 的數值直接套成 max.poll.records、又沒考慮單批處理時間、就會超時。

修法：

1. max.poll.records 配合單條處理時間設：一批的總處理時間要明顯小於 max.poll.interval.ms；處理慢就把 batch 設小。
2. 長處理 workload 調大 max.poll.interval.ms：單條本來就慢（呼叫外部 API）的、把 interval 放寬、或把處理移到另一個 thread pool、poll 迴圈只負責拉取。
3. 理解 push vs pull 的差異：RabbitMQ 是 broker push、consumer 慢只是堆積；Kafka 是 consumer pull、consumer 慢會被誤判為死亡。這層差異是 prefetch 跟 max.poll.records 不能直接對映的根因。對應 Consumer group 卡。

Case 5：RabbitMQ 即刪 vs Kafka retention、replay 行為差異炸出資料量

徵兆：團隊以為 Kafka「跟 RabbitMQ 一樣處理完就沒了」、結果 disk 持續長大；或反過來、需要 replay 時才發現 retention 設太短、要回放的事件已經被清掉。RabbitMQ 心智下「訊息消費完就不佔空間」的假設不成立。

根因：RabbitMQ ack 後訊息即刪、queue 的空間隨消費釋放。Kafka 寫進 log 後在 retention 期內一直留著、不管有沒有被消費 —— 這正是 replay 能力的來源、也是 disk 成本的來源。沒設好 retention，要嘛留太久 disk 爆、要嘛留太短該 replay 時沒得 replay。RabbitMQ 沒有「retention」這個旋鈕（它是 ack 即刪），Kafka 必須顯式設 retention policy。

修法：

1. 按 replay 需求設 retention：event sourcing 要回放幾天就設幾天的 retention.ms、不是抄 RabbitMQ 的「處理完即刪」心智。
2. 算清 retention 的 disk 成本：retention × 寫入速率 = 佔用空間、納入容量規劃；對比 RabbitMQ 只佔「未消費」的量、Kafka 佔「retention 期內全部」的量。
3. compact topic 給狀態類資料：如果只需要「每個 key 最新值」（像 RabbitMQ 不存在的場景）、用 cleanup.policy=compact 而非 time-based delete、避免無限長大。對應 Topic 卡的 retention policy。

漸進 cutover：dual-write 與 shadow consume

paradigm shift 不能一次切換、因為 consumer 行為（offset 語意、ordering、DLQ、重試）全變了、需要在真實流量下驗證新 consumer 跟舊 consumer 結果一致才敢切。漸進 cutover 用兩個機制：

dual-write：producer 同時往 RabbitMQ 跟 Kafka 寫同一份事件。RabbitMQ 端維持舊 consumer 正常生產、Kafka 端讓新 consumer 接收。dual-write 期間 RabbitMQ 仍是 source of truth、Kafka 只是並行驗證。要處理的細節是雙寫的一致性 —— 寫了 RabbitMQ 但 Kafka 寫失敗時怎麼辦、實務上通常容忍 Kafka 端短期缺漏（因為還沒切過去）、但要監控雙端的訊息數落差。

shadow consume：新的 Kafka consumer 跑完整處理邏輯、但 side effect 導到影子環境（寫影子 DB、不發真實 webhook、不寄真實信）。把 Kafka consumer 的處理結果跟 RabbitMQ consumer 的真實結果比對、確認 ordering、去重、DLQ 行為都對齊。shadow 期是 paradigm 翻譯正確性的驗證窗口、不是效能測試。

cutover 是 per-workload 的：某個 workload shadow 驗證通過、就把它的真實消費切到 Kafka、停掉該 workload 的 RabbitMQ consumer 與 dual-write；其他 workload 維持原狀繼續驗證。不是全站一次切。

Capacity / cost 對照

判讀：純 work queue 場景 RabbitMQ 的運維成本顯著低、Kafka 的 storage 跟運維是為了 replay 與高吞吐付的價。如果 workload 用不到 replay 跟跨 consumer group fan-out、遷到 Kafka 是用更高的成本換用不到的能力。

整合 / 下一步

混合架構是 long-term default

多數環境的終態是 RabbitMQ 與 Kafka 共存、各管各的責任：

1[task 分派：寄信 / 轉檔 / webhook]        [event log：CDC / 事件總線 / replay]
2         RabbitMQ                                    Kafka
3         │                                            │
4         └──────── Bridge（Connect source / 自寫）────┘

RabbitMQ 跑「處理即承諾」的任務隊列、Kafka 跑「寫入即承諾」的事件流。需要從任務流產生事件記錄時、用 Kafka Connect 的 RabbitMQ source connector 或自寫 bridge 把選定的訊息搬到 Kafka topic。

跟 outbox pattern 對位

從 RabbitMQ 遷往 Kafka 常伴隨 資料庫交易與事件發布一致性 的需求 —— 因為 event sourcing 場景要求事件不能丟。直接在交易中寫 Kafka 有雙寫一致性問題、應該走 3.3 outbox pattern：交易內只寫 outbox 表、再由 Debezium CDC 把 outbox 變更發到 Kafka topic。

跟其他 migration 結構的對照

兩篇都是 paradigm shift、都是 partial migration + 長期混合。差別在落差的方向：Kafka ↔ NATS 是 log vs subject messaging 的抽象層差異、RabbitMQ → Kafka 是 work queue vs event log 的責任模型差異 —— 後者的核心翻譯是「處理即承諾」如何重新表達成「寫入即承諾 + offset replay」。

相關連結

• Source / target vendor：RabbitMQ / Kafka
• 平行 vendor：NATS / Redis Streams
• 平行 migration playbook：Kafka ↔ NATS / Kafka → MSK
• 關鍵概念卡：Partition / Topic / Consumer group / Dead-letter queue / Ack/nack
• 下游能力：3.3 outbox pattern / 3.4 consumer 設計 / 6.12 idempotency / replay
• Methodology：Migration Playbook 寫作方法論

本文是跨 vendor migration playbook、cross-link 到 Redis Streams 跟 Kafka。對位 Kafka ↔ NATS 的 paradigm shift 模板 — 兩端不是同類產品的不同實作、是不同抽象層的系統：一個是 Redis 行程內的 append-only log data structure、一個是專用的 distributed event streaming platform。

Redis Streams 跟 Kafka 是不同抽象層的東西

Redis Streams 是 Redis 行程內的一個 data structure、Kafka 是一整套獨立的 distributed event streaming platform。這個區別決定整趟遷移的性質：要把 messaging 能力從「既有 Redis 行程的一塊記憶體」搬到「自成一格、要獨立運維的多節點叢集」，遠超過換個相容 broker 的工作量。

Redis Streams 的責任邊界是「在已經跑著的 Redis 裡多一個 append-only log」。它共用 Redis 的記憶體、持久化（AOF / RDB）、failover（Sentinel / Cluster）跟運維團隊。寫入用 XADD、消費用 XREADGROUP，consumer group 跟 pending entries list（PEL）都活在同一個 Redis 行程。它的設計取捨偏向「低延遲、低運維增量、跟 Redis 生命週期綁定」。

Kafka 的責任邊界是「成為跨系統的事件總線」。它把訊息寫成 partition 化的 log、落在獨立 broker 的磁碟、用 replication 保護、用 consumer group offset 追蹤各 consumer 進度，可長期保留並隨意 replay。它的設計取捨偏向「寫入即承諾、磁碟級長期保留、多 consumer 各自重播、水平擴展吞吐」。

關鍵在「拓樸單位」這列。Redis Streams 的一個 stream key 只能落在單一 shard、沒有 partition 概念，吞吐與資料量受單 shard 的記憶體與單執行緒處理能力封頂。Kafka 的 topic 天然切成多 partition、分散到多 broker，這是兩者在規模上的分水嶺，也是後面所有對位與故障演練的根。

先確認是不是真的該遷：多數中小規模不該遷

決定遷移前先做反向確認：在中小規模、且團隊已熟 Redis 的情境，Redis Streams 往往已經夠用，把它換成 Kafka 多半是引入運維負擔而非解決問題。遷移的正當理由來自規模或保留需求真的超出 Redis Streams 的能力邊界，而不是 Kafka 更主流。

Arcjet 的方向恰好相反、值得當反向參照。Arcjet 的 security / bot detection 平台需要低延遲請求處理，原本評估 Kafka，發現 managed Kafka 要六位數美元年費、自管運維難度也高；他們把既有的 Redis cache 層升級成 Streams，總成本掉到約一千美元年費。代價是 Redis Streams 沒有自動 retention，他們自寫一個 Janitor process，依約每分鐘一百則的實際處理速度監測 stream 長度跟 consumer group 狀態、selectively trim。

Arcjet 的判讀對遷移方向的啟示：當 workload 是低延遲、資料量留在記憶體可承受的範圍、團隊本來就在跑 Redis，Redis Streams 是務實且便宜的選擇；願意自寫 retention 工具就能補上它缺的治理能力。這條路成立時，遷去 Kafka 是用六位數年費跟一整套叢集運維，去換一個現有方案已能覆蓋的需求。

Bitso 是另一個 Redis Streams 站得住的高壓案例。Bitso 的撮合引擎微服務要扛每秒上千則訊息、亞毫秒延遲、撐住 BTC 價格暴動的尖峰；他們先後評估 Kafka（延遲不符）跟 SQS（vendor lock-in + 延遲）後選 Redis Streams，自建一層 Reliable Streams 抽象封裝 PEL + retry + DLQ，走 idempotent processing 接受重複勝過遺失。Bitso 揭露 Redis Streams 是「資料結構」而非「broker 系統」，可靠性責任在 application 層；但在亞毫秒延遲是硬指標的撮合場景，這個取捨反而讓 Redis Streams 勝過 Kafka。

兩個案例共同點：當延遲是硬指標、資料量在 RAM 可承受範圍、團隊能自建缺的治理層，Redis Streams 就站得住。遷去 Kafka 的決策該建立在這些前提不再成立之上，而不是建立在 Kafka 更有名之上。

真正該遷的訊號

決定遷移的依據是 Redis Streams 的三個能力邊界被實際 workload 突破：retention 需求超出 RAM 的成本曲線、需要長期 replay、consumer group 或 partition 規模超出單一 Redis 行程。三個訊號中任一個被觸發、且自建工具補不回來時，遷去 Kafka 才划算。

第一個訊號是 retention 超出 RAM 的成本翻轉。Redis Streams 的資料活在記憶體，保留越久、stream 越長、佔的 RAM 越多，而 RAM 是 Redis 叢集裡最貴的資源。當 retention 需求從「幾小時的緩衝」長到「數天到數週的事件保留」，把這些資料留在 RAM 的成本會快速超過 Kafka 把同樣資料留在 broker 磁碟（甚至 tiered storage 到 S3）的成本。Learning.com 退場案例就是這條線被突破的反例 — 把 Redis 當長期事件儲存（Stream 是其中一塊），事件量每週以 GB 成長、AOF fsync 與 EBS I/O 變成 latency 痛點，最終退回 PostgreSQL。成本曲線翻轉是最常見、也最該觸發遷移的訊號。

第二個訊號是需要長期 replay。事件溯源（event sourcing）或合規稽核場景，需要保留並重播數週、數月甚至數年的歷史事件。Redis Streams 的 replay 只能重讀 retention 內還在的資料，而 retention 受 RAM 限制無法拉得很長；Kafka 的磁碟保留加 tiered storage 讓長期 replay 變成 first-class 能力。當 replay 視窗的需求超出 RAM 能承受的 retention，這個訊號成立。

第三個訊號是 consumer group 或 partition 規模超出單一 Redis。Redis Streams 的單一 stream key 綁在單一 shard，吞吐受單 shard 封頂、沒有 partition 可以水平拆分並行度；要跨 shard 只能手動用 hash tag 切成多個獨立 stream，application 自己路由。當單一邏輯 stream 的吞吐需求、或 consumer 並行度需求超過單 shard 能給的，且手動切 stream 的複雜度已經失控，Kafka 的原生 partition 才值得換。

這三個訊號之外，還有一個放大條件：是否需要 Kafka 生態（Schema Registry、Connect / Debezium CDC、Streams 流處理）。如果遷移同時要接上 CDC pipeline 或 schema 強制治理，那 Kafka 帶來的不只是 retention 跟 partition、而是整套生態，這會讓遷移的價值天平更傾向 Kafka。但若只是想要更長 retention、生態用不到，先評估 Redis tiered 方案或自建 Janitor 是否更便宜。

概念對位：XADD/XREADGROUP/XACK/MAXLEN/XCLAIM

遷移的核心工作是把 Redis Streams 的五個核心操作對應到 Kafka 的等價概念、並理解每個對位背後語意的偏移，這比換 SDK 重得多。直接照字面搬會在 retention、消費進度、失敗接管三處踩雷，這三處正是後面故障演練的來源。

XADD 對 producer.send 的最大偏移是 partition key。Redis 的單一 stream key 沒有 partition，所有 entry 都在同一條序列上嚴格有序；Kafka 把訊息依 key 雜湊分到不同 partition，只有同一 partition 內保證有序。遷移時要決定哪個欄位當 partition key、這個決定同時決定了 ordering 的範圍跟 hot partition 的風險。

XREADGROUP 對 consumer group 的偏移在 rebalance。Redis consumer group 沒有自動 rebalance，consumer 掛掉後它名下未 ack 的訊息留在 PEL，要靠其他 consumer 主動 XCLAIM 接管；Kafka 的 consumer group 有 rebalance protocol，consumer 加入或離開時 broker 自動把 partition 重新分配。從手動接管搬到自動 rebalance，application 端負責接管的那段邏輯可以刪掉、但要改成理解 rebalance 行為。

XACK 對 offset commit 是最容易誤用的一處，獨立成下一節的故障演練。MAXLEN 對 retention policy 是成本模型翻轉的核心，也獨立成故障演練。

Production 故障演練

Case 1：Retention 模型從 RAM 限制翻成 log 成本，磁碟與成本失準

徵兆：團隊把 Redis Streams 的 MAXLEN 100000（保留最近十萬則、控制 RAM）習慣直接對映成 Kafka 的某個數字，結果 cutover 後不是 broker 磁碟暴漲超出預期、就是資料保留遠短於業務需要、replay 視窗對不上。

根因：Redis Streams 的 MAXLEN 是 application 在每次 XADD 主動修剪的「條數上限」，目的是壓住 RAM 佔用，是一個 count-based 的記憶體預算旋鈕。Kafka 的 retention 是 broker 端被動執行的 policy、預設是 time-based（retention.ms）或 size-based（retention.bytes），目的是控制磁碟保留窗，而磁碟比 RAM 便宜一到兩個數量級。兩者的單位、執行主體、成本曲線都不同 — 把「保留十萬則以省 RAM」直接搬成 Kafka 設定，會錯估磁碟用量，也會把 Redis 時代「為了省 RAM 而被迫短保留」的限制錯誤地帶進一個本來就能長保留的系統。

修法：

1. 從業務需求重算 retention、不沿用 Redis 的 RAM 預算：Redis 的 MAXLEN 數字是 RAM 成本的妥協、不是業務的真實保留需求；遷移時回到「業務需要 replay 多久」重新算 retention.ms，這正是遷移要解鎖的能力。
2. 改用 time-based 為主、size-based 當保險絲：Kafka 設 retention.ms 對齊業務 replay 窗、再設 retention.bytes 防單 partition 磁碟失控。
3. 長保留接 tiered storage：retention 需求拉到數週數月時，把冷資料分層到 S3、熱資料留本地磁碟，成本曲線進一步壓平，而這在 Redis 的 RAM 模型下做不到。

Case 2：PEL 觀念被帶進 offset，造成重複或漏消費

徵兆：遷移後 consumer 出現「明明處理過的訊息又被重新消費」或「某些訊息整批沒被處理」；團隊照 Redis 時代「逐則 XACK」的心智模型管理 Kafka offset commit，結果對不上。

根因：PEL 跟 offset 是兩個不同的進度模型。Redis Streams 的 PEL 是 broker 維護的「逐則待 ack 集合」，每則訊息獨立追蹤是否已 ack，consumer 可以亂序 ack 某幾則、其他留在 PEL；XACK 是針對特定 entry ID 的點狀確認。Kafka 的 offset 是 per partition 的單調位移、代表「這個位置之前都算消費完」，commit offset N 意味著 0 到 N-1 全部視為已處理。把 PEL 的逐則語意套到 offset 上會出兩種錯：一是處理完亂序的訊息後 commit 了較大的 offset，中間沒處理完的訊息被當成已消費而漏掉；二是 commit 時機錯置（auto-commit 在處理前就 commit），crash 後從錯誤位置重讀造成重複。

修法：

1. 理解 offset 是區間承諾、不是逐則確認：commit offset 前確保該 offset 之前的訊息都已處理完、不要對亂序處理的批次 commit 最大 offset。
2. 關 auto-commit、改 manual commit 在處理之後：enable.auto.commit=false，處理完一批再 commit，對齊 at-least-once。
3. 保留 application 端 idempotency：這點從 Redis 時代就該有、遷到 Kafka 仍成立 — at-least-once 下重複難免，用 message ID + dedup store 顯式去重，對位 idempotency 卡跟 Bitso 的 idempotent processing。

Case 3：單 stream key 換成多 partition，ordering 假設破裂

徵兆：遷移前所有事件在單一 Redis stream 上嚴格有序、downstream 依賴這個順序（例如同一筆訂單的 created → paid → shipped）；切到 Kafka 多 partition 後，同一筆訂單的事件被分到不同 partition、處理順序錯亂。

根因：Redis Streams 的單一 stream key 綁單一 shard、所有 entry 在一條序列上全域有序，application 不需要思考 ordering 範圍就免費得到全序。Kafka 把 topic 切成多 partition 來換取水平吞吐，代價是只保證 同一 partition 內 有序、partition 之間無序。遷移時若沒指定 partition key、訊息會被 round-robin 或依預設雜湊散開，同一個業務實體（訂單、帳戶、裝置）的事件落到不同 partition，全序假設就破了。

修法：

1. 用業務實體當 partition key：把需要保序的實體 ID（訂單 ID、帳戶 ID）當 Kafka message key，同 key 雜湊到同 partition、partition 內保序，把「全域有序」收斂成「per-entity 有序」這個多數業務真正需要的粒度。
2. 辨識哪些流真的需要全序：若某條流真的需要全域嚴格有序且無法拆成 per-entity，設單 partition topic（犧牲該 topic 的水平吞吐）；這也是個訊號 — 若大量流都需要全序，遷 Kafka 的吞吐優勢用不上、該重新評估遷移。
3. 規劃 partition 數對齊並行度跟 hot key：partition 數決定 consumer 並行上限，同時注意熱門 key 造成的 hot partition，對位 Kafka topic 設計的 key 策略段。

Case 4：Redis 既有低延遲被 Kafka 吞吐換掉，延遲敏感路徑受傷

徵兆：遷移後某些原本靠 Redis Streams 亞毫秒延遲的路徑（即時風控判斷、撮合前置）延遲跳到數十毫秒，下游 SLA 破線。

根因：Redis Streams 的亞毫秒延遲來自記憶體操作 + 行程內 data structure；Kafka 為了長期保留跟高吞吐，訊息要落磁碟、過 replication、走網路到獨立 broker，單則訊息延遲落在 5-50ms 區間，這是它換吞吐跟持久性付出的代價。把延遲敏感路徑無差別搬上 Kafka，等於用一個為吞吐優化的系統去服務一個為延遲優化的需求。

修法：

1. 按延遲需求分流、不要全遷：把延遲敏感的即時路徑留在 Redis Streams（或 Redis 其他結構）、把需要長保留 / 高吞吐 / replay 的事件流遷到 Kafka，這正是 Bitso 在撮合場景堅持 Redis Streams 的理由。
2. 接受混合架構是常態：Redis Streams 跟 Kafka 共存、各自服務適配的 workload，不追求「全部統一到 Kafka」；對位 Kafka ↔ NATS 的混合架構是 long-term default 思路。
3. 若 Kafka 延遲必須壓低：調 producer linger.ms=0 + acks=1、consumer fetch.min.bytes=1 換取較低延遲，但這會犧牲吞吐與部分可靠性、是 trade-off 不是免費午餐。

Migration 結構：漸進 cutover + 長期混合

這趟遷移的結構是漸進拆分而非一次性切換：先按 workload 性質分流、再對需要遷的事件流做 dual-write 並行、逐流 cutover、最終留下 Redis Streams 跟 Kafka 共存的混合架構。一次性把所有 stream 搬上 Kafka 既無必要、也會把延遲敏感路徑拖下水。

1. Phase 0：scope 分流 — 對每條 stream 跑前面三個訊號的判讀，分成「該遷 Kafka」（retention / replay / 規模超界）跟「留 Redis Streams」（延遲敏感 / 規模在範圍內）兩類。這一步直接決定後續工作量、也避免無差別遷移。
2. Phase 1：Kafka 叢集與 topic 設計 — 建 broker 叢集、依 Case 3 的 partition key 設計建 topic、依 Case 1 的業務需求設 retention，這時做的是基礎設施準備、還沒碰流量。
3. Phase 2：dual-write 並行 — producer 同時寫 Redis Streams 跟 Kafka、新 consumer 接 Kafka 驗證正確性、舊 consumer 持續吃 Redis Streams，這是可逆階段、出問題退回只讀 Redis 即可。
4. Phase 3：逐流 cutover — 逐條 stream 把流量切到 Kafka、確認 consumer 進度（offset）跟 idempotency 都對、再停掉該 stream 的 Redis 端寫入；cutover 以 stream 為單位、不是整批。
5. Phase 4：長期混合 — 留在 Redis Streams 的延遲敏感流跟遷到 Kafka 的事件流共存、各自運維；需要時用 bridge（消費 Redis Streams 寫入 Kafka、或反向）同步必要資料。

dual-write 階段的可逆性是這個結構的安全邊界：在 Phase 2 之前一切可退回純 Redis、Phase 3 逐流 cutover 把不可逆動作（停 Redis 寫入）切到最小粒度，單條 stream 出問題不影響其他流。

Capacity / cost 對照

判讀：成本的核心翻轉在「儲存成本曲線」這列。Redis Streams 把資料壓在最貴的 RAM、retention 越長越貴，所以實務上被迫短保留；Kafka 把資料攤到便宜的磁碟、再分層到 S3，讓長保留變得可負擔。但這個翻轉只在「retention 需求真的長」時成立 — 若 retention 只需數小時、資料量小，Redis Streams 沒有獨立叢集跟 0.5-2 FTE 的運維增量，總成本反而低，這正是 Arcjet 的處境。遷移划不划算取決於 retention 跟規模需求落在這條曲線的哪一段。

整合 / 下一步

混合架構是常見終態

多數從 Redis Streams 起步、因規模長出 Kafka 需求的系統，終態是兩者共存而非取代：

1[延遲敏感即時路徑]                    [長保留 / replay / 高吞吐事件流]
2   Redis Streams                              Kafka
3        │                                       │
4        └──────────── Bridge（雙向同步）────────┘

Redis Streams 服務亞毫秒延遲的即時路徑（風控、撮合前置）、Kafka 服務需要長保留與 replay 的事件流；需要打通時寫一段 bridge 同步必要 stream。這跟 Kafka ↔ NATS 的混合架構是 long-term default 是同一個 paradigm shift 結論的兩個實例。

接上 Kafka 生態

遷到 Kafka 後可解鎖 Redis Streams 沒有的生態能力：

• Schema 治理：用 Schema Registry 強制 producer / consumer 契約，補上 Redis Streams 缺的 schema enforcement（對位 Bitso 自建抽象層的紀律性責任）。
• CDC pipeline：接 Debezium 把資料庫變更流進 Kafka topic，做事件溯源主軸。
• 長期 replay：tiered storage 把冷事件分層到 S3、支援數年 replay。

反向確認的 tripwire

遷移後若觀察到：延遲敏感路徑 SLA 破線、Kafka 叢集運維成本超出省下的 RAM 成本、實際 retention 需求遠短於規劃 — 這些是「該遷的訊號其實不成立」的回溯訊號，應重新評估該 stream 是否該退回 Redis Streams，對位 Arcjet 的成本判讀。

相關連結

• Source / target vendor：Redis Streams / Kafka
• 反向案例：Arcjet Redis Streams 取代 Kafka / Bitso Reliable Streams / Learning.com 退場
• 平行 migration playbook（同 paradigm shift）：Kafka ↔ NATS
• 平行 vendor：RabbitMQ / NATS
• Methodology：Migration Playbook 寫作方法論（Type E paradigm shift）

本文是跨 vendor migration playbook、cross-link 到 Kafka 跟 NATS。跟前四篇 migration（schema 差 / drop-in / operational redesign / multi-tool 拆分）對照、本篇是 paradigm shift — 兩端不是「同類產品的不同實作」、是 不同抽象層的 messaging system。

「Kafka → NATS migration」字面上不成立

前面四篇 migration 都隱含一個前提：source 跟 target 是 同類產品、只是不同實作或 deployment 模型。「Kafka → NATS」字面上看起來也是 messaging migration、但實際上：

Kafka 跟 NATS Core 是 不同類產品 — 一個是 durable event log、一個是 transient pub/sub。「migration」需要先決定 target 是 NATS Core 還是 JetStream、然後判斷 application 模式能否重設計 對應。

什麼情境真的能換、什麼不能

判讀：

• Microservice async messaging + 低延遲需求 → NATS Core 更合適、是 真正的 migration
• Event sourcing + replay → JetStream 部分對等、但 partition / offset 觀念變了
• Log collection / event streaming → 不該遷、保留 Kafka

為什麼會考慮這個 paradigm shift

實務上觸發評估 NATS 通常三條 driver：

1. Cost + operational complexity：Kafka cluster + ZooKeeper（或 KRaft）+ Schema Registry + Connect 是重資產、3-5 broker + ops 1+ FTE；NATS 單 binary、無依賴、輕量
2. Latency 要求 < 1ms：Kafka 對單 message latency 不是 SLA、NATS Core 是
3. Multi-tenant / multi-region 簡化：NATS 內建 account + leaf node 拓樸、跨 region 是 first-class

但這三條 driver 都 只在特定 application 模式有效。不是普世 better、是 某類 workload 適合。

Migration 結構：application 重設計 + 部分 stream cutover

跟前面四篇 migration 結構都不同、Kafka ↔ NATS 是 混合：

1. Phase 0：scope 判讀 — 列 application、區分「適合 NATS」vs「保留 Kafka」
2. Phase 1：application code 重設計 — 不是 SDK 換、是 messaging pattern 改（event sourcing → message bus / consumer group → durable consumer）
3. Phase 2：部分 stream parallel run — 新 application 走 NATS、舊 application 持續 Kafka
4. Phase 3：cutover 適合的 stream
5. Phase 4：長期混合架構 — Kafka 跟 NATS 共存、不消滅一邊

整體不是 一次 migration、是 漸進拆分。多數 production 環境 永遠 是混合架構。

Application 重設計範例：consumer group → durable consumer

 1// Kafka 端 consumer group pattern
 2consumer := kafka.NewConsumer(&kafka.ConfigMap{
 3    "bootstrap.servers": "kafka:9092",
 4    "group.id":          "myapp-orders",
 5    "auto.offset.reset": "earliest",
 6})
 7consumer.SubscribeTopics([]string{"orders"}, nil)
 8
 9for {
10    msg, err := consumer.ReadMessage(-1)
11    // process msg.Value
12    consumer.CommitMessage(msg)
13}

 1// NATS JetStream durable consumer
 2js, _ := nc.JetStream()
 3sub, _ := js.PullSubscribe("orders.>", "myapp-orders",
 4    nats.AckExplicit(),
 5    nats.MaxAckPending(100),
 6)
 7
 8for {
 9    msgs, _ := sub.Fetch(10, nats.MaxWait(5*time.Second))
10    for _, msg := range msgs {
11        // process msg.Data
12        msg.Ack()
13    }
14}

差異：

• Kafka auto.offset.reset → NATS DeliverPolicy（多種選項）
• Kafka commit message → NATS explicit Ack（per message）
• Kafka partition → NATS subject hierarchy（orders.> 通配）
• Kafka rebalance → NATS 不需要、durable consumer 跨 instance 共享

Application 邏輯改動 30-60%、不是 SDK 換。

Production 故障演練

Case 1：Consumer offset 觀念差，replay 不對等

徵兆：application 設計「跑歷史 7 天事件 catch-up」、Kafka 設 auto.offset.reset=earliest + seek_to(timestamp) 跑；換 NATS JetStream 後找不到 seek_to 等價 API、catch-up 失敗。

根因：Kafka offset 是 broker-side 維護 + consumer-side commit；NATS JetStream 用 sequence number + DeliverPolicy.ByStartTime、但 time-based seek 精度低、且 application code 必須改。

修法：

1. 預先設計：NATS JetStream 用 DeliverPolicy.ByStartSequence + 自管 sequence-time mapping
2. 保留 Kafka 給 replay-heavy use case：不是所有 application 都遷
3. 混合架構：歷史 replay 走 Kafka、新事件流走 NATS、application 處理雙來源

Case 2：Retention model 差異、磁碟使用炸

徵兆：NATS JetStream stream 設 retention=interest（subscriber 收到就刪）、cutover 後 disk 持續長大；預期跟 Kafka log retention 7 天類似、實際資料留 30+ 天沒清。

根因：NATS JetStream retention 有 3 種：limits / interest / workqueue。interest 是 至少一個 subscriber 還沒 ack 就保留；application 端 silent consumer（已下線但沒 unsubscribe）讓 message 永留。

修法：

1. 預設 retention=limits：用 MaxAge / MaxBytes 跟 Kafka log retention 對應、明確控制
2. interest retention 慎用：只在 確認所有 subscriber lifecycle 受控 場景
3. Subscriber cleanup：application graceful shutdown 必須主動 unsubscribe、不留 zombie consumer

Case 3：Exactly-once 假設不對等

徵兆：cutover 後發現某 application（payment processor）開始出現 duplicate transaction；Kafka 端用 transactional producer + idempotent consumer 跑了 2 年沒問題。

根因：Kafka exactly-once 是 producer transaction + consumer offset commit atomic；NATS JetStream exactly-once 概念不一樣 — 是 publish ack + consumer ack 跨層 atomic、application 端要主動處理 idempotency。

修法：

1. 重新審視 application 端 idempotency：用 message ID + dedup store（Redis SETEX）顯式 dedup
2. NATS JetStream 對 exactly-once 不該假設「自動」：application 端責任、不是 broker 端
3. Payment / financial 場景慎遷：保留 Kafka transactional pattern 較穩

Case 4：Schema registry 缺位、ad-hoc schema 漂移

徵兆：NATS 部署 3 個月後、producer / consumer 間 schema 對不上、application bug；Kafka 端有 Confluent Schema Registry 強 enforce、NATS 沒對等服務。

根因：NATS 哲學是 minimalist、不內建 schema registry；application 自己決定 payload format。Kafka 生態的 Avro / Protobuf + Registry 模式不直接搬。

修法：

1. 外部 schema management：用 BSR（Buf Schema Registry）或自家 Git-based registry、producer / consumer build-time 驗證
2. NATS Object Store：JetStream 提供 K/V + Object Store、可存 schema 文件
3. 接受紀律性 trade-off：NATS 簡潔代價是 application 端紀律、不能靠 broker 強 enforce

Case 5：Fan-out 模式跟 Kafka 不一致

徵兆：同一 event 要送 5 個 downstream service、Kafka 端用 consumer group + 5 個 group 跑；NATS 端設計 5 個 durable consumer、結果某些 message 漏 fan-out。

根因：Kafka consumer group 對 同 group 內 partition 分配、不同 group 各自完整消費；NATS JetStream Durable consumer 預設行為跟 group 不同 — 單 durable consumer 是 shared subscription、要 fan-out 需多個獨立 durable。

修法：

1. 明確設計 fan-out：N 個 downstream 對應 N 個 獨立 durable consumer、不共用
2. 用 AckPolicy.None + push subscriber：不需要 ack 的 fan-out 場景、用 ephemeral push subscriber
3. 檢查 application stream config：fan-out 失敗多半是 consumer config 錯、不是 NATS bug

Capacity / cost 對照

判讀：簡單 messaging workload NATS 顯著便宜；complex event streaming（Schema Registry / Streams / Connect 重度用）Kafka 不替代。

整合 / 下一步

混合架構是 long-term default

多數 production 環境最終是 Kafka + NATS 共存：

1[event sourcing / log collection]        [microservice async messaging]
2         Kafka                                       NATS
3         │                                            │
4         └──────── Bridge (Connect / Custom) ────────┘

NATS 跑微服務間 messaging、Kafka 跑 event log / analytics pipeline；中間用 Kafka Connect NATS connector 或自寫 bridge 同步必要 stream。

跟 Logical Replication + Debezium 對位

CDC pipeline 設計：

• DB → Debezium → Kafka topic（event sourcing 主軸）
• Kafka → NATS bridge → microservice fan-out
• 不直接 DB → Debezium → NATS（Debezium 不原生支援 NATS sink）

跟前 4 篇 migration 的結構對照

結論：migration 結構由 最大差異維度 決定、不是 universal phased playbook。

相關連結

• Source / target vendor：Kafka / NATS
• 平行 vendor：RabbitMQ / Redis Streams
• 平行 migration playbook：Splunk → Elastic Security / Redis → DragonflyDB / PostgreSQL → Aurora / Datadog → Grafana Stack
• Methodology：Vendor 深度技術文章的寫作方法論

觀察

Pinterest 從 Kafka broker 卸 ~200 TB/day 熱資料到 S3、2024 年 5 月起 20+ production topic 上線、跟 KIP-405 native tiered storage 不同、採 broker-decoupled 設計。

判讀

Broker-decoupled 設計讓 consumer 直接從 S3 拉、broker 不再是熱路徑。揭露「broker resource 跟 cross-AZ network cost」其實該分離治理、而非綁在 broker 容量擴張上。

對應大綱

Kafka 進階主題：tiered storage / 跨層儲存成本。

下一步路由

回 Kafka vendor 頁 與 3.1 broker basics。

引用源

• Pinterest Tiered Storage for Apache Kafka — a Broker-Decoupled Approach

本文是跨 vendor migration playbook、cross-link 到 Apache Kafka（source）跟 Google Cloud Pub/Sub（target）。跑 6 維 diff dimension audit 後判定為 Type E paradigm shift：兩者投遞模型本質不同（partition-based log vs topic-subscription pub/sub）。

為什麼從 Kafka 遷到 Pub/Sub

這個遷移的 driver 通常是平台策略：

• All-in GCP：組織決定收斂到 GCP 生態，Kafka 是唯一非 GCP 的 stateful 服務，維運孤島成本高
• 運維簡化：自管 Kafka cluster 的 broker、ZooKeeper/KRaft、partition rebalance、retention 管理需要專職團隊；Pub/Sub 是全託管
• GCP 整合：下游是 BigQuery、Dataflow、Cloud Run — Pub/Sub 原生串接，Kafka 要加 connector 層
• 全球路由：Pub/Sub topic 是 global（不綁 region），Kafka 需要 MirrorMaker 做跨 region 同步

遷移的工作量不在資料搬遷（message queue 通常不搬歷史資料），在 模型轉換 — Kafka 的 partition ordering、consumer group、offset commit 跟 Pub/Sub 的 topic-subscription、ack deadline、ordering key 是不同抽象。

6 維 diff dimension audit

五維 High — Type E paradigm shift，是兩套模型的橋接，工程量遠超 drop-in 或翻譯。

模型差異對照

遷移前必須理解兩套模型的對應關係。對應不是一對一 — 有些概念在對方沒有直接等價物。

Ordering 語意是最大差異

Kafka 的 ordering 保證是 partition 內全域有序。同一個 partition 的訊息按寫入順序消費，consumer group 內每個 partition 只有一個 consumer。

Pub/Sub 預設不保證 ordering。要 ordering 需開啟 ordering key — 同一 ordering key 的訊息有序，但不同 ordering key 之間無序。ordering key 的並行度由 key 的 cardinality 決定（類似 Kafka 的 partition key）。

遷移時的判斷：

• 若 Kafka 的 ordering 只依賴 partition key（常見），ordering key 直接對應
• 若依賴 partition 內的全域順序（少見但存在），需要重新設計 — Pub/Sub 沒有 partition 全域順序的概念
• 若完全不需要 ordering（fan-out 場景），Pub/Sub 預設行為更簡單

Component 數量轉換

Kafka 生態的 Schema Registry 在 Pub/Sub 由原生 Schema 功能替代（topic-level schema validation）；Kafka Connect 的 sink connector 由 BigQuery subscription 或 Dataflow job 替代。Dataflow 不是必要 — 簡單的 push/pull consumer 不需要 Dataflow，只有 stream processing（windowed aggregation、join）才需要。

階段一：Producer 遷移（雙寫）

雙寫策略是 paradigm shift 遷移的標準起手。Application 同時把訊息寫入 Kafka 和 Pub/Sub，consumer 仍從 Kafka 消費。

Producer 改造

 1# 示意：雙寫 wrapper（實際生產用各自語言的 client library）
 2def publish_order_event(event):
 3    # 原有 Kafka producer
 4    kafka_producer.send("order-events", key=event.order_id, value=event.to_bytes())
 5
 6    # 新增 Pub/Sub producer
 7    pubsub_publisher.publish(
 8        "projects/my-project/topics/order-events",
 9        data=event.to_bytes(),
10        ordering_key=event.order_id  # 對應 Kafka partition key
11    )

雙寫驗證

雙寫的失敗隔離要嚴格設計。Pub/Sub publish 失敗時，application 應該 log + metric 但不 block request。Kafka 是已驗證的正式路徑，Pub/Sub 在這個階段是 shadow。

階段二：Consumer 遷移（逐 subscription 切換）

Producer 雙寫穩定後，逐一把 consumer 從 Kafka 切到 Pub/Sub subscription。

Consumer 改造重點

Ack 模型差異：Kafka consumer 是 poll + commit offset；Pub/Sub 是 pull（或 push）+ per-message ack。

 1# Kafka consumer pattern
 2for msg in kafka_consumer:
 3    process(msg)
 4    kafka_consumer.commit()
 5
 6# Pub/Sub pull subscriber pattern
 7def callback(message):
 8    try:
 9        process(message.data)
10        message.ack()
11    except Exception:
12        message.nack()  # 會被重新投遞
13
14subscriber.subscribe("projects/my-project/subscriptions/order-processor", callback=callback)

Idempotency 更重要：Pub/Sub 的 at-least-once delivery 加上 ack deadline 機制，redelivery 比 Kafka 更容易觸發（ack deadline 內沒 ack 就重投）。Consumer 的 idempotency 設計要比 Kafka 時更嚴格。

Flow control：Pub/Sub client library 支援 max_outstanding_messages 和 max_outstanding_bytes 做 backpressure 控制，對應 Kafka 的 max.poll.records。

切換順序

依 consumer 的重要度和複雜度排序：

1. 先切 stateless consumer（log pipeline、metrics aggregation）— 低風險
2. 再切有 side effect 但 idempotent 的 consumer（search index sync、notification）
3. 最後切核心 consumer（payment processing、inventory update）— 需要完整 idempotency 驗證

每切一組 consumer：

1. 建立對應的 Pub/Sub subscription
2. 部署新 consumer（讀 Pub/Sub）
3. 驗證處理正確性（比對 Kafka consumer 和 Pub/Sub consumer 的輸出）
4. 停止舊 Kafka consumer
5. 觀察 7 天無異常

階段三：停止雙寫

所有 consumer 切完後：

1. 停止 Kafka producer（移除雙寫邏輯）
2. 觀察 Kafka topic 不再有新訊息
3. 等 Kafka retention 過期
4. 下線 Kafka cluster

Kafka cluster 不要在 consumer 切完後立即下線。保留 retention period + 7 天作為回退保險。

回退路徑

Type E 遷移的回退要在每個階段都設計：

• 階段一回退：移除 Pub/Sub publish 邏輯，Kafka 路徑不受影響
• 階段二回退：重啟 Kafka consumer、停止 Pub/Sub subscriber。Kafka 的 offset 要確認是否仍在 retention 內
• 階段三回退：如果 Kafka 已下線，需要重新建 cluster 並從 Pub/Sub 反向雙寫回 Kafka — 成本高，所以階段三前要確認穩定

回退的關鍵指標：consumer lag（Pub/Sub 的 oldest_unacked_message_age）持續上升、error rate 上升、或 redelivery rate 異常。

遷移後的監控對照

不適合遷移的場景

以下場景 Kafka → Pub/Sub 的 ROI 不成立：

• 需要 exactly-once semantics：Kafka 的 transactional producer + idempotent producer 提供 exactly-once；Pub/Sub 是 at-least-once，application 層做 dedup
• 需要長期 replay：Kafka retention 可設數月甚至永久（tiered storage）；Pub/Sub message retention 最長 31 天（若需超過 31 天的 replay，可用 BigQuery subscription 做長期歸檔，但查詢模式不同於 Kafka 的 offset-based replay）
• 大量 ordering 依賴：如果 Kafka topology 重度依賴 partition ordering 且 key cardinality 低，Pub/Sub ordering key 的並行度會比 Kafka 差
• 使用 Kafka Streams / ksqlDB 做 stateful processing：stream processing 邏輯跟 Kafka 綁定（state store backed by changelog topic），遷到 Pub/Sub 要同時遷移 processing 框架（→ Dataflow / Beam），工程量額外翻倍且 API 完全不同
• 多雲 / 非 GCP 環境：Pub/Sub 是 GCP-only，跨雲場景反而讓 Kafka 更合理

交接路由

• Source vendor overview：Apache Kafka
• Target vendor overview：Google Cloud Pub/Sub
• Pub/Sub 操作細節：Push / Pull / Ack Flow Control、Ordering / DLT / Schema
• Consumer idempotency：3.4 Consumer Design、3.6 Processing Recovery Semantics
• 反向路徑（SQS → Pub/Sub）：AWS SQS → Google Pub/Sub

本文是 Kafka overview「Replication 與 exactly-once 升級」段的 implementation-layer deep article。Overview 已給出 partition / replication 的選型定位、本文展開 寫入承諾 跟 處理語義 兩條獨立軸線怎麼設、邊界在哪、成本是什麼。對應反例 3.C9 Queue 語義誤配。

寫入承諾與處理語義是兩條獨立軸線

Kafka 的可靠性拆成兩個彼此正交的問題、混在一起談是多數誤配的起點。第一條軸線是 寫入承諾：一筆訊息寫進 broker 後、在多少 replica 落地才算「成功」、broker 掛掉時這筆訊息會不會消失。這條軸線由 replication factor、ISR、acks 與 min.insync.replicas 共同決定、屬於 broker 端的耐久性保證。第二條軸線是 處理語義：同一筆訊息在 producer 重送、consumer 重啟、partition rebalance 等情境下、會不會被寫進去兩次或被處理兩次。這條軸線由 producer idempotence、transaction 與 consumer 端的 commit 設計決定、屬於端到端的正確性保證。

兩條軸線可以獨立調整：可以有「寫入承諾很強但處理語義是 at-least-once」的配置（acks=all + 非冪等 consumer）、也可以有「寫入承諾較弱但已開冪等」的配置。把 exactly-once 當成單一開關去找、是因為沒看出這兩條軸線存在。本文先講第一條（replication / ISR / acks）、再講第二條（idempotence / transaction）、最後談兩者疊起來能達成什麼、達不成什麼。

這個拆分對映 delivery semantics 與 idempotency 兩張知識卡：前者描述 broker 承諾的送達次數、後者描述處理端怎麼讓「送達多次」不等於「生效多次」。

ISR：誰算「跟得上」的副本

ISR（in-sync replica、同步副本集）是一個 partition 當前「跟得上 leader」的 replica 集合、是 Kafka 把 replication factor 這個 靜態配置 轉成 動態保證 的關鍵概念。Replication factor = 3 只說明這個 partition 有 3 份 replica；但任一時刻真正跟得上 leader 的可能只有 2 份或 1 份。ISR 就是這個「當前實際同步」的集合、寫入承諾的判斷都基於 ISR、不是基於 replication factor。

一個 follower 留在 ISR 內的條件是：它在 replica.lag.time.max.ms（預設 30 秒）內持續向 leader 拉取資料、且追上 leader 的 log end offset。當 follower 因為 broker 慢、網路抖動、GC 停頓或 disk 壓力而落後超過這個時間窗、leader 會把它移出 ISR — 這就是 ISR shrink（收縮）。當它恢復、重新追上、再被加回 ISR — 這是 ISR expand（擴張）。

ISR 收縮本身不是故障、是 Kafka 對「這個 follower 暫時不可信」的誠實表態。真正的風險在於：ISR 收縮到某個程度後、acks=all 的寫入承諾會無法滿足 min.insync.replicas 而開始拒絕寫入。下一段的 acks 取捨直接建立在 ISR 這個概念上。

實機看 ISR 的方式是 kafka-topics.sh --describe、Isr 欄位列出當前同步的 broker id：

1# RF=3、min.insync.replicas=2 的 topic、三 broker 都同步時
2kafka-topics.sh --describe --topic repl-demo --bootstrap-server kafka1:9092
3# Topic: repl-demo  PartitionCount: 1  ReplicationFactor: 3  Configs: min.insync.replicas=2
4#   Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 2,3,1

Replicas 欄位是 配置上 的 3 份副本、Isr 欄位是 當前實際同步 的集合。兩者一致代表健康；Isr 比 Replicas 短代表有副本落後。日常巡檢用 kafka-topics.sh --describe --under-replicated-partitions 直接列出 Isr 短於 Replicas 的 partition。

acks 與 min.insync.replicas：寫入承諾的兩個旋鈕

寫入承諾由 producer 端的 acks 跟 broker / topic 端的 min.insync.replicas 共同決定、兩者必須一起設才有意義。acks 決定 producer 在收到「成功」回應前、要等多少 replica 確認；min.insync.replicas 決定 broker 在 ISR 不足時是否拒絕寫入。前者是 producer 的等待策略、後者是 broker 的拒絕底線。

acks 三個值對應遞增的耐久性與遞增的延遲成本：

acks=0 適用「丟一兩筆無所謂」的場景、例如高頻 metric 上報、log shipping 的非關鍵層。它把網路往返成本壓到最低、代價是 producer 完全不知道 broker 有沒有收到。任何牽涉金流、訂單、狀態變更的訊息都不該用 acks=0。

acks=1 是一個容易被誤以為安全的中間值。它只等 leader 寫入本地、不等 follower 同步。多數時候運作正常、但存在一個明確的資料遺失窗口：leader 回了成功、follower 還沒拉到這筆訊息、此時 leader 所在 broker 崩潰、新 leader 從 follower 中選出 — 那筆「已回成功」的訊息在新 leader 上不存在、producer 卻以為寫成功了。這個窗口在正常運行時很窄、但在 broker 滾動重啟、硬體故障、AZ 中斷時會被放大。

acks=all 是耐久性配置的正解、但只有搭配 min.insync.replicas ≥ 2 才完整。單獨設 acks=all、若 min.insync.replicas=1、那麼當 ISR 收縮到只剩 leader 一份時、acks=all 等同 acks=1 — 「所有 ISR 確認」這個條件在 ISR 只剩 1 份時形同虛設。min.insync.replicas=2 補上這個漏洞：它要求 ISR 至少有 2 份才接受 acks=all 寫入、否則直接拒絕、把「靜默遺失」轉成「明確拒絕」。

min.insync.replicas 是 topic-level 可動態調整的配置、不需重啟 broker：

1# 動態調整單一 topic 的 min.insync.replicas
2kafka-configs.sh --alter --topic repl-demo \
3  --add-config min.insync.replicas=2 \
4  --bootstrap-server kafka1:9092
5
6# 查當前值、synonyms 會顯示 topic override 蓋過 broker default
7kafka-configs.sh --describe --topic repl-demo --bootstrap-server kafka1:9092
8# min.insync.replicas=2 synonyms={DYNAMIC_TOPIC_CONFIG:min.insync.replicas=2,
9#   DYNAMIC_DEFAULT_BROKER_CONFIG:min.insync.replicas=1, DEFAULT_CONFIG:min.insync.replicas=1}

RF=3 + acks=all + min.insync.replicas=2 是業界對「不能丟資料」topic 的標準三件組：3 份副本提供冗餘、acks=all 要求同步確認、min.insync=2 在容忍一台 broker 掛掉的同時仍保證每筆寫入落在至少兩份 replica。容忍度的算術是 RF - min.insync.replicas：3 - 2 = 1、代表可以掉一台 broker 仍正常寫入、掉兩台則寫入被拒（但已寫入的資料不丟）。

Producer idempotence：去掉重送造成的重複

Producer idempotence（冪等生產者、enable.idempotence=true）解決的是 producer 重送 造成的 broker 端重複。它讓「producer 因為沒收到 ack 而重送同一筆訊息」這件事、在 broker 端被去重、不會寫進兩筆。這是處理語義軸線的第一塊、獨立於前面的寫入承諾。

問題的根源是：producer 送出訊息後、若因網路超時沒收到 broker 的 ack、它無法分辨是「訊息沒送到」還是「訊息送到了但 ack 在回程丟了」。預設行為是重送。在沒有冪等保護時、若實際是後者、broker 就收到兩筆相同訊息、partition 裡出現重複。

冪等機制的做法是給每個 producer 分配一個 producer ID（PID）、並為每個 partition 維護一個遞增的 sequence number。Broker 記住每個 (PID, partition) 已接受的最大 sequence；重送的訊息帶相同 sequence、broker 認出是重複、直接丟棄並回成功。這個保證的範圍是 單一 producer session 內、單一 partition 的精確一次寫入。

開啟方式是 producer 端設 enable.idempotence=true。在較新版 Kafka 這已是預設值、且它會隱含要求 acks=all、retries > 0、max.in.flight.requests.per.connection ≤ 5 — 因為冪等去重依賴這些前提。冪等的成本極低（broker 多維護 PID/sequence 的少量 metadata）、幾乎沒有理由關閉。

需要明確的邊界是：冪等只覆蓋 同一個 producer session。Producer 重啟後拿到新的 PID、broker 無法把新舊 session 的訊息關聯起來。跨 session 的去重、以及「寫多個 partition 要嘛全成功要嘛全失敗」的需求、要靠下一段的 transaction。

Kafka transaction 與 read_committed：跨 partition 的原子寫入

Kafka transaction（交易）解決的是 跨多個 partition 的原子寫入 與 consume-process-produce 的原子提交。它讓一組寫入（可能跨多個 topic / partition）以及對應的 consumer offset commit、要嘛全部對下游可見、要嘛全部不可見。這是處理語義軸線的第二塊、建立在冪等之上。

典型場景是 stream processing 的 consume-process-produce 迴圈：consumer 讀入一批訊息、處理後產出結果寫到另一個 topic、然後 commit 讀取進度。若這三步不是原子的、崩潰時可能出現「結果已產出但 offset 沒 commit」（重啟後重複處理、重複產出）或「offset 已 commit 但結果沒寫成功」（訊息遺失）。Transaction 把「產出結果」跟「commit offset」綁成一個原子操作、消除這個窗口。

啟用 transaction 需要 producer 設一個穩定的 transactional.id、並在程式碼中走完整的 transaction 生命週期：

1producer.initTransactions()      // 向 transaction coordinator 註冊、fence 掉舊 session
2producer.beginTransaction()
3  producer.send(record1)          // 跨多個 topic/partition 的寫入
4  producer.send(record2)
5  producer.sendOffsetsToTransaction(offsets, groupMetadata)  // consumer 進度也納入交易
6producer.commitTransaction()      // 全部原子提交；失敗則 abortTransaction()

transactional.id 提供跨 session 的 fencing（隔離）：同一個 transactional.id 的新 producer 啟動時、coordinator 會 fence 掉舊的、避免「殭屍 producer」在崩潰後復活還繼續寫。這是冪等的 PID 機制做不到的跨 session 保證。

實機限制：kafka-console-producer.sh 帶 --producer-property transactional.id=... 不會自動呼叫 initTransactions()、會直接報 IllegalStateException: Cannot add partition ... before completing a call to initTransactions。完整 transaction 生命週期只能在 client code 中驗證、無法用 console 工具演示。本文的 transaction 行為描述依官方 producer API 語義、生命週期程式碼未經本地 client 實機跑通。

Transaction 的另一半在 consumer 端：isolation.level=read_committed。預設的 read_uncommitted 會讀到尚未 commit、甚至最終被 abort 的 transactional 訊息。設成 read_committed 後、consumer 只會看到已 commit 的 transactional 訊息、abort 的訊息對它不可見、未 commit 的訊息會被擋在 last stable offset（LSO）之前等待。

1# consumer 以 read_committed 隔離級別讀取、只看已 commit 的 transactional 訊息
2kafka-console-consumer.sh --topic repl-demo --from-beginning \
3  --isolation-level read_committed \
4  --bootstrap-server kafka1:9092

需要注意：對非 transactional 的普通訊息、read_committed 跟 read_uncommitted 行為相同 — 普通訊息一律可見。隔離級別只對 transactional 訊息產生差異。這也是為什麼若上游沒有任何 transactional producer、把 consumer 改成 read_committed 不會有任何可觀察的效果。

端到端 exactly-once 的邊界與成本

端到端 exactly-once 的意思是：訊息從 producer 到 consumer 處理結果、整條路徑上「不重不漏」。它由前面所有零件疊出來、但有明確的適用邊界、不是萬用保證。

Kafka 原生能提供 exactly-once 的範圍是 Kafka-to-Kafka 的封閉迴圈：consume from Kafka、process、produce to Kafka、commit offset、整個用 transaction 綁定。Kafka Streams 框架把這套封裝成 processing.guarantee=exactly_once_v2 一個配置、底層就是 transaction + 冪等 + read_committed 的組合。在這個封閉迴圈內、exactly-once 是真實成立的。

邊界出現在 離開 Kafka 的那一刻。當處理結果要寫進外部系統（資料庫、HTTP API、第三方服務、寄信、扣款）、Kafka 的 transaction 管不到外部系統的提交。一筆訊息「已扣款但 offset commit 前崩潰」這種跨系統不一致、Kafka transaction 無法消除 — 它只保證 Kafka 內部的原子性。跨系統的 exactly-once 要靠外部系統自己的冪等鍵（idempotency key）、或 outbox pattern、或兩階段提交、由應用層補上、不是 Kafka 送的。

成本方面、exactly-once 不是免費的耐久性升級：

務實的判斷是：先確認需求真的是 exactly-once、還是「at-least-once + 下游冪等」就夠。多數業務（包括金流）用 at-least-once 送達 + 下游用業務冪等鍵去重、就達到了「效果上不重複」、且吞吐與複雜度成本遠低於完整 transaction exactly-once。完整的 Kafka transaction exactly-once 留給 Kafka-to-Kafka 的 stream processing pipeline、那是它的甜蜜點。這個取捨對映 3.6 processing-recovery-semantics 對「在哪一層放冪等」的判讀。

故障演練

可靠性配置的價值在故障時才顯現。以下演練在 3-broker KRaft 叢集（RF=3、min.insync.replicas=2）上跑、用停 broker 製造 ISR 收縮、觀察各配置的真實行為。

ISR 收縮到低於 min.insync.replicas 時 acks=all 被拒

演練：起 3-broker 叢集、建 RF=3 / min.insync.replicas=2 的 topic、初始 ISR = 三台全在。依序停掉兩個 follower broker、觀察 ISR 收縮、再用 acks=all produce。

初始狀態（ISR 三份全在、acks=all 正常）：

1Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 2,3,1
2# acks=all produce → exit=0

停一個 follower（broker 3）、ISR 收縮到 2 份、仍滿足 min.insync=2：

1Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 2,1
2# acks=all produce → exit=0（ISR=2 仍 >= min.insync=2、寫入接受）

再停一個 follower（broker 1）、ISR 收縮到只剩 leader 1 份、低於 min.insync=2：

1# acks=all produce → broker 拒絕：
2[Producer] Got error produce response ... Error: NOT_ENOUGH_REPLICAS, retrying
3org.apache.kafka.common.errors.NotEnoughReplicasException:
4  Messages are rejected since there are fewer in-sync replicas than required.

判讀：這正是 min.insync.replicas 的設計意圖在運作。ISR 不足時、broker 選擇 明確拒絕寫入（NOT_ENOUGH_REPLICAS）、而不是降級成 acks=1 默默接受。對 producer 而言、寫入失敗會觸發 retry、retry 耗盡後拋例外、上游應用感知到「現在寫不進去」、可以 fail-fast 或 backpressure — 而不是寫了一筆只在單一 broker 上、隨時可能隨那台 broker 一起消失的「假成功」訊息。把資料遺失轉成可觀測的寫入拒絕、是這個配置的全部目的。

恢復：重啟兩個 broker、ISR 自動 expand 回三份、acks=all 恢復接受寫入：

1Topic: repl-demo  Partition: 0  Leader: 2  Replicas: 2,3,1  Isr: 1,2,3

附帶觀察：在 KRaft 模式下、controller 也是 quorum（本演練三台都兼任 controller）。同時停掉兩台、controller quorum 失去多數、kafka-topics.sh --describe 對 metadata 的查詢會 timeout（DisconnectException）。production 叢集應把 controller 數量與 broker 故障域分開規劃、避免 broker 故障連帶打垮 metadata 平面。

Unclean leader election 的取捨

當一個 partition 的所有 ISR replica 都不可用、只剩一個 曾經落後、已被踢出 ISR 的 replica 還活著、Kafka 面臨一個無法兩全的選擇。unclean.leader.election.enable=false（預設）會選擇 不選 leader：這個 partition 進入不可用狀態、拒絕讀寫、直到某個 ISR replica 恢復。unclean.leader.election.enable=true 會選擇 把那個落後的 replica 提為 leader：partition 立刻恢復可用、代價是那個 replica 上缺失的訊息（leader 掛掉前已 commit 但它還沒同步到的部分）永久遺失。

判讀：這是一個 可用性 vs 耐久性 的直接取捨、沒有正確答案、只有對映業務的選擇。對金流、訂單、審計這類「丟一筆都不行」的 topic、保持 false、寧可 partition 短暫不可用也不接受靜默資料遺失。對 metric、log、可重算的衍生資料、開 true 換可用性、丟幾筆可接受。預設 false 是合理的安全預設、但要意識到它的代價是「所有 replica 都不在 ISR 時、partition 會卡住不可用」、這在多 broker 同時故障時會發生。

Idempotent producer 對重送去重

演練：producer 開 enable.idempotence=true、acks=all、模擬 ack 丟失導致的重送。

判讀：冪等開啟後、producer 因網路超時重送的訊息帶相同 (PID, partition, sequence)、broker 認出 sequence 重複、丟棄重送並回成功、partition 內不出現重複。實機上 enable.idempotence=true 的 produce 寫入正常（exit=0）、消費端讀回的訊息數等於實際送出的邏輯訊息數、重送不放大。要記住的邊界仍是：這只覆蓋單一 producer session；producer 重啟換 PID 後、跨 session 的重複要靠 transaction 或下游冪等鍵處理。

Transaction 中途失敗的 read_committed 隔離

演練：transactional producer 在 beginTransaction 後寫入若干訊息、然後 abortTransaction（模擬處理中途失敗）；consumer 分別用 read_uncommitted 與 read_committed 讀取。

判讀：read_committed 的 consumer 看不到被 abort 的訊息 — 中途失敗的 transaction 對它等於沒發生過、不會讀到「處理一半的髒資料」。read_uncommitted 的 consumer 則會讀到這些最終被 abort 的訊息、若據此處理就產生了不該發生的副作用。這是 transaction 隔離的核心價值：把「transaction 失敗」的可見性控制在 commit 邊界內。

本段的 abort 行為依官方 transaction 語義描述。本地以 kafka-console-consumer.sh --isolation-level read_committed 驗證了隔離級別參數可用、且對已 commit 的普通訊息 read_committed 與 read_uncommitted 輸出一致（普通訊息一律可見、隔離級別只對 transactional 訊息產生差異）；完整的 begin/abort transaction 生命週期需 client code、未用 console 工具跑通。

Capacity / cost

各配置的容量與成本影響、決定它適用的規模與 topic 類別：

務實 default：

• 業務 topic 一律 RF=3 + acks=all + min.insync.replicas=2、idempotence 預設開
• 容忍度算術 RF - min.insync.replicas 要 ≥ 1、否則單台 broker 維護就會中斷寫入
• 完整 transaction exactly-once 只給 Kafka-to-Kafka pipeline；跨系統用 at-least-once + 下游冪等鍵
• unclean.leader.election 保持 false、除非該 topic 明確可丟資料換可用性

整合 / 下一步

跟 processing-recovery-semantics 對位

寫入承諾保證訊息留在 broker、但 處理 的不重不漏在 consumer 端。3.6 processing-recovery-semantics 展開 consumer 的 commit 時機、崩潰恢復的 replay 範圍、以及「冪等放在哪一層」的判讀 — 跟本文的 transaction exactly-once 邊界互補：本文界定 Kafka 能送什麼、那篇界定處理端怎麼接才不放大重複。

跟 event-contract-replay-boundary 對位

Exactly-once 的封閉迴圈假設訊息格式穩定、replay 可重現。3.7 event-contract-replay-boundary 展開 schema 演進與 replay 邊界 — 當 transaction 提供的原子性遇上 schema 變更、replay 舊訊息的可重現性會受 contract 影響、是 exactly-once 在時間維度上的延伸限制。

對應反例 3.C9

3.C9 Queue 語義誤配 是本文兩條軸線混淆的真實後果：broker 遷移後「名稱上相近的 delivery semantics」在失敗重播時產生不同結果、出現重複扣款與狀態漏更新。判讀路徑正是本文的拆分 — 先確認是寫入承諾（acks / ISR）還是處理語義（idempotence / commit 時機）出問題、不要用 queue depth 這種寫入承諾層的指標去判斷處理語義層的故障。

對應案例 3.C21 Goldman Sachs MSK 遷移

3.C21 Goldman Sachs MSK 遷移 揭露遷移時可靠性配置的細節風險集中在 client 端的 timeout / flush / LB 配置、而非 broker 本身。本文的 acks=all 在 ISR 不足時拒絕寫入、若 client 端的 retry 與 timeout 沒對齊（如 flush timeout 太短）、會把「broker 正常的 backpressure」誤判成「遷移失敗」。可靠性配置與 client 容錯參數要一起驗證。

下一步路由

• 上游概念：delivery semantics、idempotency 知識卡
• 同 vendor：Kafka overview 的 producer / consumer 設計段
• 下游能力：3.6 processing-recovery-semantics、3.7 event-contract-replay-boundary、6.12 idempotency / replay
• 方法論：Vendor 深度技術文章的寫作方法論

本文是跨 vendor migration playbook、cross-link Kafka 跟 AWS MSK。跑 migration-playbook-methodology 6 維 audit 後對映 Operational = High（self-managed → AWS managed）→ Type C operational redesign hybrid。

$15K/month operational cost 拆解

跟 Datadog → Grafana Stack（H cost variant）同 framing — 用 cost 拆解開頭、不是「為什麼遷」driver list：

最大成本塊是 operational FTE、不是 infrastructure。MSK 把 50-80% operational 工作轉嫁 AWS、留 application + cost monitoring 給 SRE。

跑 6 維 diff dimension audit：

Operational = High（其他 Low-Medium）→ Type C operational redesign hybrid。

為什麼遷：FTE / availability / consistency 三條 driver

• Operational FTE：Kafka self-managed + ZooKeeper / KRaft + Prometheus 端到端 ops 是 0.5-1 FTE、MSK 把 patch / HA / backup 全託管
• Availability：MSK 自動 multi-AZ broker + auto-recovery、self-managed 自管 broker 故障 RTO 30 分鐘-2 小時
• Consistency with cloud stack：已 deep on AWS（RDS / S3 / Lambda）、MSK 進 same VPC + IAM auth、降低 cross-vendor 設置成本

反向 driver（MSK → self-managed）：

• Throughput / GB 規模大時 MSK 跨 broker cost 反轉（cost > self-managed）
• 需要 Kafka 客製化（custom plugin / kraft early adopter / 非 AWS region）
• Multi-cloud / hybrid 架構不想 vendor lock

Operational redesign 對位

跟 PostgreSQL → Aurora / MongoDB → Atlas 同 Type C pattern：

每行 operational concept 都需要 migration plan、application code 不變但 運維知識體系全換。

4-phase migration（Type C 標準流程）

Phase 0：Pre-migration audit

• Workload sizing → MSK broker class：當前 throughput / partition count / topic count
• Application connection pattern audit：客戶端 producer / consumer 用 SASL / mTLS / plaintext？哪個 application
• Topic config audit：retention / replication factor / cleanup policy
• Backup pattern audit：有 MirrorMaker / cross-cluster mirror 嗎

Phase 1：MSK cluster 建置（2-3 週）

 1resource "aws_msk_cluster" "main" {
 2  cluster_name           = "production"
 3  kafka_version          = "3.6.0"
 4  number_of_broker_nodes = 3
 5
 6  broker_node_group_info {
 7    instance_type   = "kafka.m5.large"
 8    client_subnets  = var.private_subnets
 9    security_groups = [aws_security_group.msk.id]
10    storage_info {
11      ebs_storage_info {
12        volume_size = 1000
13        provisioned_throughput {
14          enabled           = true
15          volume_throughput = 500
16        }
17      }
18    }
19  }
20
21  client_authentication {
22    sasl {
23      iam = true        # IAM auth (推薦)
24      scram = false
25    }
26  }
27
28  configuration_info {
29    arn      = aws_msk_configuration.main.arn
30    revision = aws_msk_configuration.main.latest_revision
31  }
32
33  encryption_info {
34    encryption_in_transit {
35      client_broker = "TLS"
36    }
37  }
38
39  logging_info {
40    broker_logs {
41      cloudwatch_logs {
42        enabled   = true
43        log_group = aws_cloudwatch_log_group.msk.name
44      }
45    }
46  }
47}

Phase 2：Data migration（MirrorMaker 2.0）

1Self-managed Kafka ──(MM2)──→ MSK
2                       │
3                consumer offset sync
4                       │
5                topic config sync

MM2 跑 1-7 天、依 topic 量 + retention 期間；replica.lag 對齊後進 cutover。

Phase 3：Cutover

• Application 端切 bootstrap.servers 從 self-managed → MSK
• Producer 漸進切（10% → 50% → 100%）
• Consumer 切換時 offset 從 MM2 sync 過的位置開始
• Self-managed cluster read-only standby 2 週

Production 故障演練

Case 1：IAM auth 沒設、application 連不上

徵兆：cutover 後 application 報 SaslAuthenticationException: Access denied；MSK 端 cloudWatch log 顯示 IAM principal 不認。

根因：MSK IAM auth 要求 client 跑 MSK IAM auth library（Java 用 aws-msk-iam-auth、Python 用 aws-msk-iam-sasl-signer-python）；application 端用 standard Kafka client、不知道怎麼 sign IAM signature。

修法：

 1# Python kafka-python + IAM auth
 2from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
 3from kafka import KafkaProducer
 4
 5class AwsMskIamProvider(MSKAuthTokenProvider):
 6    def token(self):
 7        return self.generate_auth_token('us-east-1')[0]
 8
 9producer = KafkaProducer(
10    bootstrap_servers='b-1.mycluster.kafka.us-east-1.amazonaws.com:9098',
11    security_protocol='SASL_SSL',
12    sasl_mechanism='OAUTHBEARER',
13    sasl_oauth_token_provider=AwsMskIamProvider(),
14)

EKS pod 必須有 IAM role（IRSA）對 MSK cluster kafka-cluster:Connect action。

Case 2：Version pinning、3.6.0 跟 self-managed 行為差

徵兆：cutover 到 MSK 3.6.0 後、某些 consumer 跑舊 client 失敗；新 broker 改 default inter.broker.protocol.version 但 client 不認。

根因：MSK 升 Kafka version 後 broker config 變動、舊 client（< 2.8）跟新 broker 協議不對；self-managed 端可能用更舊 broker version 跑、看不出問題。

修法：

1. Pre-migration：所有 client 升 Kafka client library 2.8+
2. MSK kafka_version 對齊 self-managed：先建 MSK 3.0 / 3.5、跟 self-managed 一致、cutover 後再升
3. Phase rollout：用 Tiered Storage + retention 策略保留舊資料、新 producer / consumer 用新 version

Case 3：Metric pipeline 失效、SOC dashboard 無數據

徵兆：cutover 後 Grafana dashboard 顯示 MSK metric 0；舊 JMX exporter 抓不到 MSK；CloudWatch 有 metric 但 SOC 端不接 CloudWatch。

根因：MSK 不暴露 JMX、metric 走 CloudWatch / open monitoring (Prometheus + Grafana)、跟自建 JMX-based pipeline 不對等。

修法：

1. Open monitoring enabled：MSK config 設 open_monitoring.prometheus.jmx_exporter.enabled = true、跑 Prometheus 對 MSK broker 拉 metric
2. CloudWatch → Prometheus：用 cloudwatch-exporter 拉 CloudWatch metric 進 Prometheus
3. Dashboard refresh：Grafana dashboard 對 MSK-specific metric name 重寫（kafka_server_* → aws_kafka_* 或統一 alias）

Case 4：Cross-cluster mirror（MM2 → MSK）配置複雜

徵兆：MM2 跑了 1 週、self-managed 跟 MSK consumer offset 沒同步；application 切過去後 重新讀整批舊資料、duplicate processing。

根因：MM2 consumer offset sync 需要 跨 cluster mapping、source 端 offset 跟 target 端 offset 不直通；MM2 預設 offset sync 沒打開。

修法：

1# MM2 config
2source.consumer.bootstrap.servers=self-managed-kafka:9092
3target.consumer.bootstrap.servers=msk-cluster:9098
4target.security.protocol=SASL_SSL
5sync.group.offsets.enabled=true       # 必須打開
6emit.checkpoints.enabled=true
7checkpoints.topic.replication.factor=3

Architecture：consumer 切換時讀 MM2 checkpoint topic、不直接讀 internal offset；application 端用 idempotent + dedup key、avoid duplicate processing。

Case 5：MSK billing 暴漲、Tiered Storage / cross-AZ 沒控

徵兆：MSK 第一個月帳單比預估高 50%；breakdown 後發現 cross-AZ traffic（producer/consumer 跨 AZ）+ Tiered Storage 退到 S3 的 hot tier。

根因：

• MSK auto multi-AZ deployment 不可避免 cross-AZ traffic、producer 寫 partition leader 可能跨 AZ
• Tiered Storage 對 hot data（retention < 24 小時）會多 storage cost；cold data 才 cost-effective

修法：

1. Application AZ-aware routing：producer 走 same-AZ broker（用 rack-aware producer config）、降 cross-AZ
2. Retention 對齊 hot tier：< 24 小時 retention 用 broker local storage、24 小時+ 才走 Tiered Storage
3. Reserved instance：MSK 不直接 reserved、但 EBS / data transfer 可預付、降 10-20%

Capacity / cost

判讀：< 50 broker organization MSK ROI 通常 6-12 月持平、之後省 FTE；50+ broker 大 organization 自管 cost 可能反而低。

整合 / 下一步

跟 Kafka ↔ NATS migration 對位

兩條 Kafka 出路：

• MSK：operational simplification、protocol drop-in、cost 中等漲；適合 繼續用 Kafka paradigm 的 organization
• NATS：paradigm shift、application 必須改、適合 單純 messaging 不要 event sourcing 的 use case

多數 organization 不需要 paradigm shift、MSK 更合理；真正需要 lightweight messaging 才走 NATS。

跟 Confluent Cloud 對位

Confluent Cloud 是另一個 managed Kafka、跨 cloud（AWS / GCP / Azure）；MSK 是 AWS-only、但跟 IAM / VPC 整合更深。Multi-cloud organization 走 Confluent、AWS-deep organization 走 MSK。

跟 IAM / Secrets Manager 整合

MSK + IAM auth + Secrets Manager（連 Vault → AWS Secrets Manager migration）是 AWS-deep stack 的標準組合；short-lived credential + IRSA 是 production best practice。

反向 migration（MSK → self-managed）

少見、通常是 cost 反轉（大 scale）或 multi-cloud strategy；流程鏡像對稱、注意 MSK Tiered Storage data 不直接 export、需要 先 disable tiered storage + recall data。

下一步議題

• MSK Connect：managed Kafka Connect、降 connector 運維、但 plugin ecosystem 比 self-managed Connect 少
• MSK Serverless：burst workload 適合、steady workload 反而貴
• Cost monitoring playbook：MSK billing 拆解每月跑一次、catch unexpected egress / tiered storage cost

相關連結

• Source vendor：Kafka
• 平行 migration playbook (Type C)：PostgreSQL → Aurora / MongoDB → Atlas
• 平行 H cost variant：Datadog → Grafana Stack
• 平行 paradigm shift：Kafka ↔ NATS
• Methodology：Migration playbook methodology

觀察

Pinterest 三個 AWS region（us-east-1 / us-east-2 / eu-west-1）跑 MirrorMaker v1、原版設計把 record 解壓+重壓、memory 用量 2-10x 於網路 bytes、CPU spike 與 OOM 頻繁。

判讀

Shallow Mirror 在 RecordBatch 層淺迭代 + ByteBuffer pointer 共享、避開 deserialize/re-compress。揭露「跨區同步不是純 I/O 問題、是 CPU + memory + 網路三維壓力」。

對應大綱

Kafka 進階主題：cross-region MirrorMaker / MirrorMaker 2 配置。

下一步路由

回 Kafka vendor 頁 與 3.C1 Meta FOQS。

引用源

• Pinterest Shallow Mirror

本文是 Kafka overview 的 implementation-layer deep article、聚焦保留與分層儲存。選型層的「該不該選 Kafka」「跟其他 broker 差在哪」見 overview；本文回答「保留策略怎麼設、log compaction 怎麼運作、冷熱分層怎麼讓容量跟保留期解耦、踩哪些坑」。配置段在 Apache Kafka KRaft 單節點實機驗證；tiered storage 段標註未實機驗證的範圍。

Retention 是 replay window 的物理邊界

Retention 的核心責任是決定「一筆訊息在 broker 上能存活多久」、而這條邊界直接界定 consumer 能往回重播多遠。Kafka 的 log 是 append-only 的事件序列、訊息寫入後不會被原地修改；retention 是唯一會把舊訊息從磁碟移除的機制。設多久、用什麼條件刪、刪掉之後 consumer 還能不能讀到，全由保留策略決定。

這條邊界之所以重要、是因為 Kafka 的多 consumer 模型讓「重播」變成一級能力。同一個 topic 可以被多組 consumer 各自從任意 offset 開始讀、每組維護自己的進度；只要訊息還在 retention 範圍內、新加入的 consumer 或出事後要補算的 consumer 都能從頭重讀。一旦訊息超過 retention 被刪、replay window 就到此為止、補償只能改走資料庫或上游來源。

Kafka 提供兩條獨立的保留軸、可單獨用也可同時用：

時間軸對齊的是 replay 需求：把 retention 設成「事故從發生到偵測到修復的最長時間」、確保發現要補算時事件還在。容量軸對齊的是成本與磁碟保護：避免某個突發高流量 topic 把 broker 磁碟寫滿、拖垮同 broker 上其他 partition。兩者同時設時是「誰先觸發誰生效」、所以容量軸常常會在高流量時段提前砍掉本來預期能保留 7 天的事件——這個交互是後面故障演練的重點之一。

實機建立一個同時設兩軸的 topic、--describe 會把保留配置直接列在 Configs：

1# CLI 在容器內 /opt/kafka/bin/、bootstrap-server 指向 broker
2kafka-topics.sh --create --topic ret-delete --partitions 1 \
3  --config retention.ms=60000 \
4  --config retention.bytes=10485760 \
5  --config segment.ms=10000 \
6  --bootstrap-server localhost:9092
7
8kafka-topics.sh --describe --topic ret-delete --bootstrap-server localhost:9092
9# Configs: retention.ms=60000,retention.bytes=10485760,segment.ms=10000,...

retention 不是寫死在建 topic 當下、線上可以用 kafka-configs.sh --alter 動態調整、立即生效不需重啟 broker：

1kafka-configs.sh --alter --entity-type topics --entity-name ret-delete \
2  --add-config retention.ms=3600000 \
3  --bootstrap-server localhost:9092
4# Completed updating config for topic ret-delete.
5
6kafka-configs.sh --describe --entity-type topics --entity-name ret-delete \
7  --bootstrap-server localhost:9092
8# retention.ms=3600000 sensitive=false synonyms={DYNAMIC_TOPIC_CONFIG:retention.ms=3600000}

動態調整的 retention 屬於 DYNAMIC_TOPIC_CONFIG、優先於 broker 層的 log.retention.* 預設值；synonyms 欄位會把覆蓋關係列出來、排查時可確認當前生效的是哪一層。

Segment 是刪除的最小單位

Retention 刪資料的最小單位是 log segment、不是單筆訊息。理解這一點才能解釋「為什麼設了 retention.ms 之後，過期的訊息有時還在」。每個 partition 的 log 在磁碟上被切成多個 segment 檔、只有 active segment（當前正在寫入的那一個）以外、已經 roll over 的 segment 才會被 retention 檢查並整段刪除。

Segment 何時 roll over 由兩個條件決定：segment.bytes（檔案大到上限、預設 1 GB、最小 1 MB）或 segment.ms（檔案存在時間超過設定）。實機寫入 ~6 MB 資料到一個 segment.bytes=1048576（1 MB）的 topic、磁碟上會看到 6 個 roll 過的 segment：

100000000000000000000.log   1045229   # 已 roll，可被 retention 刪
200000000000000001024.log   1046336   # 已 roll
300000000000000002048.log   1046336   # 已 roll
400000000000000003072.log   1046336   # 已 roll
500000000000000004096.log   1037748   # 已 roll
600000000000000005112.log    904737   # active segment，不會被刪

Retention 的實際刪除動作由背景執行緒週期性執行、頻率是 broker 層的 log.retention.check.interval.ms、預設 300000 毫秒（5 分鐘）。這代表「過期」跟「被刪」之間有最長一個檢查週期的延遲：訊息超過 retention.ms 的瞬間不會立刻消失、要等下一次檢查跑到、且該訊息所在的 segment 已經 roll over、整段才會被刪。實機把 retention.bytes 設成 2 MB、寫進 6 MB（6 個 segment）、在 5 分鐘檢查週期內查 earliest offset 仍是 0——超量的 segment 還沒被回收、因為檢查執行緒還沒跑到下一輪。

這個機制有兩個操作後果。其一、磁碟用量會在「超過 retention 上限」到「下一次檢查」之間短暫超標、容量規劃要把這段 overshoot 算進緩衝。其二、把 retention.ms 設得比 segment.ms 還短沒有意義：訊息要等所在 segment roll 才可能被刪、active segment 永遠刪不掉、所以實際最短保留時間是 max(retention.ms, segment 尚未 roll 的時間)。

cleanup.policy：delete 與 compact 是兩種回收語意

cleanup.policy 決定 retention 用哪種語意回收空間、是保留策略最關鍵的分岔。預設值 delete 是時間或容量到期就整段刪除、適合事件流（event stream）：訊息代表「發生過的事實」、過了 replay window 就沒有保留價值。另一個值 compact 是 log compaction、語意完全不同：它保留每個 key 的最新值、刪除同 key 的歷史版本、適合「狀態快照」型資料。

兩者的判準是這份 log 表達的是「事件序列」還是「最終狀態」。訂單建立、付款完成、商品瀏覽這類事件、每一筆都是獨立事實、用 delete；使用者個人設定、商品庫存當前值、CDC 同步出來的資料表鏡像這類「同一個 key 不斷被覆寫、只關心最新值」的資料、用 compact。Kafka 內部的 __consumer_offsets topic 就是 compact——它只需要每個 consumer group 的最新 offset、不需要歷史 commit 記錄。

兩者可以同時開（cleanup.policy=compact,delete）：先按 key 壓縮保留最新值、同時對壓縮後的結果再套時間 / 容量上限。用 kafka-configs.sh 切換時、逗號分隔的值要用中括號群組、否則會被解析成兩個獨立 config：

1kafka-configs.sh --alter --entity-type topics --entity-name ret-delete \
2  --add-config 'cleanup.policy=[compact,delete]' \
3  --bootstrap-server localhost:9092
4# Completed updating config for topic ret-delete.
5# describe: cleanup.policy=compact,delete

Log compaction 用最新值取代歷史

Log compaction 的核心責任是讓一個 topic 收斂成「每個 key 的最新狀態」、同時保有 Kafka 的 log 重播能力。它的運作方式是背景的 log cleaner 執行緒掃描已 roll 的 segment、對每個 key 只保留 offset 最大的那筆、把同 key 的舊版本標記移除、再把存活的記錄重寫成新 segment。Compaction 後、新加入的 consumer 從頭讀一次、拿到的就是整個 keyspace 的最新快照、而非完整變更歷史。

實機驗證最直接：建一個 compact topic、對 3 個 key 各寫 2 個版本（舊值在前、新值在後）、等 compaction 跑完、從頭消費：

 1kafka-topics.sh --create --topic ret-compact --partitions 1 \
 2  --config cleanup.policy=compact \
 3  --config min.cleanable.dirty.ratio=0.01 \
 4  --config segment.ms=5000 \
 5  --config delete.retention.ms=100 \
 6  --bootstrap-server localhost:9092
 7
 8# 寫 k1/k2/k3 各舊值一筆、再各新值一筆（key:value 用冒號分隔）
 9printf 'k1:v1-old\nk2:v1-old\nk3:v1-old\nk1:v2-new\nk2:v2-new\nk3:v2-new\n' | \
10  kafka-console-producer.sh --topic ret-compact \
11  --property parse.key=true --property key.separator=: \
12  --bootstrap-server localhost:9092
13
14# 等 segment roll + compaction，再從頭消費
15kafka-console-consumer.sh --topic ret-compact --from-beginning \
16  --property print.key=true --property print.offset=true \
17  --timeout-ms 6000 --bootstrap-server localhost:9092
18# Offset:3  k1  v2-new
19# Offset:4  k2  v2-new
20# Offset:5  k3  v2-new

寫進 6 筆、從頭只讀到 3 筆——k1/k2/k3 的 v1-old（offset 0-2）被壓縮移除、只留每個 key 的 v2-new。關鍵細節：offset 沒有重新編號、留存記錄保留原始 offset（3、4、5）、log 的位置語意不變、其他 consumer 的 offset 進度不會錯位。

Compaction 的觸發不是即時的、由幾個參數共同決定。min.cleanable.dirty.ratio 是「髒比例」門檻、髒記錄（已被新版本取代但還沒清掉的舊版本）佔 log 比例超過這個值、cleaner 才會處理該 partition、預設 0.5（驗證時調成 0.01 加速觸發）。segment.ms 控制 active segment 多久 roll、只有 roll 過的 segment 能被 compact。delete.retention.ms 控制 tombstone（value 為 null 的刪除標記）保留多久——compaction topic 用 null value 表示「這個 key 已刪除」、tombstone 要保留夠久讓所有 consumer 都讀到刪除事件、之後才清掉。

Tombstone 是 compaction 表達「刪除」的方式：寫一筆 key 存在、value 為 null 的記錄、compaction 會把該 key 的所有歷史連同這筆 tombstone 在 delete.retention.ms 之後一起清除。這讓 compact topic 能表達「key 從存在到被刪」的完整生命週期、而不只是「永遠累積最新值」。

Tiered Storage 讓容量與保留期解耦

以下 tiered storage 段落依 Apache Kafka 官方文件（KIP-405）與 Pinterest / LinkedIn 公開案例敘述、未在本文的 KRaft 單節點環境實機驗證。Apache Kafka 的原生 tiered storage（remote.storage.enable）在當前版本屬 early-access、需要額外的 RemoteStorageManager plugin 與 broker 設定；正式採用前以官方文件版本標註為準。

Tiered storage 的核心責任是把 broker 的「儲存容量」跟「保留期長度」解耦。傳統 Kafka 的保留期受限於 broker 本機磁碟：想保留 30 天、就得讓每個 broker 的 local disk 容納 30 天的全量資料、retention 拉長等於 broker 數量或單機磁碟線性增長、而 broker 的 CPU / 記憶體 / 網路其實沒用到那麼多。Tiered storage 把 log 分成兩層：熱資料（近期、頻繁讀）留在 broker local disk（local tier）、冷資料（過期門檻之外、偶爾 replay）卸載到遠端物件儲存如 S3（remote tier）。Broker 只需放得下熱資料、保留期可以拉到數月甚至更久、成本變成 S3 的物件儲存費而非 broker 機群。

分層的觸發由 local.retention.ms / local.retention.bytes（本機保留多久 / 多大、超過就卸到 remote）跟整體的 retention.ms / retention.bytes（含 remote 的總保留邊界、超過才真正刪除）共同界定。一筆訊息的生命週期變成：寫入 local tier、超過 local retention 卸到 remote tier、超過整體 retention 從 remote 刪除。Replay window 因此可以遠大於 broker local disk 容量。

讀取路徑分熱冷兩條、效能特性不同。Consumer 讀近期 offset、資料在 local tier、走的是 Kafka 一向的 page cache + 順序讀路徑、低延遲高吞吐。Consumer 讀很舊的 offset（例如出事後從幾週前重播）、資料在 remote tier、broker 要先從 S3 把對應 segment 拉回來才能 serve、第一次讀的延遲明顯高於熱路徑、吞吐受 S3 頻寬與 broker 拉取並行度限制。這個熱冷讀差異是 tiered storage 的核心取捨——也是故障演練要處理的場景。

業界對 tiered storage 有兩條不同的工程路線、對應不同的 broker 角色定位：

Pinterest 的 broker-decoupled 做法把 ~200 TB/day 熱資料卸到 S3、讓 consumer 直接從 S3 拉冷資料、broker 不再是冷讀的熱路徑。它揭露的設計判讀是「broker 運算資源」跟「跨 AZ 網路成本」其實該分開治理、而不是綁在 broker 容量擴張上——保留期變長不該等於 broker 機群變大。

LinkedIn 的分層叢集策略是另一個層次的「分層」：把不同業務特性與可靠性需求的 workload 拆到不同叢集（依關鍵程度分群、例如關鍵 / 一般 / 實驗性，分層名稱為示意而非案例原文用詞）、避免混在同一叢集時故障與資源競爭互相放大。這裡的「分層」指叢集隔離、不是儲存的冷熱分層。兩種「分層」常被混談、但解的是不同問題：tiered storage 解單一 topic 的儲存成本、tiered clusters 解多 workload 的隔離治理。

故障演練

Retention 太短、replay window 不夠補事故

徵兆：下游 consumer 出 bug、產出錯誤的衍生資料、幾天後才被對帳發現；要從原始事件重播修復時、發現最舊的事件已經被刪、replay 從某個時間點之後才有資料、之前的修不回來。

根因：retention.ms 設得比「事故從發生到偵測到開始修復的最長時間」短。Replay window 由 broker retention 與 consumer checkpoint 共同界定、retention 是其物理上限；偵測延遲一旦超過 retention、要補算時原始事件已過期。常見的隱性誘因是把 retention 按「正常 consumer 跟得上的進度」來設（例如 consumer 通常落後幾分鐘、就設 1 天保險）、卻沒按「最壞情況下多久才會發現問題」來設。

修法：

1. 把 retention.ms 對齊事故偵測到修復的最長時間、而非 consumer 正常落後量；對帳 / 審計類 pipeline 的偵測週期常以天計、retention 要跟著拉到對應天數。
2. 對「偵測延遲可能很長」的關鍵 topic、在下游另留可重算的來源（資料庫快照、上游 source of truth）、不把 Kafka retention 當唯一補償依據。
3. 用 kafka-configs.sh --alter 動態延長 retention 是即時生效的、但只對「還沒被刪」的訊息有用——已刪的救不回來；所以調整要趁事故升級前、發現偵測週期被低估的當下就改、不是等出事才改。
4. Replay 邊界對齊見 3.7 Event Contract 與 Replay Boundary：replay 要能指定 time range、超出 retention 的 time range 直接無效。

Compaction 開了、磁碟卻沒回收

徵兆：topic 設了 cleanup.policy=compact、預期同 key 舊版本會被清掉、磁碟用量卻持續上漲、--describe 看 partition log 一直變大；從頭消費仍讀到大量同 key 的歷史版本。

根因：compaction 觸發條件沒滿足。log cleaner 只處理已 roll 的 segment、active segment 永遠不壓縮；min.cleanable.dirty.ratio 預設 0.5、髒比例沒到一半 cleaner 不動手；如果寫入集中在少數 key、active segment 遲遲不 roll（segment.bytes / segment.ms 都沒到）、髒記錄全積在 active segment 裡、compaction 看不到它們。另一個常見原因是 broker 的 log cleaner 執行緒數（log.cleaner.threads）不足以跟上高寫入量、cleaner backlog 累積。

修法：

1. 確認 active segment 會適時 roll：對寫入量不大但需要及時壓縮的 topic、設 segment.ms（例如數小時）強制 roll、讓髒記錄離開 active segment 進入可壓縮範圍。
2. 視壓縮急迫度調 min.cleanable.dirty.ratio：要更積極壓縮就調低（驗證時用 0.01）、但調太低會讓 cleaner 頻繁重寫 segment、增加 I/O——這是壓縮及時性跟 cleaner 開銷的取捨。
3. 監控 cleaner backlog：看 broker 的 log-cleaner 相關 metric、backlog 持續成長代表 cleaner 執行緒不夠、加 log.cleaner.threads。
4. 確認沒有把 compact 用在「其實該 delete」的事件流上——事件流每筆 key 多半唯一、compaction 沒有舊版本可壓、磁碟自然不會降；那種情況該用 delete 加 retention。

Cold tier 讀延遲拖垮 replay

徵兆：開了 tiered storage、平時讀近期資料正常、一旦發起從幾週前的舊 offset 大規模 replay、consumer 的吞吐驟降、p99 拉取延遲飆高、broker S3 拉取頻寬打滿、同 broker 上其他正常 consumer 也跟著受影響。

根因：舊 offset 的資料在 remote tier、每次讀要先從 S3 把 segment 拉回 broker、第一次冷讀延遲遠高於 local tier 的順序讀。大規模 replay 等於一次要從 S3 拉大量冷 segment、S3 頻寬與 broker 拉取並行成為瓶頸；broker-coupled 架構下這些拉取流量全經過 broker、會排擠到熱路徑的正常服務。

修法：

1. 把大規模冷 replay 排到低流量時段、避免跟線上熱路徑爭 broker 資源與 S3 頻寬。
2. 控制 replay 的並行度與範圍：依 replay boundary 指定 time range / tenant / partition、分批拉冷資料、不要一次全量回放整個保留期。
3. 評估 broker-decoupled 架構（如 Pinterest 做法）：consumer 直接從 S3 拉冷資料、把冷讀流量從 broker 熱路徑移開、保護線上服務。
4. 容量規劃把「冷讀延遲」算進 RTO：replay window 拉很長能補很久以前的事故、但補的速度受 cold tier 吞吐限制、事故修復時間估算要把這段拉取時間算進去。

retention.bytes 在高流量時段提早刪

徵兆：retention.ms 明明設了 7 天、某次流量突增後、consumer 卻發現幾小時前的事件就已經被刪、replay 拿不到本該還在的資料；earliest offset 在沒人預期的時候大幅前移。

根因：retention.ms 與 retention.bytes 同時設時是「誰先觸發誰生效」。流量突增讓 partition log 在遠不到 7 天時就撞到 retention.bytes 容量上限、容量軸先觸發、舊 segment 被提前刪除——時間軸的 7 天承諾在高流量下失效。常見於「按平均流量估容量上限、卻遇到尖峰流量」、或多個 topic 共享磁碟時為了保護磁碟把每 topic 容量上限壓得偏低。

修法：

1. 釐清這個 topic 的保留承諾是時間還是容量主導：以 replay window 為準的關鍵 topic、容量上限要按「尖峰流量 × 保留天數」估、而非平均流量、否則尖峰時容量軸會偷走時間承諾。
2. 監控 earliest offset 與 log 大小的變化率：earliest offset 在非預期時間前移、就是 retention.bytes 提前觸發的訊號、加進告警。
3. 要硬保證時間保留、就把 retention.bytes 設成 -1（不限容量、純時間軸）、改用獨立的磁碟告警與容量規劃來防磁碟塞爆、而不是用 retention.bytes 兼做兩件事。
4. 評估 tiered storage：把保留壓力從 broker local disk 移到 remote tier、local 只留熱資料、就不必為了保護 broker 磁碟而把 retention.bytes 壓低、時間承諾不再被容量上限侵蝕。

容量與成本

實務 default：

• 事件流 topic 用 delete、retention.ms 對齊事故偵測到修復的最長時間、retention.bytes 設 -1 或按尖峰流量估、不讓容量軸偷走時間承諾。
• 狀態快照 / CDC 鏡像 topic 用 compact、確認 active segment 會適時 roll、監控 cleaner backlog。
• 需要長保留期（數月以上）且 broker 磁碟成本敏感時、評估 tiered storage、把冷資料移到 S3、broker 只放熱資料。
• 任何 retention 調整前先確認當前生效層級（kafka-configs.sh --describe 看 synonyms）、避免 broker 預設與 topic 動態配置混淆。

整合與下一步

跟 replay 邊界對齊

Retention 是 replay window 的物理上限、但 replay 能不能正確執行還要看 event contract 是否齊備（event id / schema version / occurred time / dedup key）。保留策略設計要跟 3.7 Event Contract 與 Replay Boundary 一起看：retention 決定「能不能讀到」、event contract 決定「讀到了能不能正確重播」、兩者缺一 replay 都不成立。相關概念見 retention 與 offset 知識卡。

跟分層叢集治理對位

本文的 tiered storage 解的是單一 topic 的儲存成本；3.C4 LinkedIn 分層叢集解的是多 workload 的隔離——把不同可靠性需求的 topic 拆到不同叢集、避免資源競爭互相放大。保留策略在分層叢集裡會按層差異化：critical 叢集拉長 retention 保 replay、experimental 叢集縮短 retention 控成本。

跟 broker-decoupled 架構的取捨

3.C11 Pinterest broker-decoupled tiered storage 把冷讀流量從 broker 熱路徑移開、是「cold tier 讀延遲拖垮 replay」故障演練的架構級解法；它跟 3.C12 Pinterest Shallow Mirror 揭露的「跨區同步是 CPU + memory + 網路三維壓力」一起、構成 Pinterest 在儲存與複製兩條路徑上的成本治理。

回上游

• 上游 vendor 頁：Apache Kafka（「Tiered storage」與「Cross-region 與分層叢集」段）
• 平行 deep article：consumer rebalance 與 lag 診斷 / replication、ISR 與 exactly-once（同 vendor 其他實作層議題）
• 下游能力：3.4 consumer 設計 / 6.12 idempotency / replay

業務背景

Shopify 的核心資料儲存是 100+ 個 MySQL shard，每個 shard 承載不同商家的交易資料。下游系統（搜尋索引、analytics、資料倉儲）需要近即時地取得資料變更。原本用 query-based 方案（內部系統 Longboat）輪詢資料庫，但隨 shard 數量跟資料量成長，輪詢的延遲跟資料庫負載壓力持續惡化。

遷移到 log-based CDC（Debezium over Kafka Connect）後，pipeline 的穩態規模是 ~150 個 Debezium connector 跑在 12 個 Kubernetes pod、Black Friday peak 100K records/sec、P99 latency < 10s。

技術挑戰

Snapshot 鎖定 read replica

Debezium 在初始同步（snapshot）時需要取得一致性快照。MySQL connector 的預設行為是對 read replica 取 global read lock，鎖住的時間跟表大小成正比。Shopify 的大表 snapshot 可能鎖住 read replica 數小時，影響線上查詢。

Shopify 工程師直接向 Debezium 上游貢獻了「lock-free snapshot」機制 — 用 MySQL 的 GTID（Global Transaction ID）確保一致性，取代 global read lock。這個改動後來合併進 Debezium 主線，所有使用者都受益。

Oversized record

MySQL 的 blob / text 欄位可能產生超過 1 MB 的 CDC record。Kafka 的 message size limit（預設 1 MB）會讓這些 record 被 producer 拒絕。調大 max.message.bytes 是一個選項，但會影響 broker 的記憶體跟 replication 效率。

Shopify 的解法是把 oversized payload 寫到 GCS（Google Cloud Storage），CDC record 只帶 GCS pointer。Consumer 端在需要完整資料時再從 GCS 取。這個 pattern 把 Kafka 維持在「傳遞事件 metadata」的定位，大型 payload 走 object storage。

Connector 故障隔離

150 個 connector 跑在 12 個 pod 上，一個 connector 的 failure（例如某個 shard 的 MySQL 做了 schema change、binlog 格式不相容）可能影響同 pod 上的其他 connector。Shopify 用 Kafka Connect 的 distributed mode + task rebalance 做故障隔離，但 rebalance 本身在 connector 數量多時有延遲。

解法與取捨

回寫教材的連結

• 3.3 outbox pattern：CDC 是 outbox pattern 的 log-based 替代方案。Shopify 的 case 揭露 CDC 的工程成本集中在 snapshot 跟 schema evolution，outbox 的成本集中在應用層 dual-write。
• Kafka vendor 頁：Kafka Connect / CDC 的進階主題。
• 3.1 broker basics：message size limit 跟 broker 資源的關係。

判讀徵兆

讀者在自己的系統看到以下訊號時，應該回讀本案例：

• CDC snapshot 過程持續數小時、鎖住 read replica 影響線上查詢
• CDC record size 頻繁超過 Kafka 的 message size limit
• Kafka Connect connector 數量超過 50 個、rebalance 時間開始明顯增長
• 從 query-based 同步（輪詢）切換到 log-based CDC 的評估階段

引用源

• Capturing Every Change From Shopify’s Sharded Monolith

本文是 Apache Kafka overview「KRaft 與 Schema Registry」段的 implementation-layer deep article。Overview 已交代 Schema Registry 在事件總線中的定位；本文聚焦 怎麼設 compatibility、wire format 長什麼樣、schema 怎麼安全演進、演進設錯會打掛什麼。對應 Event Schema Compatibility 知識卡的 implementation 展開。

為什麼事件總線需要一個獨立的 schema 治理元件

Schema Registry 是把「event 的結構契約」從 producer 與 consumer 的程式碼裡抽出來、集中存放並強制版本相容性的元件。它承擔的責任是讓不同 service、不同部署節奏的 producer 與 consumer 在 schema 改版時仍能互通，而不需要全體同時上線。Kafka broker 本身只存 bytes、不理解 payload 結構；一旦多個團隊往同一個 topic 寫事件、又各自獨立發版，schema 漂移就會在 consumer 端炸開。

這個責任在單一 service 內部不存在。一個 service 自己 produce、自己 consume，schema 改版同一個 deploy 就同步了，序列化用什麼格式都行。Schema Registry 解的是 跨 service、跨團隊、跨部署時間 的契約問題：A 團隊升級了訂單事件加一個欄位，B 團隊的對帳服務還跑舊版 consumer，C 團隊的風控服務跑更舊版——三方不同步演進，靠的就是 registry 在 producer 註冊新 schema 時先擋下破壞相容性的改動。

Yelp 的 Schematizer 案例 把這個責任拉到極端：一天數十億訊息、數百個 service、數千個 schema，自建 registry 強制所有 message 走 Avro、訊息只帶 schema ID。它揭露 schema 治理是 data pipeline 的核心責任、不是 add-on——當規模到了數千 schema，沒有集中強制的相容性檢查，跨服務事件契約會在某次發版後悄悄斷掉，而 broker 不會報任何錯。

Confluent Schema Registry 是業界事實標準的實作；Apicurio 是 CNCF 生態的開源替代，額外支援 OpenAPI / AsyncAPI artifact、且提供 Confluent-compatible API endpoint，遷移成本低。兩者都把 schema 存進一個 Kafka topic（Confluent 用 _schemas，single-partition、compacted），registry 自己是無狀態的，掛掉重啟後從該 topic rebuild。

Schema ID 嵌進訊息的 wire format

Confluent wire format 在每筆訊息的 value（或 key）前面加 5 個 byte：1 個 magic byte（固定 0x00）加 4 個 big-endian byte 的 schema ID，後面才接序列化後的 payload。Consumer 拿到訊息先讀這 5 個 byte，用 schema ID 去 registry 查對應 schema，再用該 schema 反序列化。這是「訊息只帶 schema ID、不帶 schema 本體」的機制——schema 本體只在 registry 存一份，訊息裡放的是指標。

本文用 OrbStack 起 confluentinc/cp-kafka + confluentinc/cp-schema-registry，用 Avro console producer 寫一筆 {"id":1,"name":"alice"}，再 dump 出 raw bytes 驗證 wire format：

1000000 00 00 00 00 01 02 0a 61 6c 69 63 65 0a   >.......alice.<

逐 byte 拆解：

• 00：magic byte，標識這是 Confluent wire format
• 00 00 00 01：4-byte big-endian schema ID = 1，consumer 拿這個去 registry 查 schema
• 02：Avro 把 id（long）以 zigzag varint 編碼，1 編成 0x02
• 0a 61 6c 69 63 65：name（string）長度 5（zigzag 0x0a）加 UTF-8 的 alice

這個格式有兩個工程後果。第一，consumer 反序列化任何訊息前都要能連到 registry——registry 掛掉，已 cache schema ID 的 consumer 還能跑，但遇到沒見過的 schema ID 就卡住。第二，schema ID 是全域單調遞增的整數、跨 subject 共用：同一份 schema 被多個 topic 註冊只會有一個 ID。實機驗證可以看到，先註冊到 user-value 的 schema 拿到 id:1，之後用同樣結構寫 users-demo topic 時，registry 認出是同一份 schema、複用 id:1：

1{"subject":"users-demo-value","version":1,"id":1,"schemaType":"AVRO", ...}

version 是 subject 內的序號（每個 subject 從 1 開始）、id 是全域的。除錯時看到某筆訊息反序列化失敗，第一步就是讀那 4-byte schema ID、去 registry 撈出它指向哪個 schema、跟 consumer 預期的對不對。

序列化格式取捨：Avro、Protobuf、JSON Schema

Schema Registry 支援三種格式，差異不只是語法、而是演進規則與生態的取捨。

Avro 的演進靠 reader schema 與 writer schema 分離：訊息用 writer schema（寫入時的版本）序列化，consumer 用自己的 reader schema（讀取時的版本）反序列化，registry 提供兩者做 schema resolution。這是 Avro 在 data pipeline 場景的核心優勢——欄位帶 default 時，舊資料用新 schema 讀會自動填 default，新資料用舊 schema 讀會自動忽略多出來的欄位。Yelp、多數 Kafka-native data platform 都選 Avro，正是因為它的演進語意最完整。

Protobuf 用 field number 而非欄位名做 wire 識別：欄位改名不破壞相容性（number 沒變即可），刪欄位要 reserve 掉 number 避免重用。已經用 gRPC 的團隊讓 RPC 與事件共用同一份 .proto，省一套 schema 維護。代價是 Protobuf 的 default 語意較弱（proto3 沒有 explicit presence 的 scalar 一律有 zero value），某些演進判斷不如 Avro 直觀。

JSON Schema 適合既有系統已經大量用 JSON、且看重人類可讀與 validation keyword（required、minimum、pattern）的場景。代價是 payload 較大（欄位名重複出現在每筆訊息）、型別保證弱於前兩者。當吞吐量大、payload size 敏感時，JSON Schema 的頻寬成本會顯著高於 Avro 的 binary 編碼。

選型判準：data pipeline 為主、重演進安全 → Avro；已有 gRPC、RPC 與事件共用 → Protobuf；既有 JSON 生態、重可讀性而吞吐量不極端 → JSON Schema。三者可在同一個 registry 並存（每個 subject 各自標 schemaType），但同一個 subject 內不能混用格式。

Subject naming strategy 決定相容性檢查的邊界

Subject 是 registry 裡做版本管理與相容性檢查的基本單位；naming strategy 決定「哪些 schema 被歸進同一個 subject、因而要互相相容」。選錯 strategy 會讓相容性檢查管太寬或太窄，是後面故障演練的根源之一。

TopicNameStrategy 是預設，subject 名就是 <topic>-value。實機驗證可以看到，用 Avro producer 寫 users-demo topic 時，registry 自動建立 users-demo-value subject：

1["user-value","users-demo-value"]

預設策略的隱含假設是「一個 topic 只承載一種事件型別」。這對多數 topic 成立，但當業務要把多種相關事件（例如 OrderCreated 與 OrderCancelled）放進同一個 topic 以保證跨事件 ordering 時，TopicNameStrategy 會把兩種 record 當成同一個 subject 的版本演進、互相做相容性檢查——這幾乎一定失敗，因為兩種事件結構本來就不同。

這時要改 RecordNameStrategy（subject = record 全名，跨 topic 同名 record 共用一份演進歷史）或 TopicRecordNameStrategy（subject = topic + record 名，同 topic 多型別各自獨立演進）。判準：一個 topic 一種事件 → 預設即可；一個 topic 多種事件且要保 ordering → TopicRecordNameStrategy；同一種 record 散在多個 topic 要強制全域一致 → RecordNameStrategy。Producer 與 consumer 必須設成同一個 strategy，否則 consumer 會用錯 subject 去查 schema。

Compatibility level：四種基礎 × transitive

Compatibility level 是 registry 在 producer 註冊新 schema 時套用的相容性規則，決定哪些 schema 改動會被擋下。它回答的問題是「新 schema 跟既有 schema 比，誰應該能讀誰寫的資料」。設定可以是全域預設、也可以 per-subject 覆寫。

BACKWARD 是 Confluent 預設，實機驗證可以確認：

1{"compatibilityLevel":"BACKWARD"}

BACKWARD 保護的是「consumer 先升級」的演進順序——新版 consumer 必須能讀舊版 producer 還在寫的舊資料。它允許的安全改動是「加帶 default 的欄位」與「刪欄位」：新 schema 讀舊資料時，舊資料缺的新欄位用 default 補；新 schema 不要的欄位讀舊資料時忽略。它擋下的是「加沒有 default 的必填欄位」——舊資料沒這欄位、新 consumer 又要求它存在，就讀不出來。

FORWARD 反過來保護「producer 先升級」：舊版 consumer 要能讀新版 producer 寫的資料。它允許「刪帶 default 的欄位」與「加欄位」。當演進順序是 producer 先上、consumer 慢慢跟（例如先讓 producer 開始寫新欄位、consumer 之後才用）時選 FORWARD。

FULL 同時滿足兩者，代價是只能做「加帶 default 的欄位」與「刪帶 default 的欄位」這類雙向安全的改動，演進自由度最低但最安全。當 producer 與 consumer 的升級順序無法協調（大型組織、多團隊各自排程）時，FULL 把演進約束到怎麼改都不會斷。

四種各有一個 transitive 變體（BACKWARD_TRANSITIVE 等）。非 transitive 只檢查新 schema 對 最近一版；transitive 檢查新 schema 對 該 subject 所有歷史版本。差別在這個場景：v1 → v2 相容、v2 → v3 相容，但 v3 對 v1 不相容。非 transitive 會放行 v3（因為只比 v2）；transitive 會擋下。當 consumer 可能 replay 很舊的歷史資料（Kafka 的長期保留 + replay 正是常態），transitive 才能保證任何歷史版本都讀得出來。3.7 event contract / replay boundary 講的 replay 邊界，在 schema 層的對應就是 transitive compatibility。

安全演進規則：實機驗證註冊與拒絕

把上面的規則落到實際操作。在預設 BACKWARD 下，註冊 v1（id + name）後，加一個帶 default 的 email 欄位是安全的，registry 接受並記為 v2：

1{"id":2,"version":2,"schemaType":"AVRO", ...}

user-value 的版本列表確認累積成兩版：

1[1,2]

接著嘗試加一個 沒有 default 的 age（int）必填欄位——這破壞 BACKWARD，因為新 consumer 讀舊資料時 age 沒值也沒 default。registry 回 HTTP 409 並指出確切原因：

1{"error_code":40901,"message":"Schema being registered is incompatible with an earlier schema for subject \"user-value\", details: [{errorType:'READER_FIELD_MISSING_DEFAULT_VALUE', description:'The field 'age' at path '/fields/3' in the new schema has no default value and is missing in the old schema', ...}], compatibility: 'BACKWARD'}

READER_FIELD_MISSING_DEFAULT_VALUE 精確命中規則：reader（新 schema）多了一個舊資料沒有、又無 default 的欄位。registry 另外提供 compatibility check API，可以在不真正註冊的前提下先問「相不相容」，給 CI pipeline 在 PR 階段擋下破壞性改動：

1{"is_compatible":false}

由此導出兩條安全演進的操作規則。加欄位：一律帶 default（BACKWARD / FULL 都要），舊資料才能用新 schema 讀出。沒有合理 default 的「必填新欄位」不能直接加——要嘛在 producer 端先全部開始寫該欄位、確認資料齊全後再 promote，要嘛走新 topic / 新 record 而非原地演進。刪欄位：分步做。先讓所有 consumer 停止依賴該欄位（部署一輪），確認沒人讀之後，下一輪才從 schema 拿掉。一步到位刪掉還在被讀的欄位，會在 FORWARD / FULL 下被擋、在 BACKWARD 下放行但打掛還沒升級的 consumer。

Production 故障演練

Case 1：producer 加必填欄位無 default，打掛舊 consumer

徵兆：某團隊 producer 發版後，另一團隊的舊 consumer 開始大量反序列化失敗、SerializationException 或 AvroTypeException: Found X, expecting Y，consumer lag 暴衝、訊息卡在 poll 階段。producer 端與 broker 端完全沒報錯——訊息照寫成功。

根因：subject 的 compatibility level 被設成 NONE（或該欄位走了 FORWARD 不檢查 reader 缺欄位的路徑）。producer 加了一個沒有 default 的必填欄位、registry 沒擋，新訊息帶新 schema ID 寫進 topic。舊 consumer 用自己的舊 reader schema 去反序列化新 writer schema 的資料，遇到自己不認識又無從補值的結構就炸。問題不在 producer 也不在 broker，在 registry 沒在註冊時擋下這次演進。

修法：

1. 把 compatibility level 改回至少 BACKWARD：實機驗證過 NONE 會直接放行破壞性 schema——把 compatibility 設成 NONE 後，前面被 409 拒絕的破壞性 schema 立刻被接受成 v3。NONE 等於把演進安全完全交給人，多團隊場景幾乎一定出事。
2. 回退 producer：先讓 producer 退回舊 schema 止血，恢復舊 consumer 可讀。
3. 重新演進：欄位帶 default 重發，或若該欄位語意上必填、走「先讓 producer 寫、consumer 升級、再 promote」的分步路徑。
4. CI 防線：把 compatibility check API（/compatibility/subjects/<s>/versions/latest）接進 producer repo 的 CI，PR 階段就用 is_compatible:false 擋掉，不等到 production 註冊時才發現。

Case 2：compatibility level 設錯，放行破壞性變更

徵兆：team 以為有 registry 把關所以放心演進，某次刪掉一個還在被下游讀的欄位、registry 接受了，下游服務隔天開始拿到 null / 缺欄位、business logic 走錯分支，但沒有任何 exception——資料「看起來正常」只是少了東西。

根因：compatibility level 設成了 FORWARD 而需求其實是 BACKWARD，或設成 NONE。實機驗證可以看到 per-subject 覆寫的行為——對 user-value 單獨 PUT FORWARD 後查 config 回 {"compatibilityLevel":"FORWARD"}，這個 subject 的檢查方向就跟全域預設不同了。FORWARD 允許刪帶 default 的欄位（保護 producer 先升級的順序），但團隊實際的演進順序是 consumer 後升級——方向錯配，registry 放行的正是會打掛 consumer 的那類改動。

修法：

1. 依演進順序選 level，不是隨手設：consumer 先升級選 BACKWARD；producer 先升級選 FORWARD；順序無法協調選 FULL。把這個決策寫進 topic ownership 文件、不是留給註冊當下的人臨時判斷。
2. 可能 replay 歷史就用 transitive：Kafka 長期保留 + replay 是常態，非 transitive 只擋最近一版、replay 舊資料時舊 schema 仍可能讀不出。長期保留的 topic 預設用 *_TRANSITIVE。
3. per-subject 覆寫要留審計：全域預設外的每一個 per-subject 覆寫都是一個風險點，要能查出「誰、何時、為什麼把這個 subject 改成跟預設不同」。

Case 3：schema ID 對不上，consumer 反序列化失敗

徵兆：consumer 報 Schema not found; error code: 40403 或反序列化拿到亂碼、欄位錯位。某些訊息正常、某些失敗，跟特定 producer 或特定時間段相關。

根因有幾種，靠讀訊息前 5 byte 的 schema ID 定位：

• registry 換過、ID 不一致：跨環境（dev / staging / prod）各自一套 registry，schema ID 全域遞增的順序不同，同一份 schema 在不同環境是不同 ID。如果有人把 prod 的訊息 mirror 到 staging 而沒搬 schema，staging consumer 拿 prod 的 schema ID 去 staging registry 查就 404。
• 訊息根本不是 Confluent wire format：有 producer 沒走 schema-aware serializer、直接寫 raw bytes，前 5 byte 不是 magic + ID。consumer 把第一個 byte 當 magic、後 4 byte 當 ID 去查，撈到不存在或錯誤的 schema。
• registry 不可達或 cache 失效：consumer 端 schema cache 沒命中、又連不上 registry。

修法：

1. 讀 wire format 確認：dump 訊息 raw bytes，確認第一個 byte 是 00、接下來 4 byte 解出來的 ID 在目標 registry 查得到。本文驗證過 00 00 00 00 01 對應 schema id 1，這是除錯的第一手證據。
2. 跨環境 schema 搬遷：mirror 訊息時用 registry 的 import / export，或 MirrorMaker 搭配 schema 同步，不要只搬資料不搬 schema。
3. 隔離非 schema-aware producer：用 ACL 或 topic 命名規範強制所有 producer 走 schema serializer，避免 raw bytes 混進 schema-managed topic。

Case 4：subject naming strategy 衝突

徵兆：把第二種事件型別寫進既有 topic 時，producer 直接註冊失敗報 incompatible，或多 producer 寫同 topic 互相把對方的 schema 判成不相容、彼此發版互相擋。

根因：用 TopicNameStrategy（預設）卻往同一個 topic 放多種 record。subject 是 <topic>-value、整個 topic 共用一條演進線，registry 拿 OrderCancelled 去跟既有的 OrderCreated 做相容性檢查——兩種結構不同的事件當然不相容。strategy 的隱含假設（一 topic 一事件型別）跟實際用法（一 topic 多事件保 ordering）衝突。

修法：

1. 改 strategy 配合用法：一 topic 多事件 → TopicRecordNameStrategy，subject 變成 <topic>-<record 全名>，每種 record 各自一條演進線、不互相檢查。
2. producer 與 consumer 設同一個 strategy：strategy 不一致時 consumer 會用錯 subject 查 schema，拿到 null 或錯 schema。這是部署層的硬約束，要在共用 config 統一。
3. 若只是不小心寫錯 topic：那不是 strategy 問題、是路由問題，修 producer 的 topic 選擇邏輯，別為了繞過檢查改成 RecordNameStrategy。

容量與運維邊界

實務 default：data pipeline 場景選 Avro + 至少 BACKWARD；長期保留 + replay 的 topic 用 transitive；compatibility check 接進 CI 在 PR 階段擋破壞性改動，不依賴註冊當下把關；一 topic 一事件型別當預設、要多型別才動 naming strategy。Schema Registry 自己也是個要 HA 的元件——production 跑多副本、_schemas topic 的 replication factor 拉高，registry 是事件總線的單點時要當關鍵基礎設施對待。

整合與下一步

跟 CDC pipeline 的銜接

Shopify Debezium CDC 案例 跑在 100+ MySQL shard、150 個 Debezium connector 的規模（該案例記載的重點是 lock-free snapshot 與 oversized record 處理）。CDC pipeline 有一個一般性的 schema 演進壓力，以下依 CDC 機制推導、非該案例的結論：上游 DDL 一改，Debezium 產生的 Kafka record schema 跟著變，下游 consumer 受影響。Schema Registry 的 compatibility 檢查就是把這道衝擊在進 Kafka 時攔下的關卡——選錯 compatibility level，一次 ALTER TABLE 就可能透過 CDC 打穿整條 pipeline。Debezium 與 Kafka Connect 原生整合 Schema Registry，connector 設定裡指定 registry URL 與 naming strategy。

跟 replay 邊界與事件契約

3.7 event contract / replay boundary 講的是事件契約能 replay 多遠；schema 層的對應就是本文的 transitive compatibility。Replay 跨越多個 schema 版本時，只有 transitive 能保證任何歷史版本都讀得出來。兩者一起界定「這條事件流的契約能安全回放到多久以前」。

下游能力

• 概念索引：Event Schema Compatibility 知識卡（本文的 implementation 來源）
• 上游 vendor 頁：Apache Kafka（KRaft 與 Schema Registry 段）
• 對應案例：3.C14 Yelp Schematizer（schema 治理拉到平台層）、3.C13 Shopify Debezium CDC（CDC 場景的 schema evolution）
• 方法論：Vendor 深度技術文章的寫作方法論

觀察

Yelp data pipeline 一天數十億訊息、跨數百個 service、數千 schema、用自建 Schematizer 強制所有 message 走 Avro schema、訊息只帶 schema ID。

判讀

Schematizer 不只是 schema store、還做 schema evolution compatibility 與 topic 自動分配（不相容 schema 強制新 topic）。揭露 producer / consumer schema 治理要拉到平台層、靠工具強制、不靠人約定。

對應大綱

Kafka 進階主題：Schema Registry / Schema evolution。

下一步路由

回 Kafka vendor 頁 與 3.7 event contract / replay boundary。

引用源

• Yelp Schematizer: More than just a schema store

本文是 Apache Kafka overview「Multi-tenant 與配額治理」「Topic 生命週期治理」兩段的 implementation-layer deep article。Overview 說明這些議題對應哪些案例跟子議題、本文展開具體的 quota / ACL 配置、授權模型推導、故障徵兆與修法。

共享叢集的治理問題：一個叢集、多個互不信任的租戶

Multi-tenant Kafka 的核心問題是把一個物理叢集切成多個彼此隔離的邏輯空間、讓每個團隊用同一組 broker 卻不互相干擾。當 Kafka 從單一團隊的工具長成全公司的事件總線、叢集承載的不再是一條 pipeline、而是數十到數百個團隊的 producer 跟 consumer。這時叢集的瓶頸從「broker 夠不夠快」轉成「怎麼防止某個團隊的流量、權限、或 topic 失控波及其他所有人」。

Uber 的 Kafka 平台演進把這個轉換描述為「從單隊列問題提升到平台治理問題」。當事件平台服務眾多團隊、重點是配額、隔離、觀測與運維標準化、而非只擴 broker。擴 broker 解決的是總容量、解決不了「單一租戶吃光共享資源」這類隔離問題。

共享叢集的治理分三個獨立的軸、各自處理不同的失控來源：

三軸正交：quota 設好不代表權限對、ACL 鎖好不代表 topic 不會爆炸。下面逐軸展開、每軸都對應 production 踩過的失控場景。本文 quota 與 ACL 操作以 Kafka 4.2.0（KRaft 模式、apache/kafka:latest）實機驗證。

Quota：把頻寬與 request 容量切給租戶

Quota 是 broker 端對 client 的流量上限、由 broker 在超限時主動 throttle（延遲回應）而非拒絕、讓單一租戶無法把共享頻寬吃光。Kafka 的 quota 是 broker-side 強制、不依賴 client 自律 —— 即使 client 不配合、broker 也會在回應裡插入 throttle 延遲、把該 client 的有效吞吐壓回配額內。

三類 quota 度量

Kafka quota 度量三種資源、對應三類飽和：

前兩個 byte rate 防的是頻寬類飽和、適合「大訊息、穩定流量」的租戶。request_percentage 防的是另一種失控 —— 某租戶送大量極小的 request（例如每筆一個 byte、每秒幾萬筆）、byte rate 看起來很低、卻把 broker 的 request handler thread 佔滿。這種「請求數爆炸但流量不大」的攻擊型 pattern 只有 request_percentage 抓得到。一個 broker 預設有 N 個 request handler thread、request_percentage=200 代表允許該 client 用掉 2 條 thread 的時間（100% = 1 條）。

三種套用層級

Quota 可以套在三種 entity 上、精度遞增：

層級的選擇取決於認證模型。沒開認證的叢集只能用 client-id —— 但 client.id 由 client 自行宣告、可偽造、只適合內部信任環境的粗略區分。開了 SASL 認證後、user 才是可信的租戶邊界、quota 綁 user 才有隔離意義。最細的 user + client-id 組合用在「同一個租戶內、batch 匯入服務跟即時 API 服務要分開限流」這種情境：整個 billing 租戶有一個總配額、但裡面的 batch-importer 再單獨壓低、避免夜間批次把租戶配額吃光、害同租戶的即時服務沒頻寬。

設定與查詢（實機驗證）

設 client-id 層級、同時給 producer 跟 consumer byte rate：

1kafka-configs.sh --bootstrap-server localhost:9092 --alter \
2  --add-config 'producer_byte_rate=1048576,consumer_byte_rate=2097152' \
3  --entity-type clients --entity-name svc-orders
4# Completed updating config for client svc-orders.

設 user 層級、含 request_percentage：

1kafka-configs.sh --bootstrap-server localhost:9092 --alter \
2  --add-config 'producer_byte_rate=5242880,consumer_byte_rate=10485760,request_percentage=200' \
3  --entity-type users --entity-name tenant-billing
4# Completed updating config for user tenant-billing.

設 user + client-id 組合層級（同租戶內單獨壓低 batch 服務）：

1kafka-configs.sh --bootstrap-server localhost:9092 --alter \
2  --add-config 'producer_byte_rate=524288' \
3  --entity-type users --entity-name tenant-billing \
4  --entity-type clients --entity-name batch-importer
5# Completed updating config for user tenant-billing.

查詢時 entity 指定要對齊設定時的層級。查 user 層級：

1kafka-configs.sh --bootstrap-server localhost:9092 --describe \
2  --entity-type users --entity-name tenant-billing
3# Quota configs for user-principal 'tenant-billing' are
4#   consumer_byte_rate=1.048576E7, request_percentage=200.0, producer_byte_rate=5242880.0

組合層級要兩個 entity 都帶、否則查不到：

1kafka-configs.sh --bootstrap-server localhost:9092 --describe \
2  --entity-type users --entity-name tenant-billing \
3  --entity-type clients --entity-name batch-importer
4# Quota configs for user-principal 'tenant-billing', client-id 'batch-importer' are
5#   producer_byte_rate=524288.0

不帶 --entity-name 而只給 --entity-type clients 會列出所有 client-id 層級的 quota、適合稽核整個叢集的 quota 分布。

ACL：把存取權限綁到 principal

ACL 是 broker 對每個操作的授權檢查、把「誰（principal）能對什麼資源（resource）做什麼操作（operation）從哪裡來（host）」綁成一條規則、broker 在每次 produce / fetch / admin 操作前比對。Quota 管的是「用多少」、ACL 管的是「能不能用」—— 兩者正交、quota 不限制權限、ACL 不限制流量。

授權模型四要素

一條 ACL 由四個維度構成、四個維度交集才決定一次操作是否放行：

resource 的 pattern type 是隔離設計的關鍵：LITERAL 精確匹配單一資源名、PREFIXED 匹配整個前綴。多租戶的 topic 隔離靠 prefixed ACL 加命名規範 —— 給 tenant-billing 一條 billing. 前綴的 All 權限、它就能自由管理所有 billing. 開頭的 topic、卻碰不到 orders. 或別租戶的命名空間。命名規範在這裡不只是整潔、是授權邊界本身。

operation 的選擇要對齊角色。一個 producer 需要 topic 的 Write 跟 Describe（描述 partition metadata）；一個 consumer 需要 topic 的 Read Describe 加上 consumer group 的 Read Describe（commit offset 要對 group 有權）。漏掉 group 的 ACL 是常見錯誤：consumer 能讀到訊息、卻 commit 不了 offset、表現成不斷重複消費。

KRaft 的 StandardAuthorizer

ACL 的儲存與判定由 broker 的 authorizer 負責。KRaft 模式用 org.apache.kafka.metadata.authorizer.StandardAuthorizer、ACL 存在 metadata log（取代 ZooKeeper 時代的 AclAuthorizer 把 ACL 存在 ZK）。預設的 apache/kafka 容器不開 authorizer —— 不開時所有操作放行、ACL 指令也無從生效。啟用需要在 broker 設三項：

1authorizer.class.name=org.apache.kafka.metadata.authorizer.StandardAuthorizer
2super.users=User:admin
3allow.everyone.if.no.acl.found=false

super.users 列出繞過所有 ACL 檢查的管理身分、用來開機跟救援；少了它、開 authorizer 後第一個操作就會把自己鎖在外面。allow.everyone.if.no.acl.found=false 是隔離的前提 —— 設 true 時「沒有任何 ACL 的資源對所有人開放」、等於 deny-list 模式、漏設一個 topic 就全公司可讀。多租戶必須走 false 的 allow-list 模式：預設拒絕、明確授權才放行。

本文 ACL 操作以實機驗證：用上述三項 env（KAFKA_AUTHORIZER_CLASS_NAME / KAFKA_SUPER_USERS='User:ANONYMOUS' / KAFKA_ALLOW_EVERYONE_IF_NO_ACL_FOUND=false）配完整 KRaft single-node 設定起容器、PLAINTEXT 連線的 principal 為 User:ANONYMOUS、設為 super user 後即可用 kafka-acls.sh 操作。

ACL 配置（實機驗證）

給 producer 對單一 topic 的 write + describe：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:svc-orders \
3  --operation Write --operation Describe \
4  --topic orders.events

給 consumer topic 的 read + describe、外加 consumer group 的權限（一條指令同時建兩個 resource 的 ACL）：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:svc-fulfillment \
3  --operation Read --operation Describe \
4  --topic orders.events \
5  --group fulfillment-workers

prefixed ACL 把整個命名空間授權給一個租戶：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:tenant-billing \
3  --operation All \
4  --resource-pattern-type prefixed \
5  --topic billing.
6# Adding ACLs for resource
7#   `ResourcePattern(resourceType=TOPIC, name=billing., patternType=PREFIXED)`

host 限制把同一 principal 的權限綁到特定來源 IP：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --allow-principal User:svc-orders \
3  --allow-host 10.0.3.21 \
4  --operation Write \
5  --topic orders.events

deny 規則的優先序高於 allow —— 同一 principal 即使有 allow、命中 deny 就拒絕。用來在大範圍 allow（如 prefixed All）之上挖一個例外：

1kafka-acls.sh --bootstrap-server localhost:9092 --add \
2  --deny-principal User:svc-orders \
3  --deny-host 10.0.9.99 \
4  --operation Write \
5  --topic orders.events

列出特定 topic 的全部 ACL、用於稽核：

1kafka-acls.sh --bootstrap-server localhost:9092 --list --topic orders.events

Topic 生命週期治理：命名、ownership 與回收

Topic 生命週期治理把「topic 的建立、歸屬、淘汰」變成有規則的流程、避免死 topic 累積與 partition 數爆炸壓垮叢集的 metadata 面。Kafka 的每個 partition 都是 controller 要追蹤的 metadata 單位；topic 只增不減時、partition 總數隨團隊數線性成長、最終 controller 的 metadata 處理、broker 的 leader election、client 的 metadata fetch 都跟著變慢。

命名規範劃出 ownership

Topic 命名規範把 ownership 跟隔離邊界編碼進名字本身。一個可治理的命名規範通常含三段：租戶 / 領域前綴、語意名、版本。例如 billing.invoices.v1 —— billing. 前綴對齊 prefixed ACL 的隔離邊界跟 quota 的租戶歸屬、invoices 是語意、v1 給 schema 演進留出平行存在的空間。命名規範在多租戶不是風格問題、是三個治理軸的共同錨點：ACL 靠前綴授權、quota 靠前綴歸屬、回收靠前綴找 owner。

實機建 topic 時 Kafka 4.2.0 對 . 跟 _ 混用會出 metric 名稱碰撞警告：

1WARNING: Due to limitations in metric names, topics with a period ('.')
2or underscore ('_') could collide. To avoid issues it is best to use
3either, but not both.

成因是 metric 名把 topic 名裡的 . 跟 _ 都正規化掉、billing.invoices 跟 billing_invoices 可能對映到同一條 metric。命名規範應在 . 跟 _ 之間選一個當分隔符、全叢集一致、避免監控數據互相污染。

活躍判準與自動回收

死 topic 的回收靠可量化的活躍判準。LinkedIn 的 TopicGC以自動治理取代手動清理未使用 topic、降低 metadata 壓力並改善 produce / consume 效能。它的判讀是：當 queue 規模擴大、僅靠容量擴充不夠、topic 生命週期與治理自動化會成為可靠性關鍵。

TopicGC 是 LinkedIn 的內部系統、不是 Kafka 內建指令；它揭示的是一套可借鏡的回收流程結構：

1. 定義活躍判準：以 last produce / last consume timestamp 判斷 topic 是否仍在使用、設一段觀察窗（例如 N 天無寫入且無讀取）。
2. 分級回收：先標記（soft）、進入待回收狀態並通知 owner、保留一段 grace period、無人認領才真正刪除（hard）。兩段式避免誤刪仍有低頻流量的 topic。
3. 保留稽核：每次標記與刪除留紀錄、回收前後比對 controller log、partition 數量、produce / consume 效能指標、確認治理有效且無誤傷。

回收條件的設定要對齊業務節奏。純看 produce timestamp 會誤判「低頻但關鍵」的 topic（如月結批次）；活躍判準要同時看 produce 跟 consume、且觀察窗要長於最長的合法閒置週期。

Production 故障演練

Case 1：單一租戶暴衝吃滿頻寬（quota 缺位）

徵兆：某團隊上線一支新 backfill job、開始全速寫入；同叢集其他租戶的 producer 端 request-latency p99 從個位數 ms 跳到數百 ms、consumer lag 全面上升；broker network out 打到網卡上限、但 CPU 不高。受害的不是暴衝者自己、是所有共用 broker 的鄰居。

根因：叢集沒設任何 producer quota、或只對部分租戶設了 quota。沒有 broker-side throttle 時、單一 client 能用滿 broker 的 network / disk I/O、把共享頻寬擠光。byte rate 飽和的特徵是 network 打滿但 CPU 不高 —— 區別於 request_percentage 缺位導致的 CPU 飽和。

修法：

1. 立即對暴衝 client 設 producer_byte_rate、broker 即時 throttle、無需重啟。
2. 建立 quota 預設值：對所有 client-id（或 user）設一個保守的 default byte rate、新租戶上線自動受限、避免「漏設就無限」。
3. 區分 byte rate 與 request_percentage 飽和：network 打滿設 byte rate、CPU 打滿（高頻小訊息）補 request_percentage。
4. 容量規劃：把各租戶 quota 總和對齊 broker 的 network / disk 容量、留 headroom、避免「每個 quota 都合理但加總超過物理上限」。

Case 2：ACL 設太鬆或太緊

徵兆（太鬆）：稽核發現某 consumer 服務能讀到不屬於它的租戶 topic；或某 topic 被預期外的 principal 寫入、資料被污染。最壞情況是 allow.everyone.if.no.acl.found=true 下漏設 ACL 的 topic 對全叢集可讀寫。

徵兆（太緊）：consumer 能讀訊息卻不斷重複消費、log 顯示 commit offset 被拒；或 producer 報 TOPIC_AUTHORIZATION_FAILED、明明該有權限。

根因：太鬆來自 deny-list 心態 —— allow.everyone.if.no.acl.found=true 把「沒設 ACL」當成「開放」、漏設就外洩。太緊通常是漏掉 operation 或 resource：consumer 只給了 topic 的 Read、漏給 consumer group 的 Read Describe、於是讀得到但 commit 不了、表現成重複消費；producer 漏給 Describe、拿不到 partition metadata。

修法：

1. 走 allow-list：allow.everyone.if.no.acl.found=false、預設拒絕、明確授權才放行。
2. ACL 對齊角色模板：producer = topic Write + Describe；consumer = topic Read + Describe 加 group Read + Describe；漏 group ACL 是重複消費的常見根因。
3. 用 prefixed ACL 而非逐 topic 設、把授權邊界對齊命名規範前綴、減少漏設。
4. 稽核流程：定期 kafka-acls.sh --list 比對預期授權矩陣、把 ACL 納入版本控制與 review、而非手動逐條加。

Case 3：Topic 數量爆炸壓垮 metadata 面

徵兆：叢集 topic / partition 總數隨團隊增長爬到數萬以上；controller failover 時間從秒級拉長到分鐘級；broker 啟動載入 metadata 變慢；client 的 metadata fetch 變大變慢、rebalance 期間出現連鎖延遲。容量沒滿、但整個叢集的 control plane 變鈍。

根因：partition 是 controller 要追蹤的 metadata 單位、數量只增不減。每個團隊隨手建 topic、每個 topic 又開高 partition 數、總 partition 數線性甚至超線性成長、壓垮 metadata 處理。KRaft 相比 ZooKeeper 提高了 metadata 上限、但上限仍存在、不是無限。

修法：

1. Partition 數規劃納入 topic 建立流程：partition 數對應並行度上限、不是越多越好；多餘 partition 是純 metadata 成本。詳見 Partition 卡。
2. 回收死 topic 釋放 partition slot：見 Case 4 與生命週期治理段。
3. 監控 metadata 壓力訊號：controller log、partition 總數、controller failover 時間設告警、在壓垮前介入。
4. 規模化路徑：單叢集 metadata 逼近上限時、評估分群（依關鍵程度分多叢集）、見 overview 的 Cross-region 與分層叢集段與 LinkedIn Tiered Clusters案例。

Case 4：Unused topic 未回收

徵兆：叢集裡大量 topic 數月無 produce 也無 consume、卻持續佔 partition slot 跟 metadata；沒人記得某些 topic 屬於哪個團隊、不敢刪；新 topic 想建時撞到 partition 上限、被迫先擴叢集而非先回收。

根因：沒有活躍判準與回收流程、topic 只建不刪。歸屬資訊沒編碼進命名、回收時找不到 owner、於是「不敢刪」成為預設、死 topic 無限累積。這是 Case 3（metadata 爆炸）的慢性來源。

修法：

1. 建立活躍判準：以 last produce / last consume timestamp 加觀察窗判定死 topic、觀察窗長於最長合法閒置週期（避免誤刪月結類低頻 topic）。
2. 兩段式回收：先 soft 標記並通知 owner、grace period 內無人認領才 hard 刪除、避免誤刪。
3. 命名規範補 ownership：前綴對齊團隊、回收時能直接找到 owner、消除「不敢刪」。
4. 自動化加稽核：參考 TopicGC的流程結構、回收前後比對 metadata 與效能指標、留稽核紀錄。

容量與規模邊界

Quota 與 ACL 是 broker-side 即時生效、不需重啟、可隨租戶調整、運維成本低。生命週期治理是持續流程、不是一次性操作 —— 死 topic 會持續產生、回收要常態化。三軸的共同前提是命名規範：沒有可治理的命名、quota 找不到歸屬、ACL 邊界對不齊、回收找不到 owner。多租戶治理的第一步是先把命名規範立起來、再談 quota 與 ACL。

整合與下一步

跟 overview 與案例的對位

• 上游 vendor 頁：Apache Kafka —— 本文展開其「Multi-tenant 與配額治理」「Topic 生命週期治理」兩段
• 平台治理案例：3.C6 Uber Kafka 事件平台 —— 單隊列問題提升到平台治理
• 生命週期案例：3.C3 LinkedIn TopicGC —— 自動回收與 metadata 壓力
• 規模化分群：3.C4 LinkedIn Tiered Clusters —— metadata 逼近上限時的多叢集路徑
• 自管轉 managed 的 ACL cutover：3.C2 VMware → MSK

跟安全模組對位

ACL 是 Kafka 內建的授權層、處理 broker 級的 principal × resource 授權。完整的 secret 管理（SASL 認證憑證怎麼發、輪替、撤銷）屬於 07 資料保護與安全模組的範疇 —— ACL 綁的 principal 從哪來、由認證層決定、ACL 只負責「這個 principal 能做什麼」。多租戶的完整信任鏈是「認證確認身分（07）→ ACL 授權操作（本文）→ quota 限制用量（本文）」三層。

下一步議題

• Schema 治理：跨租戶共用 topic 時、schema compatibility 是另一層契約治理、見 overview 的 KRaft 與 Schema Registry段
• Consumer group ACL 細節：跟 Consumer group rebalance 的互動
• Quota 與 delivery semantics：throttle 延遲對 producer timeout / retry 的影響

相關連結

• 上游 vendor 頁：Apache Kafka
• 對位 deep article（同模組）：本模組其他 Kafka deep article 見 vendor 頁進階主題段
• 跨模組授權鏈：07 資料保護與安全模組
• 方法論：Vendor 深度技術文章的寫作方法論
• 知識卡：Topic、Partition、Consumer group

觀察

Airbnb logging pipeline 跨多個 topic、event size 從幾百 bytes 到幾百 KB、QPS 跨數個量級差異、Spark 一個 partition 對一個 task 造成 data skew、catch-up 一個 4 小時 lag 要再花 4 小時。

判讀

自建 balanced Spark Kafka reader、把 parallelism 從 partition 數解耦、按 event volume × size 重新分派 work。揭露 partition 數不該等同 consumer parallelism、要看 event 形狀。

對應大綱

Kafka 進階主題：Consumer 設計 / consumer lag / rebalance / partition + consumer group。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• Scaling Spark Streaming for Logging Event Ingestion

觀察

Robinhood 每天處理 billions of events / TB 資料、用於 risk signal、order quality、market data、fraud detection；team 多為 Python、不想用 JVM 生態。

判讀

把 Kafka Streams 的 stateful streaming 模式（topology、tables、windowing）移植到 Python library 形式、不需要 Yarn / Mesos resource manager。揭露 stream processing framework 選型常被語言生態主導、不是技術 feature。

對應大綱

Kafka 進階主題：跨語言 client / Streams framework / stream processing on Kafka。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• Faust: Stream Processing for Python

觀察

Walmart 每天 trillions of message、25K+ Kafka consumer 跑在 WCNP Kubernetes 多雲環境；最大痛點是 pod scaling / deploy / heartbeat fail 觸發 consumer rebalance、lag spike。

判讀

自建 Messaging Proxy Service（MPS、Kafka Connect sink connector）、把 consumer 從 partition-bound 解耦成 stateless REST service、可獨立 auto-scale、不用增 partition；內建 DLQ 處理 poison pill。揭露「consumer 該跟 partition 數綁定」這個假設在 K8s 規模化下不再成立。

對應大綱

Kafka 進階主題：rebalance storm / consumer lag / multi-tenant 配額。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• Reliably Processing Trillions of Kafka Messages Per Day

觀察

Wix 2000+ microservice、每天 66 billion Kafka 訊息、用自建 Greyhound（JVM library + polyglot sidecar）抽象 Kafka；troubleshooting 痛點是「卡住的 consumer 看不到原因、只能寫 DB 修復腳本」。

判讀

TLLSR 框架（Trace / Lookup / Longest-running / Skip-replay / Redistribute）解 single-partition lag、單筆 poison pill、handler 卡住等情境；consumer lag alert > 30 分鐘觸發。揭露原生 lag metric 無法定位「卡在哪」、需要 message-level trace + 操作介面。

對應大綱

Kafka 進階主題：consumer lag / observability / multi-tenant / poison message。

下一步路由

回 Kafka vendor 頁 與 3.5 紅隊章。

引用源

• Troubleshooting Kafka for 2000 Microservices at Wix

觀察

Wix cluster metadata 從 2019 年 5K topic / 45K partition 漲到 20K topic / 200K partition、每日 record 從 450M 漲到 2.5B、controller startup 與 broker stability 受 metadata 量壓垮。

判讀

不用 MirrorMaker、自建 Replicator service + Migration Orchestrator、用 Kafka topic 當控制平面協調 consumer 切換 + offset mapping；按 SLA 切多 cluster。揭露「topic / partition 數量」是 broker 級別的物理上限、不能無限擴張。

對應大綱

Kafka 進階主題：cross-region MirrorMaker / topic 生命週期 / 分層叢集策略。

下一步路由

回 Kafka vendor 頁 與 3.C3 LinkedIn TopicGC。

引用源

• Migrating to a Multi-Cluster Managed Kafka with 0 Downtime

業務背景

Spotify 的事件傳遞系統（Event Delivery）負責把使用者行為事件（播放、搜尋、推薦互動）從客戶端送到資料管線。系統跨 5 個 datacenter 運行 Kafka 0.7，production peak 700K events/sec、pressure test 達到 2M events/sec。事件資料是推薦系統、analytics 跟廣告計費的輸入，遺失事件直接影響商業決策的準確性。

2016 年，Spotify 決定把 Event Delivery 從 Kafka 遷移到 GCP Pub/Sub，而非升級到當時已發布的 Kafka 0.8+。

技術挑戰

MirrorMaker 的 best-effort 語意

Kafka 0.7 的跨 datacenter replication 工具 MirrorMaker 在 best-effort mode 下會丟失資料但向 producer 回報成功。對 Spotify 的場景，producer 端認為事件已送達，但跨 datacenter 的 mirror 實際上丟了一部分。丟失比例在正常情況下很低，但在 broker restart 或網路抖動時可以升高到影響 analytics 準確性的程度。

這個問題的根源是 Kafka 0.7 的 producer 沒有 idempotent 保證，MirrorMaker 的 consumer offset commit 跟 producer ack 之間有 gap。

Broker restart 後 producer 無法自動恢復

Kafka 0.7 的 producer 在 broker restart 後可能進入無法自動恢復的狀態 — 需要人工重啟 producer process。在 5 個 datacenter、數百個 producer instance 的規模下，每次 broker 維護操作都需要人工介入恢復 producer，運維成本跟 broker 數量成正比。

為什麼不升級到 Kafka 0.8+

Kafka 0.8 引入了 replication、新的 consumer API 跟更可靠的 producer。但 Spotify 評估後認為升級的成本接近重新部署：

• Kafka 0.7 到 0.8 的 wire protocol 不相容，需要全量遷移而非滾動升級
• 所有 producer / consumer 的 client library 都要更換
• Spotify 同時在向 GCP 遷移基礎設施，Kafka 的自管運維模式跟 GCP 的託管方向不一致

相比之下，GCP Pub/Sub 提供了託管的 exactly-once 語意、跨 region replication、零運維。遷移成本跟升級 Kafka 版本的成本相當，但遷移後的長期運維成本低得多。

解法與取捨

Spotify 的判斷是：在同時進行 GCP 遷移的背景下，維護自管 Kafka 的投資回報比不上切換到託管方案。這個判斷跟 Kafka 本身的能力無關 — Kafka 0.8+ 的可靠性已經解決了 0.7 的問題。決策的關鍵變數是「組織正在往哪走」，不只是「技術上哪個更好」。

回寫教材的連結

• Kafka vendor 頁：cross-region replication 跟 MirrorMaker 的進階主題。Spotify 的案例是「早期版本限制」的歷史教訓，Kafka 3.x 的 KRaft + idempotent producer 已解決這些問題。
• Pub/Sub vendor 頁：託管 MQ 的定位跟適用場景。
• 3.6 processing recovery semantics：exactly-once 語意的工程實踐。Spotify 案例揭露 exactly-once 在早期 Kafka 版本不成立。
• 3.1 broker basics：broker 版本跟可靠性保證的關係。

判讀徵兆

讀者在自己的系統看到以下訊號時，應該回讀本案例：

• 使用舊版 Kafka（< 2.0）且跨 region replication 的資料完整性無法驗證
• Broker restart 後需要人工重啟 producer、運維成本跟 broker 數量成正比
• 組織正在做基礎設施遷移（on-prem → cloud），考慮是否同步切換 MQ
• 評估「升級現有系統 vs 遷移到新系統」的決策框架

引用源

• Spotify’s Event Delivery — The Road to the Cloud (Part II)

觀察

Global Investment Research 把 ~12 microservice / 30 instance 從 on-prem Kafka 遷到 MSK；用 MM2 同步 topic / ACL / consumer group / offset、選擇 atomic cutover、整體耗時 ~7 小時。

判讀

把 MM2 預設的 prefixed topic 改成 identical name；遇到 flush timeout（5s → 30s）、request size、NLB idle timeout 350s vs client 540s 衝突。揭露 managed 服務遷移的細節風險集中在「LB / timeout / topic naming」這些 client 端配置、不在 broker 本身。

對應大綱

Kafka 進階主題：cross-region MirrorMaker / managed broker 遷移 / ACL 設計。

下一步路由

回 Kafka vendor 頁 與 3.C2 VMware → MSK。

引用源

• How Goldman Sachs Migrated from On-Premises Apache Kafka to Amazon MSK

觀察

Trivago 跨 3 個 region 跑 50+ Kafka sink service、每個 always-on 用 1 CPU + 1 GB；CPU/mem-based autoscaling 無效（sink 多為 I/O bottleneck、CPU 平坦）。

判讀

KEDA 以 consumer lag 為 scaling signal、minReplicaCount=0 達到 scale-to-zero、daily replica-hour 從 50 降到 1-2。揭露「resource usage 不等於工作量」、event-driven 場景該看 backlog signal。

對應大綱

Kafka 進階主題：consumer lag / autoscaling / multi-tenant 配額。

下一步路由

回 Kafka vendor 頁 與 3.4 consumer 設計。

引用源

• From Always-On to On-Demand: Scaling Kafka Sinks with KEDA

本文不重複 MongoDB vendor overview 已寫過的 change streams 簡介 — 而是 production CDC pipeline 部署 + 失敗修復的實作層教學。

MongoDB 適用度前置判讀：進到 CDC pipeline 設計前先確認 workload 在 MongoDB 適用區（document shape 主導 / contract layer 該放哪 / 跨雲 hedging 是否需要）— 詳見 schema-design-pattern 開頭 3 軸前置判讀、本篇不重複展開。Change streams 是 已選 MongoDB 後 的 event-driven 整合議題。

問題情境：第一版 CDC pipeline 跑幾週的踩雷

典型觸發場景：application 寫 MongoDB 後還要 dual-write Elasticsearch / Redis / data warehouse、application code 越塞越多 hook、寫入失敗的補償邏輯散落各處。改用 change stream → Kafka → downstream sink 後、有了第一版 CDC pipeline、但連續工作幾週後出現：

• Downstream 漏 event 或 duplicate event
• Connector restart 後 resume token 過期（oplog 已滾掉）、整個 collection 必須重灌
• Sharded cluster 上 collection-level change stream 跟 cluster-wide change stream 行為不同、application 連 mongos 跟連 single shard 拿到不同 event

讀者徵兆：

• MongoDB Kafka Connector log ChangeStreamHistoryLost 或 ResumeTokenChanged
• Downstream Kafka topic event count vs source collection write count 不平
• Replication oplog 跟 change stream consumer 的 lag 同時升

Case anchor：CDC pipeline resume token 過期導致全量重灌的具體 incident 細節需未來 case 補完、本文以「常見 failure pattern」+ 容量公式處理、不憑空編造 incident 數字。側面引用 Spotify Kafka → PubSub migration（pipeline-level migration 經驗對照）。

核心機制

Change stream 是 MongoDB 3.6+ 原生 CDC、本質上是 oplog tail 包裝成 cursor API。可以從 collection / database / cluster 三個 scope 開：

• Collection-level：監看單一 collection 的變更
• Database-level：監看整個 database 的所有 collection
• Cluster-wide：監看整個 cluster 的所有 database

Oplog 是 capped collection、預設 size = disk 5% 或 50GB（取較小）。Resume token 對應 oplog entry 的 timestamp + UUID + documentKey。Token 必須對應仍在 oplog 內的 entry — oplog 滾掉就拿不到 token 對應的位置、ChangeStreamHistoryLost。

Resume token 兩種用法：

• _id：每個 event 都帶、application 自己存
• startAfter / resumeAfter parameter：重啟 cursor 時帶上

fullDocument: "updateLookup"：update event 預設只給 delta、加這個 option 會額外 query 一次 primary 拿完整 doc；高頻 update 下成本顯著（primary 負擔翻倍）。

Pre-image / post-image（6.0+）：可以拿到 update 前的 doc 狀態、需 collection-level option changeStreamPreAndPostImages: true。

Cluster-wide vs collection-level change stream：

• Cluster-wide 必須打 mongos、event ordering 是 global
• Collection-level 可直接打單 shard、ordering 只在該 shard 內
• Sharded cluster 上 cluster-wide stream 容易把 mongos 變單點瓶頸（所有 shard 的 event 都收斂到 mongos）

MongoDB Kafka Connector（Confluent / MongoDB 官方）：

• Source connector：把 change stream → Kafka topic
• Sink connector：把 Kafka topic → MongoDB
• At-least-once 語義、需 application 處理 idempotency

對應 knowledge card：change-data-capture、replication-channel、replication-slot（MongoDB 沒 slot、概念對照）。

操作流程

Step 1：scope 決策樹。

Step 2：oplog sizing。容量公式：

1oplog size >= peak write rate × max acceptable consumer downtime

典型設 24-72 小時可恢復窗口。例：peak 5K WPS、想容忍 48 小時 connector down、oplog 至少 5K × 86400 × 2 ÷ docs_per_GB ≈ 看實際 doc size 決定。在 Atlas 上 oplog size 可直接調、自管 cluster 改 replSetResizeOplog。

Step 3：Kafka Connector 配置。

 1{
 2  "connector.class": "com.mongodb.kafka.connect.MongoSourceConnector",
 3  "connection.uri": "mongodb://...",
 4  "database": "shop",
 5  "collection": "orders",
 6  "publish.full.document.only": "true",
 7  "change.stream.full.document": "updateLookup",
 8  "copy.existing": "true",
 9  "copy.existing.namespace.regex": "shop\\.orders",
10  "errors.tolerance": "none",
11  "offset.flush.interval.ms": "10000"
12}

關鍵欄位：

• change.stream.full.document: "updateLookup"：每 update 額外 query primary 拿完整 doc（成本意識）
• copy.existing: "true"：connector 啟動時先把現有 collection 全量複製、再切到 change stream — 適合初次部署
• errors.tolerance: "none"：sink 失敗時 batch 停在 dead-letter queue、不 silently drop

Step 4：resume token persistence。Connector 把 token 寫 Kafka __consumer_offsets 或外部 store；application 自管 change stream 時要寫到 durable store（不是 in-memory）。

Step 5：filter pipeline。Change stream 支援 aggregation pipeline 把過濾下推到 MongoDB：

1const pipeline = [
2  { $match: { "operationType": { $in: ["insert", "update", "delete"] } } },
3  { $match: { "fullDocument.region": "ap-tokyo" } }
4]
5const changeStream = db.orders.watch(pipeline)

把過濾下推減少 connector 處理量、特別是高頻 collection 上。

Step 6：downstream idempotency。Sink 收 Kafka event 時用 documentKey._id + clusterTime 做 dedup key — at-least-once 語義意味著 connector restart 後幾分鐘 event 會重發。

驗證點：

• Source collection write count vs Kafka topic event count 差異 < 0.1%
• Resume token age < oplog retention 的 50%（健康狀態）
• Connector restart drill 能 5 分鐘內接回

Rollback boundary：source connector 是 read-only 對 MongoDB 無傷；sink connector 要備份 target 才能還原；resume token 寫錯 → 從 startAtOperationTime 回退到時間點重跑。

失敗模式

Resume token 過期（oplog 滾掉）：connector down 太久、oplog 已超出 retention、ChangeStreamHistoryLost → 必須 copy.existing 全量重灌、期間 downstream 看不到新資料。預防是 oplog sizing 留 buffer + connector lag alarm + token age 監控（age > oplog retention 的 50% 預警）。

updateLookup 在高頻 update 下打爆 primary：每筆 update event 都觸發一次 primary query、primary 負擔翻倍。修法是改 collection-level pre/post image（6.0+）、由 MongoDB 自己在寫入時記錄、或在 application 補完整 doc 後再寫 Kafka、不用 updateLookup。

Sharded cluster cluster-wide stream 打爆 mongos：所有 shard 的 event 都收斂到 mongos、mongos 變單點瓶頸。修法是改 collection-level stream 多 connector 並行、每 connector 連 mongos 但只訂單一 collection。

At-least-once 變 duplicate flood：connector restart 點之後幾分鐘 event 重發、downstream 沒做 idempotency → 重複 side effect（重複發 email、重複扣款）。修法是 sink 端強制 idempotency（dedup key 寫 Redis / DB）、不能假設「我用 at-least-once 但實際不會 duplicate」。

Schema drift 突然 break sink：MongoDB 寫了新欄位 / 改型別、sink connector 的 JSON schema 不認、batch 停在 dead-letter queue。修法是 schema 變動有 validation gate（見 schema design pattern）、sink schema 設 lenient 模式吃 unknown field、或加 schema registry 統一版本。

Backup / DDL 期間 change stream 異常：reIndex / compact / dropCollection 觸發特殊 event、connector 沒處理 → consumer 停。修法是 connector 處理特殊 event 邏輯要明確、不認得的 operation type 至少 log warning 而不是 silently stuck。

Anti-recommendation：

• 簡單的 outbox pattern + application transactional write 對於低吞吐 / 單 sink 的場景比 change stream + Kafka 簡單；不是所有「需要 event 通知」的場景都要 CDC pipeline
• 若 downstream 只是同一 region 同團隊的 Elasticsearch index、$merge 寫進中介 collection 或 application 雙寫 + 對賬可能成本更低
• Resume token 過期是這條路徑最痛的事故、oplog sizing 是 投資而不是成本 — 不要為了省 storage 把 oplog 設太小

容量與觀測

關鍵 metric：

• Oplog 健康：oplog 寫入速率與保留時間
• Change stream 健康：cursor age、resume token 距 oplog 頭尾的距離
• Connector 健康：connector lag（Kafka offset 對比 source write）
• 下游健康：event count diff（source write count vs sink apply count）、event time → arrival time lag 分布

Mongo command：

• db.getReplicationInfo()：oplog 大小 / 時間範圍
• db.printReplicationInfo()：oplog 摘要
• db.currentOp({ "op": "getmore", "ns": "local.oplog.rs" })：看 change stream consumer 連線

Connector metric（Kafka Connect JMX）：source-record-poll-rate、source-record-write-rate、offset-commit-success-rate。

回到 4.20 observability evidence：oplog retention + connector lag + dedup rate 是 CDC pipeline 健康狀態 evidence 三件套。

回到 9.5 bottleneck localization：CDC lag 升高時區分 (a) source oplog 寫太快 (b) connector 處理慢 (c) downstream sink 慢。

邊界與整合

Sibling deep articles：

• shard key selection — cluster-wide vs collection-level change stream 在 sharded cluster 的選擇
• replica set read preference — change stream 對 primary load 的影響、能否走 secondary
• schema design pattern — schema validator 對下游 sink 的契約意義
• connection management and cache layer — CDC sink 在 production 跨層架構裡的角色（cache invalidation / federated DB 同步）

Migration playbook：

• MongoDB → 其他 sink 的 bulk migration 走 → Atlas Migration Service
• 遷出 MongoDB 時 change stream 是 catch-up 機制（先 bulk export、再 change stream 補增量）

跟 1.x 互引：1.7 schema migration rollout evidence 處理 schema drift 時 CDC pipeline 的對賬；1.9 reconciliation data repair 處理 CDC 失準後的對賬流程。

相關連結

• MongoDB vendor overview — 本文是該頁尾「change streams + Kafka」backlog 的深度展開
• Vendor 深度技術文章方法論
• 官方：Change Streams、MongoDB Kafka Connector、Oplog

本文承接 終端機圖形化工具總覽 的訊息佇列客戶端分類。broker 端的純指令操作與 vendor 選型見 Kafka、Redis Streams、RabbitMQ 服務頁。

跟 SQL 客戶端最大的不同：多半綁單一 broker 協議

訊息佇列 TUI 幾乎都綁定單一 broker 協議，這是選型要先認清的一點，也跟 SQL 客戶端剛好相反。SQL 客戶端 一個工具靠 adapter 連 Postgres、MySQL、SQLite 多種資料庫；訊息佇列這邊，Kafka 的 TUI 說的是 Kafka protocol、不認 AMQP，RabbitMQ 的 TUI 走 management API、也不讀 Kafka topic。能同時連多種 broker 的工具是少數例外（見後文 queuepeek）。

所以選型順序是先定 broker、再挑該 broker 生態的工具。實機盤點下來，Kafka 的 TUI 生態最成熟（多個活躍專案、安裝管道齊全），Redis 有強的增強型 REPL，RabbitMQ 與跨 broker 工具仍在早期。

兩種範式：全螢幕 TUI 與增強型 REPL

訊息佇列客戶端沿用跟 SQL 客戶端同一組範式區分。全螢幕 TUI（kaskade / yozefu / ktea）把 topic 清單、訊息內容、consumer 狀態排進多個面板，鍵盤導航瀏覽；增強型 REPL（iredis）仍是一行行打指令，但加上補全、語法高亮與型別感知輸出，是原生 client 的升級版。

選哪種看工作型態：要在多個 topic 間翻訊息、看 partition 與 consumer group 全貌，用全螢幕 TUI；要快速接上跑幾條指令、或塞進腳本，用增強型 REPL。

Kafka 全螢幕 TUI：kaskade、yozefu、ktea

Kafka 有三個定位不同的全螢幕 TUI，互動模型與連線設定各異。

kaskade（Python、Textual 寫，實測 4.0.7）分 admin 與 consumer 兩個子命令，連線參數走 -b。kaskade admin -b localhost:9092 進管理模式，實測連上 broker 後渲染出 topics 面板，欄位是 name、partitions、replicas、in sync、groups、members、records，一頁看完叢集的 topic 全貌。kaskade consumer -b localhost:9092 -t orders --from-beginning 進消費模式翻單一 topic 的訊息，-v json 與 -v registry 切 payload 解碼方式，後者配 --registry url=http://localhost:8081 接 Schema Registry。SSL / SASL 不走 -b，要用 --config security.protocol=SSL 逐項帶或 --config-file kafka.properties 餵設定檔。

yozefu（Rust 寫、binary 名是 yozf，MAIF 維護）主打跨 topic 的搜尋查詢，把找特定 record 當成核心場景。它的查詢語言是 SQL 風的，預設 initial_query 是 from end - 10（從尾端往回取 10 筆），search filter 還能用 WebAssembly 自訂（create-filter / import-filter 子命令）。連線走 config 模型而非純 flag：yozf config 會印出設定（檔案在 ~/Library/Application Support/io.maif.yozefu/config.json），每個 cluster 在裡面定義 bootstrap.servers、security.protocol 與 schema registry，再用 yozf -c <cluster> -t <topics> 指定要連哪個。

ktea（Go 寫，Homebrew 0.8.0）同樣是 config-based，cluster 連線設定走首次啟動的互動流程而非命令列旗標。啟動旗標有 -debug 與 -plain-fonts，後者在終端機沒裝 NerdFonts、圖示顯示成亂碼時關掉圖示。本機裝起來、啟動旗標確認過，cluster 連線與深層瀏覽走互動設定流程、未逐步驗證。

判讀：要一頁看完 topic / consumer group 狀態、或邊看邊消費，選 kaskade；要在大量 topic 裡用查詢撈特定 record，選 yozefu 的搜尋模型；ktea 是另一個 Go 單 binary 選擇、偏好互動式設定 cluster 的可評估。

增強型 REPL：iredis（Redis 與 Redis Streams）

iredis（Python 寫，實測 1.16.1）是 redis-cli 的增強版，補上指令補全、語法高亮與型別感知輸出，手感仍是 REPL。它跟 dbcli 家族的 pgcli / litecli 同一類定位。實測非互動可跑，把指令用管線餵進去就回結果：echo "DBSIZE" | iredis -h localhost -p 6390，適合塞腳本。

它對 Redis Streams（03 的 vendor 之一）的檢視特別省事。peek <key> 會先看型別再自動取值，string 顯示 strlen 與內容、stream 走 XINFO；實測對一個 stream 跑 XINFO STREAM 直接回 length、last-generated-id 等欄位，不必先 TYPE 再決定下哪個讀取指令。它是通用 Redis client、不是 stream 專用工具，但 Redis Streams 的 consumer group 操作（XPENDING、XCLAIM、XINFO GROUPS）都在這套指令補全範圍內。

RabbitMQ 與跨 broker：生態仍在早期

RabbitMQ 與「一個工具連多種 broker」這兩塊目前缺乏可直接安裝驗證的成熟工具，列出供參考、本機未實機驗證。

RabbitMQ 的 TUI 候選有 rabbitui（走 RabbitMQ management API）與 rabbithole（帶 exchange / binding 的 topology browser、支援 Protobuf 解碼）。兩者都不在 Homebrew 與 crates.io 的發佈管道，本機未安裝驗證。在缺 TUI 的情況下，RabbitMQ 的互動瀏覽仍以內建的 Management UI（web，預設 15672 埠）為主，純終端機則回到 rabbitmqctl 與 rabbitmqadmin。

跨 broker 的 queuepeek（Rust 寫，宣稱同時連 RabbitMQ、Kafka、MQTT）對應 SQL 類裡 usql 的「一個工具連多種後端」定位。本機 cargo install queuepeek 在編譯 rdkafka-sys（綁定原生 librdkafka）階段失敗、未能驗證。

gotcha（實測）

• yozefu 預設帶一個名為 localhost 的 cluster、指向 localhost:9092。連非預設 port（例如本機測試的 9093）要先 yozf configure 改掉 bootstrap.servers，直接用 flag 覆寫不會生效。
• kaskade 的 -b 只接 bootstrap server；SSL / SASL 等安全設定一律走 --config key=value 或 --config-file，混在 -b 裡會被當成 broker 位址。
• ktea 的 -plain-fonts：終端機沒裝 NerdFonts 時圖示會顯示成亂碼方塊，加這個旗標關掉圖示就恢復可讀。

同類其他選擇

Redis 的全螢幕 TUI（如 redis-tui）與其他 Kafka TUI（如 kafka-tui）未在本輪實機驗證、列出供參考。Kafka TUI 這塊專案數量較多，挑選時以發佈管道（Homebrew / pip / crates.io 直接可裝）與維護活躍度篩選，不追求窮舉。

下一步路由

• broker 端純指令工具與 vendor 選型：Kafka、Redis Streams、RabbitMQ 服務頁。
• 同範式的資料庫客戶端對照：終端機 SQL 客戶端。
• 把客戶端擺進可持久化的多工器 pane：tmux 基礎。
• 訊息佇列客戶端在遠端工具分類中的定位：終端機圖形化工具總覽。