觀察

FOQS 從區域安裝轉為全域架構，目標是讓災害期間佇列資料仍可被存取，並控制遷移期間的延遲與可用性風險。

判讀

當 queue 成為跨區關鍵路徑，轉換焦點是 discoverability、routing freshness 與 tenant 遷移節奏。

策略

1. 先建立全域路由層，再分批搬遷租戶。
2. 針對 stale routing 做補貨延遲治理。
3. 用零停機遷移策略保留客戶端連續性。

下一步路由

回 3.1 broker basics 與 3.2 durable queue。

引用源

• FOQS disaster-ready migration

對「任務隊列、worker pool、複雜 routing、RPC over messaging」這條路徑、RabbitMQ 是業界主流。本頁先給最短路徑、再展開日常 publisher / consumer 操作與 exchange 設計、最後進階治理（quorum queue、cluster、federation）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 docker 跑起 RabbitMQ + management UI、驗證 broker 健康
2. 用 CLI / Management API 建 exchange、queue、binding
3. 設計 exchange type（direct / fanout / topic / headers）對齊路由需求
4. 看懂 queue depth、unacked、connection / channel 數量訊號、定位故障層
5. 評估 quorum queue、stream、federation、shovel 等規模化議題

最短路徑：5 分鐘把 RabbitMQ 跑起來

 1# 1. 啟動 RabbitMQ + management plugin
 2docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management
 3
 4# 2. 建 exchange / queue / binding（rabbitmqadmin 可重現、Management UI 在 http://localhost:15672、預設 guest/guest）
 5docker exec rabbitmq rabbitmqadmin declare exchange name=demo.direct type=direct
 6docker exec rabbitmq rabbitmqadmin declare queue name=demo.q
 7docker exec rabbitmq rabbitmqadmin declare binding source=demo.direct destination=demo.q routing_key=demo
 8
 9# 3. 用 rabbitmqctl 驗證 broker 狀態
10docker exec rabbitmq rabbitmqctl list_queues
11docker exec rabbitmq rabbitmqctl list_exchanges
12docker exec rabbitmq rabbitmqctl list_bindings

最短路徑驗證「broker 起來、UI 能訪、能 enqueue/dequeue」。實際寫程式用 AMQP client、見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• CLI 指令對照表（rabbitmqctl / rabbitmq-diagnostics / rabbitmqadmin）
• Management API 形狀（HTTP API、適合自動化）
• AMQP client 配置：connection / channel / consumer prefetch / publisher confirm
• 對應指令範例：rabbitmqctl list_queues name messages messages_unacknowledged consumers

Exchange types 與 routing 設計

Exchange 承擔訊息分流責任、不同 type 對應不同路由語意。子議題：

• Direct：精準 routing key 匹配（point-to-point）
• Fanout：忽略 routing key、廣播到所有 binding queue
• Topic：層級式 routing key（* 單層、# 多層萬用字元）
• Headers：依 message header 路由（少用）
• 對應指令：宣告 exchange / queue / binding 的 CLI 與 client 範例

Queue 設計與 ack/nack 策略

Ack/nack 是 RabbitMQ 的 delivery 控制點。子議題：

• Durable queue vs transient queue
• Manual ack vs auto ack（後者等同 at-most-once）
• Prefetch 設定（backpressure + 併發控制）
• Dead-letter exchange（DLX）配置
• Message TTL 與 queue length limit

進階主題（按需閱讀）

本段主題已展開為 deep article：classic vs quorum vs stream 選型、network partition 與 cluster 一致性、DLQ retry escalation。下列子議題段保留選題判讀入口。

Classic queue vs Quorum queue vs Stream

子議題：

• Classic queue：原生持久化 queue、mirrored queue 已 deprecated
• Quorum queue：Raft-based、取代 mirrored、跨節點一致性
• Stream（3.9+）：append-only log、log-based 模型、類似 Kafka 但仍是 RabbitMQ 體系
• 三種模型的選擇判讀（throughput、retention、replay 需求）

Federation 與 Shovel

子議題：

• Federation：upstream / downstream broker 鏈接、適合鬆耦合跨資料中心
• Shovel：點對點轉發、適合單純訊息搬運
• 跨區 / 多 cluster 場景的選擇

Erlang clustering 與 network partition

子議題：

• Cluster 拓樸（disc node、ram node）
• cluster_partition_handling 策略（ignore、autoheal、pause_minority）
• 腦裂偵測與處理

多 vhost / 多租戶

子議題：

• Vhost 隔離（namespace、ACL、user permission）
• User / Role / Permission 設計
• Per-vhost resource limit（max connection、max queue）

Prefetch 與 consumer 併發控制

子議題：

• Prefetch count 對 throughput / fairness 的影響
• Channel-level vs Consumer-level prefetch
• 配合 retry budget 控制重試壓力

RabbitMQ Cluster Operator（K8s）

子議題：

• Cluster Operator vs 自管 StatefulSet
• 持久化卷（PVC）與資料保護
• 升級流程（rolling restart 與資料完整性）

Plugin 機制與多協議

子議題：

• MQTT plugin（IoT 場景、橋接 device-to-broker）
• STOMP plugin
• 對應 3.1 broker basics 的 QoS / ACK 機制橋接

排錯快速判讀

Queue 堆積（messages 增加、unacked 不收斂）

操作原則：先看 consumer 是否存在、再看 ack 速率 vs publish 速率、最後看 prefetch / poison message。

1rabbitmqctl list_queues name messages messages_unacknowledged consumers

判讀路徑：無 consumer（client crash）→ consumer 慢（下游卡）→ poison message 卡住（看單一 message redelivery 次數）。

Connection / Channel limit

操作原則：client 設計不當會用滿 connection / channel，看每個 connection 的 channel 數。

1rabbitmqctl list_connections
2rabbitmqctl list_channels

Disk alarm 觸發

操作原則：disk 低於 disk_free_limit、broker 暫停 publisher。判讀：保留期太長 / 訊息大小 / 未消費 queue 過大。

Memory alarm 觸發

操作原則：記憶體超過 watermark、broker 觸發 paging、publisher 變慢。判讀路徑：訊息累積、consumer 失聯、queue 設定錯誤。

Network partition（腦裂）

操作原則：cluster 節點互相不可達、看 cluster_partition_handling 與 partition log。對應 3.C9 語義誤配 思路。

何時改走其他服務

不在本頁內的主題

• 各語言 AMQP client 完整 API（依官方文件）
• 所有 plugin 細節（只列主流 plugin）
• RabbitMQ Streams 跟 Kafka 的詳細對照（見 Kafka vendor 頁）

案例回寫

RabbitMQ 專屬案例（C23-C33）

跨 vendor 對照

MQTT plugin + Cluster Operator 缺直接 customer case：可補 RabbitMQ 官方 native MQTT blog 跟 K8s Operator docs、後續若有 customer 案例可加。

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：Kafka、NATS
• 下游能力：3.2 durable queue、3.4 consumer 設計

訊息代理（broker）的核心責任是解耦 producer 與 consumer，讓非同步工作具備可排隊、可重試、可隔離的傳遞路徑。它定位在傳遞與協調層。

broker 跟 protocol 是兩個獨立的軸

Broker 是訊息分發的具體實作產品（RabbitMQ、Kafka、NATS、EMQX）、protocol 是訊息交換的線路規格（AMQP、MQTT、STOMP、Kafka wire protocol）。兩個軸獨立、形成多對多關係：

• 一個 broker 可實作多個 protocol：RabbitMQ 主走 AMQP、透過 plugin 也支援 MQTT 跟 STOMP；NATS 主走自家 protocol、JetStream 額外提供 KV 與 Object Store API
• 一個 protocol 可被多個 broker 實作：MQTT 由 EMQX / HiveMQ / Mosquitto / RabbitMQ MQTT plugin 各自實作；AMQP 主要是 RabbitMQ 跟 Apache Qpid

選型討論時要分清「我需要的是 protocol（如 device 端要 MQTT 因為輕量 / IoT 標準）」還是「broker 產品（如 RabbitMQ vs EMQX 的運維 / 生態取捨）」。當 protocol 跟 broker 都需要、會出現 protocol 橋接場景 — 例：device 端透過 MQTT 連 RabbitMQ MQTT plugin、broker 內部把 MQTT topic 自動映射成 AMQP routing key、AMQP-side consumer 用 routing key 訂閱。

這層分離也影響故障判讀：device 連不上是 protocol 層問題、broker 之間 routing 錯是 broker 內部 plugin / mapping 問題、consumer 收不到是 AMQP binding 問題 — 三層各自獨立、不能混為一談。

broker、queue、consumer 的分工

broker 管理訊息儲存、分發與確認流程；queue 或 topic 承載傳遞單位；consumer 承擔業務處理。分工清楚後，故障判讀才能定位在正確層級：投遞故障、消費故障或下游依賴故障。

producer 發送成功只代表 broker 已接收（publisher confirm），不代表業務結果完成。業務完成需要 consumer 提交副作用並確認進度。

push 與 pull 模型

push 模型由 broker 主動推送訊息，適合低延遲場景；pull 模型由 consumer 主動拉取，適合吞吐控制與批次處理。實務上常結合使用：broker 管理可見性與重試，consumer 控制節流與併發。

模型選擇重點是背壓控制。當下游變慢時，系統是否能限制消費速率並保留恢復空間，是穩定性的關鍵。

傳遞語意（delivery semantics）

三種常見 delivery semantics：

1. at-most-once：可能丟失，不重送，低延遲低成本。
2. at-least-once：可能重複，需冪等保護，最常見實務語意。
3. exactly-once：語意成本高，通常在特定邊界內成立，需要嚴格協議與系統支持。

實務上多數後端系統採 at-least-once，再用 consumer 去重與補償達到業務可接受結果。

ack / nack 流程

ack/nack 是 delivery 控制點。ack 代表該訊息可從待處理集合移除；nack 代表稍後重試或分流。ack 時機過早會造成資料遺失，過晚會造成重複處理與堆積。

穩定流程是：完成核心副作用後再 ack，暫時故障走受控重試，持續故障走 DLQ 隔離。

語意保證的不同實作機制

同一層 delivery semantics、不同 broker 用不同協議機制達成。讀懂 broker 行為的關鍵、是辨認「at-least-once」這個語意承諾、底下是哪種具體機制負責 — 故障訊號跟操作旋鈕跟著不同。

三種常見實作機制：

三個機制的工程含義不同。QoS handshake 把可靠性責任拉到 wire protocol 層、適合 device-to-broker 場景但 broker-to-consumer 還要另外處理；broker ACK 把責任放在 consumer 處理完才確認、適合「處理即承諾」的任務隊列；replication 把責任放在訊息已被多份保存、適合「寫入即承諾」的事件流。

機制差異的故障訊號

機制決定故障表現。同樣是「訊息重複投遞」、不同機制要看不同訊號：

• QoS handshake：QoS 1 重傳是設計、QoS 2 重傳代表握手失敗 — 看 broker 端的 PUBREL / PUBCOMP 完成率
• Broker ACK：ack timeout 觸發 redelivery 是設計、頻繁 redelivery 代表 consumer 處理慢或下游卡 — 看 consumer 處理時間 vs ack timeout、視訊號為 backpressure
• Replication：producer retry 觸發 duplicate 是設計、ISR shrink 代表 broker 副本不穩 — 看 ISR 狀態 vs producer acks 設定

機制差異的操作旋鈕

挑 broker 等同於挑「可調的旋鈕集合」。把「業務需要的語意」轉成「實際要調的旋鈕」、是 broker 選型落地的關鍵步驟：

• 想保證「不丟」用 MQTT：QoS 等級提到 2、開 session persistence
• 想保證「不丟」用 RabbitMQ：consumer 走 manual ack、配 DLQ、設 prefetch 限併發
• 想保證「不丟」用 Kafka：producer acks=all、min.insync.replicas ≥ 2、consumer commit-after-process

機制不同、可調旋鈕不同、operator 要熟悉的訊號也不同。這是「broker 系統複雜度」的真實來源 — 不是「broker 難安裝」、而是「broker 旋鈕集合的學習與調校曲線」。

判讀訊號

常見誤區

把 broker 當成保證業務正確性的元件，會把消費責任與補償責任遺漏。broker 保證傳遞語意，業務正確性要由 consumer 設計承擔。

把 exactly-once 當成預設目標，也容易過度設計。先定義可接受失敗代價，再選擇對應語意，通常更符合實務。

Broker 規模化的角色變化

Broker 在規模化服務承擔的責任從「單隊列工具」轉到「平台治理問題」— 容量規劃焦點從擴 broker 變成多租戶隔離、配額管理、跨團隊觀測標準化。

對應 3.C6 Uber Kafka Infrastructure Evolution — Uber 事件平台服務眾多團隊、focus 從 broker 容量是否充足轉到 team 之間的隔離邊界。對應 3.C4 LinkedIn Tiered Clusters — 規模化必然分層 cluster、按業務特性跟可靠性需求分配不同叢集、高優先 workload 跟低優先 workload 各自獨立。

規模化的三個角色階段（依據 3.C6 / 3.C4 / 早期服務對照、整理出三個典型階段）：

• 單隊列工具（規模尚小階段）：一個 Kafka cluster、所有 service 共用、broker 擴容是主要工作、團隊各自管理自己的 topic
• 多租戶平台（中大型階段）：跨團隊共用 cluster、平台 team 設定 quota、topic 命名規範、容量配額、觀測標準。3.C6 描述 Uber 在這階段「標準化 topic 治理與故障處理流程」、把跨團隊運維責任收斂到平台層
• 分層治理平台（規模化階段）：不同業務特性走不同 cluster（critical / standard / experimental）、跨 cluster 路由跟治理變主要工作。3.C4 描述 LinkedIn「依流量與可靠性需求分層」、高優先 workload 提供獨立保護

判讀含義：當 broker incident 影響多個 team 不相關業務、屬於該分層的訊號。規模化後焦點要轉向跨 team 隔離跟跨 cluster 治理、單純擴 broker 處理不了多租戶共擠的結構性問題。攻擊面跟控制面見 3.5 紅隊章 Multi-tenant broker 隔離邊界。

Queue 變跨區關鍵路徑的特殊挑戰

當 queue 變成跨區關鍵路徑（payment、order、notification 都靠它）、容量規劃焦點從 throughput 變成 discoverability 跟 routing freshness。

對應 3.C1 Meta FOQS — FOQS 從區域升級到全域、目標是讓災害期間 queue 仍可被存取、控制遷移期間的延遲跟可用性風險。Focus 從 queue 吞吐量轉到災害時的 broker 可達性、routing 狀態新鮮度、tenant 遷移節奏。

跨區 queue 的設計挑戰：

• Discoverability：client 在 region failover 後需透過 service discovery + DNS / health check 動態解析 broker endpoint、找到新 primary broker
• Routing freshness：broker topology 變更後、client 多久能拿到新 routing 表、stale routing 期間 message 流向錯 broker、要設定 routing TTL + 主動 refresh
• Tenant 遷移節奏：規模化跨區 queue 採分批 cutover、保留 client 連續性
• Stale routing 補貨延遲治理：routing 過時造成 message 累積在錯誤 broker、要設定 timeout + 重新發現機制、讓 client 重新發現新 broker 並切換到健康路徑

案例回寫

投遞語意可用 3.C9 反例 做回寫。先判讀事件是 delivery 層失配，還是 processing/recovery 層失配，再回到本章檢查 ack 時機、重試節奏與隔離策略是否清楚。 這個案例主要支撐的是「語意分層與投遞責任」判讀，不直接支撐資料庫 schema 演進或 LB timeout；若問題在資料模型或連線生命週期，應轉到 1.2 或 5.3。

若投遞成功但業務結果缺漏，先補齊語意分層，再分別回寫 3.2 durable queue 與 3.4 consumer 設計。

跨模組路由

1. 與 3.2 的交接：持久化與重試節奏回到 durable queue 與重試策略。
2. 與 3.4 的交接：消費恢復與去重回到 consumer 設計與去重。
3. 與 4.20 的交接：投遞與消費訊號納入 Observability Evidence Package。
4. 與 6.12 的交接：重播與冪等驗證回到 Idempotency 與 Replay 驗證。

下一步路由

要進一步處理持久化與重試控制，接著讀 3.2 durable queue 與重試策略。要處理交易與發佈一致性，接著讀 3.3 outbox pattern 與發佈一致性。

觀察

CloudHealth 由自管 Kafka 遷移到 Amazon MSK，過程涵蓋 topic、存取控制、觀測與遷移執行節奏。

判讀

這類轉換的實際風險在 ACL、topic policy、client 相容性與 cutover 節奏，服務名稱本身反而是次要問題。

策略

1. 先建立新叢集治理基線（ACL、觀測、部署）。
2. 分批 topic 遷移並持續監測 lag/錯誤。
3. 把回退與流量切換條件寫成明確門檻。

下一步路由

回 3.1 broker basics 與 6.8 release gate。

引用源

• VMware CloudHealth Kafka to MSK

對「事件驅動架構、CDC、跨系統事件分發、長期保留 + replay」這條路徑、Kafka 是業界事實標準。本頁先給最短路徑、再展開日常 producer / consumer 操作與 topic 設計、最後進階治理（多租戶、跨區、自動修復）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 docker-compose 跑起 Kafka + KRaft、驗證 broker 健康
2. 用 CLI 建 topic、produce / consume 訊息、看 partition 分布
3. 設計 producer acks / idempotence / consumer commit 策略對齊 delivery semantics
4. 看懂 consumer lag、ISR shrink、rebalance 訊號、定位故障層
5. 評估 multi-tenant、cross-region、tiered storage、self-healing 等規模化議題

最短路徑：5 分鐘把 Kafka 跑起來

最短路徑用 KRaft 模式（取代 ZooKeeper、單節點即可跑）、避免初學者卡在 ZK 安裝。

 1# 1. 啟動 Kafka（apache/kafka 內建 KRaft、單一容器即含 broker + controller）
 2docker run -d --name kafka -p 9092:9092 apache/kafka:latest
 3
 4# 2. 建 topic（CLI 在容器內 /opt/kafka/bin/）
 5docker exec kafka /opt/kafka/bin/kafka-topics.sh --create --topic demo --partitions 3 \
 6  --bootstrap-server localhost:9092
 7docker exec kafka /opt/kafka/bin/kafka-topics.sh --describe --topic demo \
 8  --bootstrap-server localhost:9092
 9
10# 3. 驗證 produce / consume
11docker exec kafka bash -c "echo hello | /opt/kafka/bin/kafka-console-producer.sh \
12  --topic demo --bootstrap-server localhost:9092"
13docker exec kafka /opt/kafka/bin/kafka-console-consumer.sh --topic demo \
14  --from-beginning --max-messages 1 --bootstrap-server localhost:9092

最短路徑只驗證「broker 起來、能寫能讀」。實際寫程式用 producer / consumer client、見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• CLI 指令對照表（kafka-topics / kafka-configs / kafka-consumer-groups / kafka-acls）
• Producer client 配置：acks / batch.size / linger.ms / compression / enable.idempotence
• Consumer client 配置：auto.offset.reset / enable.auto.commit / max.poll.records / max.poll.interval.ms
• 對應指令範例：kafka-topics.sh --describe、kafka-consumer-groups.sh --describe --group <id>

Topic 設計

Topic 承擔事件的邏輯邊界。子議題：

• Partition 數規劃（並行度 vs metadata 成本）
• Replication factor 與 min.insync.replicas（資料保護等級）
• Retention policy（time-based vs size-based、compact vs delete）
• Key 策略（ordering 範圍、hot partition 避免）

Producer 與 Consumer 設計

設計決定 delivery semantics 實際達成。子議題：

• Producer：acks=0/1/all 對應的可靠性取捨、idempotence、transaction 邊界
• Consumer：commit 策略（auto vs manual）、commit 時機與 at-least-once / at-most-once 對應
• Consumer group：rebalance protocol（eager vs cooperative）、static membership
• 對應指令：producer 配置範例、consumer 配置範例、kafka-consumer-groups.sh --describe

進階主題（按需閱讀）

本段主題多數已展開為 deep article：consumer rebalance 與 lag 診斷、replication / ISR / exactly-once、retention 與 tiered storage、Schema Registry 與 schema 演進、multi-tenant quota 與 ACL 治理。下列子議題段保留每個主題的選題判讀入口。

Multi-tenant 與配額治理

對應案例 3.C6 Uber Kafka 事件平台。子議題：

• Producer / Consumer quota（byte rate、request rate）
• ACL 設計（principal、resource、operation）
• Topic 命名規範與 ownership
• 對應指令：kafka-configs.sh --alter --add-config 'producer_byte_rate=...'、kafka-acls.sh --add

Cross-region 與分層叢集

對應案例 3.C1 Meta FOQS 與 3.C4 LinkedIn Tiered Clusters。子議題：

• MirrorMaker 2 配置（active-active vs active-passive）
• 分層叢集策略（critical / standard / experimental）
• 跨區 consumer 路徑與 routing freshness

Topic 生命週期治理

對應案例 3.C3 LinkedIn TopicGC。子議題：

• Topic 活躍判準（last produce / consume timestamp）
• 自動回收條件與稽核
• Metadata 壓力訊號（controller log、partition 數量上限）

Replication 與 exactly-once 升級

對應案例 3.C9 反例：語義誤配。子議題：

• acks=all + min.insync.replicas ≥ 2 + producer idempotence
• Kafka transaction 與 read_committed 邊界
• 端到端 exactly-once（Kafka Streams 場景）

Self-healing 與自動修復

對應案例 3.C7 LinkedIn Self-Healing。子議題：

• 可自動修復故障類型（disk full、broker offline、under-replicated partition）
• 自動修復 vs 人工升級邊界
• 修復過程的證據鏈納入觀測

KRaft 與 Schema Registry

子議題：

• KRaft mode 取代 ZooKeeper（運維簡化、metadata 治理）
• Schema Registry（Confluent / Apicurio）與 Avro / Protobuf
• Schema 演進策略（forward / backward / full compatibility）

Tiered storage

子議題：

• 冷熱分層（hot tier on local disk、cold tier on S3）
• Retention 設計與成本
• Read 路徑差異（hot vs cold）

Kafka Connect 與 CDC

子議題：

• Source connector / Sink connector 模型
• Debezium CDC pipeline 與 outbox 整合
• Connect cluster 治理與 schema evolution

排錯快速判讀

Consumer lag 暴增

操作原則：先看 lag 是「均勻分布」還是「集中在少數 partition」、再定位 consumer 慢 vs partition 不平衡。

1kafka-consumer-groups.sh --describe --group <id> --bootstrap-server localhost:9092
2# 輸出含 CURRENT-OFFSET / LOG-END-OFFSET / LAG 逐 partition 列、可看 lag 集中在哪幾個 partition

判讀路徑：consumer 慢（CPU / GC / 下游 I/O）→ producer 突增 → partition 不平衡（key 分布）。

ISR shrink 與 under-replicated partition

操作原則：ISR 縮小代表 follower 跟不上 leader、看 broker 健康 / 網路 / disk。

1kafka-topics.sh --describe --under-replicated-partitions --bootstrap-server localhost:9092
2# 輸出為空代表所有 partition 同步正常；列出的 partition 即 ISR 落後者

Rebalance storm

操作原則：consumer 頻繁加入 / 離開觸發 rebalance、看 session.timeout.ms 與 max.poll.interval.ms。

Offset reset 或重複消費

對應反例 3.C9。判讀路徑：commit 策略錯誤、broker 端 offset 過期、auto.offset.reset = earliest。

Schema 不相容

操作原則：producer 升級 schema、consumer 未升、看 compatibility level。

何時改走其他服務

不在本頁內的主題

• 各語言 client API reference（依官方文件）
• Kafka Streams / ksqlDB（另開 stream processing 章節）
• Confluent 商業功能（Confluent Cloud、Control Center）

案例回寫

既有通用案例（C1-C10）

Kafka 專屬案例（C11-C22）

KRaft 缺直接 customer case：目前依官方 KIP-833 / Confluent 公告為準、後續若有 customer 一手案例可補。

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：RabbitMQ、NATS
• 下游能力：3.4 consumer 設計、6.12 idempotency / replay

durable 與 ephemeral 的差異

queue 在語意上可分 durable 與 ephemeral。ephemeral queue 側重低延遲與短暫協調，適合可丟失任務；durable queue 側重故障後可恢復，適合正式狀態相關副作用，例如付款通知、發票產生、庫存同步與合規事件記錄。

這個選擇本質上是失敗代價選擇。若任務丟失可接受，ephemeral 可降低成本；若任務丟失會造成金流、合約或審計問題，durable 是必要基線。

重試策略

重試策略的責任是把暫時性故障和系統性故障分開。durable queue 常見的重試組合是：有限次重試、指數退避、jitter 分散峰值、超過門檻後分流到 dead-letter queue。

重試上限與間隔要由下游承載能力決定。重試太快會形成故障放大，重試太慢會拖長恢復時間。穩定做法是把重試策略當成服務容量控制的一部分，而不是固定平台預設值。

DLQ 與 requeue 風險

DLQ 的責任是隔離異常訊息，避免拖垮主消費流程。DLQ 是診斷與修復入口，把它當終點會讓問題沉積。每個進入 DLQ 的訊息，都應能回答：失敗原因是 payload 錯誤、下游不可用、版本不相容，還是消費邏輯缺陷。

requeue 需要明確條件。直接把異常訊息無限 requeue，通常會造成隊列震盪與延遲累積。穩定做法是先隔離、分群、修復，再批次回放。

ordering 與吞吐取捨

durable queue 在順序與吞吐之間需要明確取捨。全域順序通常成本極高，實務上多採用分區內順序：同一 key 保持順序，不同 key 可並行。這能兼顧一致性需求與處理吞吐。

順序要求越高，恢復流程越需要明確 checkpoint 與補償策略。否則故障後的重播容易造成亂序副作用，放大修復成本。

判讀訊號

常見誤區

把 durable queue 視為「寫進去就安全」，會忽略消費與恢復責任。持久化只保證訊息可取回，不保證業務結果已正確提交。

把 DLQ 當成長期倉庫，也會讓問題持續累積。DLQ 的工程價值在於快速定位異常類型並回到修復流程。

訊息系統的「通知 vs 訊息」分類

訊息系統設計區分兩種 SLO 不同的傳遞責任：transactional 通知 承擔業務副作用的可靠送達、broadcast 訊息 承擔大量低成本傳播。兩者用不同 storage、不同重試策略、不同投遞保證。

對應 9.C26 PayPay — 行動支付每日 3 億訊息、付款通知承擔「確認交易完成」的業務責任、SLO 包含秒級延遲跟高投遞率（用戶付完款後若 30 秒沒收到通知會打客服、產生重複扣款風險）。這層需求嚴於 OTA 推播、需要 durable queue + retry + 重複偵測。

分類設計：

• Transactional 通知（付款收據、訂單狀態變更、配額警告）：承擔業務副作用確認、需 durable + idempotency key 去重、SLO 通常是 秒級延遲 + 99.99% 投遞率
• Broadcast 訊息（行銷推播、新片發布通知、社群動態）：承擔大量低成本傳播、SLO 是 吞吐量 跟覆蓋率、允許 best-effort retry

判讀含義：規模化訊息系統的容量規劃要按類別分開、避免套同一個 broker capacity。3 億訊息 / 天看似一致、但 通知 跟 訊息 的工程負擔差數量級。

下游推送是隱性瓶頸

訊息系統的真正瓶頸常落在 下游推送通道（APNs、FCM、SMS gateway、email provider）、不在 broker。下游 quota 是 hard ceiling、超過會被 throttle、訊息積壓回 broker 形成 backlog。

對應 9.C26 PayPay — DynamoDB 寫入可以撐 3K msg/sec 平均（PayPay 本身用 DynamoDB 作訊息後端、不是傳統 broker）、但 APNs 推送額度成為事故當下的隱性瓶頸。容量規劃要把下游 quota 算進去、不只看訊息後端吞吐。

設計含義：

• 下游 quota 視為容量上限：APNs / FCM / SMS 的 daily quota 是 hard ceiling、訊息後端規劃要對應
• 下游通道多元化：用 APNs / FCM / SMS / in-app notification 多通道分攤 quota 壓力、單通道飽和時其他通道仍可送出（具體降級策略需依各組織業務規則設計）
• 重試節奏跟下游容量對齊：consumer 重試節奏依下游剩餘 quota 動態調整、讓重試節奏跟容量同步

判讀重點：訊息系統事故當下、先看下游推送通道狀態（APNs status、FCM error rate）、再看訊息後端。下游 throttle 引發 backlog 是規模化訊息系統最常見的瓶頸來源。下游推送 quota 的攻擊面對照見 3.5 multi-tenant broker 配額耗盡。

案例回寫

durable queue 的重試與隔離節奏可用 3.C9 反例 回寫。先看事件中的 backlog、retry、DLQ 變化，再回到本章判讀是重試策略失衡，還是隔離邊界不清楚。 這個案例主要支撐的是「重試隔離與停損門檻」判讀，不直接支撐 outbox 交易切分；若事件核心是資料提交與發布不一致，應轉到 3.3 與 1.3。

當重試量上升且主隊列延遲同步拉高時，先拆分重試通道並收斂 DLQ 分流條件，再把停損門檻接到 6.24 規則推送安全閘門。

跨模組路由

durable queue 是非同步可靠性的起點，不是終點。

1. 與 3.4 的交接：消費與恢復語意落在 consumer 設計與去重。
2. 與 3.3 的交接：發布一致性落在 outbox pattern。
3. 與 4.20 的交接：queue depth、retry、DLQ 指標進入 Observability Evidence Package。
4. 與 6.12 的交接：重試與重播驗證進入 Idempotency 與 Replay 驗證。
5. 與 8.19 的交接：故障隔離與回放決策進入 Incident Decision Log。

下一步路由

要從投遞語意往消費語意延伸，接著讀 3.4 consumer 設計與去重。要看 queue 切換失敗模式，接著讀 3.C9 反例。

觀察

LinkedIn 以 TopicGC 清理未使用 topic，降低 Kafka metadata 壓力並改善 produce/consume 效能。

判讀

當 queue 規模擴大，僅靠容量擴充不夠，topic 生命週期與治理自動化會成為可靠性關鍵。

策略

1. 定義 topic 活躍判準與回收條件。
2. 自動化清理流程並保留稽核紀錄。
3. 監控清理前後的性能與穩定性指標。

下一步路由

回 3.4 consumer design 與 6.14 dependency reliability budget。

引用源

• TopicGC at LinkedIn

對「微服務 messaging、IoT/edge、Request/Reply、需要 messaging + KV 一體」這條路徑、NATS 是輕量首選。本頁先給最短路徑、再展開日常 publish / subscribe 與 subject 設計、最後進階治理（JetStream、supercluster、leaf node）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 nats-server 跑起 NATS（含 JetStream）、驗證 broker 健康
2. 用 nats CLI publish / subscribe、看 subject hierarchy 匹配
3. 區分 Core NATS（fire-and-forget）vs JetStream（durable）的選用判讀
4. 看懂 stream 配置、consumer 配置、pending 訊號
5. 評估 supercluster、leaf node、KV / Object Store 等延伸場景

最短路徑：5 分鐘把 NATS 跑起來

 1# 1. 啟動 NATS server（-js 開 JetStream、-m 8222 開監控埠）
 2docker run -d --name nats -p 4222:4222 -p 8222:8222 nats:latest -js -m 8222
 3
 4# 2. 用 nats CLI publish / subscribe（CLI 可用 natsio/nats-box 容器）
 5#    docker run --rm --network host natsio/nats-box nats <subcommand>
 6nats --server nats://localhost:4222 pub demo.hello "world"
 7nats --server nats://localhost:4222 sub "demo.>"   # 另開一個 shell 持續訂閱
 8
 9# 3. 建 JetStream stream + pull consumer（持久化 + ack）
10nats --server nats://localhost:4222 stream add demo --subjects 'demo.>' \
11  --storage file --retention limits --discard old --defaults
12nats --server nats://localhost:4222 consumer add demo worker \
13  --pull --deliver all --ack explicit --filter 'demo.>' --defaults

最短路徑驗證「Core NATS + JetStream 都可用」。實際寫程式用 nats client library、見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• nats CLI 指令對照表（pub / sub / stream / consumer / kv）
• 監控 endpoint（/varz / /connz / /jsz HTTP）
• Client library 配置：connection / reconnect / timeout / async / sync subscribe
• 對應指令範例：nats stream info <name>、nats consumer info <stream> <consumer>

Subject hierarchy 與 wildcard

Subject 是 NATS 路由的核心、層級式設計：

• 層級用 . 分隔（例：orders.created.us-west）
• 單層 wildcard *（匹配一層）
• 多層 wildcard >（匹配剩餘所有層）
• Subject 命名規範與 ownership

Core NATS vs JetStream

子議題：

• Core NATS：fire-and-forget、無持久化、極低延遲、適合即時通知 / 控制信號
• JetStream：append-only stream + durable consumer、適合需要 replay / 持久化的事件流
• 兩者並存設計（同一 NATS server 同時跑）

Request/Reply 與 Queue groups

子議題：

• Request/Reply pattern（RPC over messaging）
• Queue groups（load balancing、多 subscriber 分擔同 subject）
• Pub/Sub vs Queue groups 的差異

進階主題（按需閱讀）

JetStream 已展開為兩篇 deep article：core 到 JetStream 邊界（採用決策入口）、JetStream 設計與 supercluster/leaf node（stream / consumer / 跨區拓樸 / 多租戶完整實作）。下列子議題段保留選題判讀入口。

JetStream stream 設計

子議題：

• Stream 配置（subjects、retention policy、storage type）
• File-based vs Memory-based storage
• MaxMsgs / MaxBytes / MaxAge（保留策略）
• Replicas（JetStream raft、跨節點一致性）

JetStream consumer 設計

子議題：

• Durable vs ephemeral consumer
• Push vs pull consumer
• Ack 策略（explicit ack / all / none）
• AckWait + MaxDeliver + DeliverPolicy（重試控制）

Cluster / Supercluster / Leaf node

子議題：

• Cluster：單一 region 多 broker、JetStream raft 同步
• Supercluster：跨 cluster gateway、跨區延展
• Leaf node：邊緣節點、subject mapping、適合 IoT / edge 場景
• 對應 3.C8 Cloudflare Queues 全球交付 的對照思路

JetStream KV / Object Store

子議題：

• KV store（基於 JetStream、簡單 key-value）
• Object Store（基於 JetStream、大 blob）
• 何時用 NATS KV vs 真的 KV 服務（Redis / etcd）

Subject-based ACL 與多租戶

子議題：

• Account 隔離（multi-tenancy 主機制）
• Subject-level permission（publish / subscribe）
• Cross-account import / export

排錯快速判讀

Consumer pending 累積

操作原則：先看 pending 是 ack-pending 還是 stream backlog、再定位 consumer 慢 vs stream 寫入過快。

1nats --server nats://localhost:4222 consumer info <stream> <consumer>
2# 看 Unprocessed Messages（stream backlog）與 Redelivered / Acknowledgment Pending（ack-pending）區分兩種累積

Stream 超 retention limit

操作原則：超 MaxBytes / MaxMsgs 時 stream 觸發 discard policy、看是 old discard 還是 new discard。

Leaf node 連線不穩

操作原則：邊緣節點到 hub 的網路品質決定 subject mapping 延遲、看 reconnect 次數與 latency。

Subject 路由錯誤

操作原則：wildcard 設計錯導致訂閱不到、或匹配過多。看 subject hierarchy 規範與實際 subject。

JetStream raft 不一致

操作原則：replica 配置 R3 但只有 2 個健康節點、stream 變 read-only。看 cluster info 與 raft state。

何時改走其他服務

不在本頁內的主題

• 各語言 client 完整 API（依官方文件）
• NATS 跟 gRPC 的對比（在分散式通訊章節）
• Synadia Cloud 商業功能

案例回寫

NATS 專屬案例（C34-C41）

跨 vendor 對照

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：Kafka、RabbitMQ
• 下游能力：3.4 consumer 設計、3.6 processing recovery semantics

外部發件箱模式（outbox pattern）的核心責任是讓資料提交與事件發布在失敗時保持可恢復一致。它把重複發布轉成可判讀、可去重、可補償的治理問題。

基本流程

transaction outbox 的典型流程是：在同一資料庫交易內，同時寫入業務資料與 outbox 記錄；交易提交後，由 relay worker 讀取 outbox 並發布到 broker；發布成功後標記或刪除 outbox 記錄。

這個流程把一致性問題從「跨系統兩段提交」改成「單系統交易 + 非同步重送」，讓失敗路徑更可控。

relay worker

relay worker 的責任是穩定發布與可恢復進度。worker 需要具備批次拉取、順序控制、重試策略與停損條件。進度管理要明確，避免重啟後漏發或重複失控。

當流量上升時，relay 吞吐會成為關鍵瓶頸。穩定做法是分 shard 處理、限制批次大小、對重試與正常發布做通道分流。

發布失敗與補償

發布失敗通常分為暫時性與系統性。暫時性故障走有限重試，系統性故障走隔離與告警。關鍵是保留 outbox 記錄與發布狀態，讓恢復時可重播。

duplicate publish 在 outbox 模式下屬於預期現象。消費端需要配合 idempotency 機制，確保重複事件不會產生重複業務結果。

判讀訊號

常見誤區

把 outbox 當作「一次解決一致性」的銀彈，會忽略消費端冪等與補償責任。outbox 保證的是發布可恢復，不是端到端結果自動正確。

把 outbox 表當一般業務表無上限累積，也會放大查詢與維護成本。需要定義保留與清理節奏，並確保稽核需求有對應方案。

Self-managed vs Managed broker 的長期 TCO

Broker 選型本質是 long-term TCO 決策、需評估雲端費用 + 工程稅 + 治理負擔三層成本。Self-managed Kafka 的容量規劃 + broker 數量 + 副本因子 + disk + ZooKeeper / KRaft 治理是長期工程 tax、每次擴容是工程專案。

對應 9.C9 Spotify Kafka → Pub/Sub Migration — Spotify 從自管 Kafka 遷到 Google Cloud Pub/Sub、動機是 容量規劃的工程成本 在 sustained growth 下變得不划算、非 Kafka 效能不足。對 7500 萬用戶的事件交付系統、把 broker 容量規劃跟運維負擔卸給 vendor、釋放工程團隊 capacity。

TCO 評估的真實成本項（9.C9 case 列前 4 項 + 雲端費用、第 5 項屬跨案例綜合）：

• Broker 雲端費用：明面成本、相對小
• 容量規劃工程：每季 partition planning、每年容量擴張專案
• 故障處理人力：broker 故障 oncall、ZooKeeper / KRaft 故障診斷
• 升級遷移成本：Kafka 每個 major version 升級是專案
• 跨團隊治理（從 3.C6 Uber 跨案例補充）：規模化後的 multi-tenant 隔離、quota 管理、observability 建設

判讀含義：Self-managed Kafka 在中小團隊可能比 Pub/Sub 便宜（雲端費用低）；但規模化後人力成本壓過雲端費用差、managed service 反而划算。對應 3.C2 VMware Tanzu Kafka → MSK 同樣是「自管 → managed」的決策。

Managed service 的取捨：

• Pub/Sub 自動 scaling、伴隨 vendor lock-in、cost-per-message 累積、message ordering / latency 特性跟 Kafka 差異
• 業務語意對映（Kafka partition / offset / consumer group 在 Pub/Sub 對映成 subscription / ordering key / message attribute）需重新校準、見 3.7 跨 broker 業務語意對映
• 遷移本身需驗證業務語意 — 對應 1.7 schema migration rollout evidence 的同類流程

Broker 遷移的階段流程

對應 9.C9 Spotify — broker 遷移屬高併發容量工程、需維持 producer 連續寫入、保證 message 不丟。Spotify case 列三階段（dual write → shadow → cutover）、本章補第四階段（Decommission）作為清理收尾。replay 模型差異見 3.6 Replay 跟 Idempotency 共設計。

1. Dual-write：producer 同時寫兩個 broker、確保 cutover 前新 broker 有完整資料
2. Shadow consume：新 broker 有獨立 consumer group 消費、驗證業務結果跟舊 broker 一致
3. Cutover：流量逐步切到新 broker、保留舊 broker 為 fallback
4. Decommission（本章補充、case 未明文）：確認新 broker 穩定後關掉舊 broker、清理舊架構

遷移期容量規劃含義：

• Dual-write 期間 broker 雙倍流量（writer side）
• Shadow consume 期間 consumer 雙倍負載（reader side）
• 業務驗證（mismatch tracking）期間有額外的對帳工作量

跟 1.12 大規模 DB 遷移 是同類流程、流程細節跟 evidence chain 可互相參考。

案例回寫

outbox 一致性可用 GitHub 2018 Oct21 MySQL Topology Incident 的恢復段落回寫。先看資料寫入與下游狀態同步是否脫節，再回到本章檢查 outbox backlog、relay 進度與重播策略。 這個案例主要支撐的是「提交後發布一致性」判讀，不直接支撐 broker 的底層投遞參數；若問題是 ack/partition 策略，應回到 3.1/3.2。

當資料已提交但事件遲到，或重播後副作用重複時，先調整 relay 節流與 consumer 冪等，再把驗證證據對齊 6.23 Verification Evidence Handoff。

跨模組路由

1. 與 1.3 的交接：交易邊界語意回到 transaction 與一致性邊界。
2. 與 3.2 的交接：發布後重試與隔離回到 durable queue 與重試策略。
3. 與 3.4 的交接：消費冪等與重播回到 consumer 設計與去重。
4. 與 6.12 的交接：一致性驗證與重播演練回到 Idempotency 與 Replay 驗證。
5. 與 8.19 的交接：發布故障決策回到 Incident Decision Log。

下一步路由

要從 outbox 延伸到消費恢復，接著讀 3.4 consumer 設計與去重。要看 queue 切換失敗時的一致性風險，接著讀 3.C9 反例。

Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 RabbitMQ / Kafka / NATS / Redis Streams / AWS SQS / Google Pub/Sub，每個 vendor 有定位、適用場景、取捨與預計實作話題的骨架。

Deep article（vendor 自身的配置、故障、容量）跟 migration playbook（跨 vendor 遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

暫定分類

選型入口

訊息佇列選型的核心判斷是工作離開 request 或 process 後需要什麼投遞保證。當工作需要排隊、重試、跨服務傳遞、多 consumer 協作或事件補送時，broker 與 outbox 值得優先評估。

RabbitMQ 適合明確 routing、ack/nack 與工作佇列；NATS 適合 subject-based messaging 與較輕量的服務通訊，搭配 JetStream 可加入持久化；Kafka 適合高吞吐事件流、partition 與長期 replay；Redis Streams 適合 Redis 生態內的 stream 與 consumer group；outbox 解決資料寫入與事件發布的一致性；idempotency 解決重複投遞造成的結果穩定性；retry budget 與 jitter 則控制故障期間的重試壓力。

接近真實網路服務的例子包括付款後寄信、影片轉檔、訂單事件傳給多個系統、IoT readings pipeline 與跨節點通知。這些場景的共同問題是 delivery semantics，因此本模組會先處理 broker 模型、retry、DLQ、outbox 與 consumer 設計。

與語言教材的分工

語言教材處理本地 backpressure、processor 邊界、port / Message Protocol 設計與單一 process 內的去重。Backend message queue 模組處理 broker selection、ack/nack、DLQ、consumer group、outbox 與跨 process 重試。

案例驅動讀法

佇列案例的核心讀法是先辨識遷移的是「資料路徑」還是「治理路徑」，再決定先做 broker 切換還是治理收斂。

跨語言適配評估

訊息佇列使用方式會受語言的 worker model、錯誤處理、序列化、背景任務框架與 idempotency 設計影響。同步 runtime 要控制 consumer thread 數量與 ack timeout；async runtime 要處理 backpressure 與 long-running handler；輕量並發 runtime 要限制同時處理量，避免 consumer 擴張超過下游容量。強型別語言適合建立 event schema 與 command model；動態語言要補足 payload validation、dead-letter 診斷與重播測試。

章節列表

反例與規模對照入口： 3.C9 反例 / 3.C10 對照。

回退判讀寫法見 0.C4 回退判讀寫法，queue 案例要優先保留 delivery semantics、lag、DLQ 與 replay 條件。

跨模組端到端串聯（DB → cache → event → observability）見 0.15 跨模組 Checkout Episode。

觀念網路補完方向

訊息佇列章節下一輪的核心責任是把「投遞成功」和「業務結果正確」分開。現有章節已經有 broker、durable queue、outbox 與 consumer design，但還需要補上 delivery semantics、processing semantics 與 recovery semantics 的三層關係，讓讀者知道 queue 失敗同時包括訊息遺失、重複副作用、順序錯亂、重播風險與下游壓力放大。

這些方向要用非同步服務自己的語意展開。寄信、開 invoice、更新 CRM、同步 search index、發 webhook 的副作用不同，retry、DLQ 與 replay 的判準也不同。

知識卡補強方向

佇列模組的 knowledge card 缺口集中在「處理語意」與「恢復語意」。已有 consumer lag、retry budget、poison message 與 offset 可以作為第一批錨點。

第二批卡片已補上 processing semantics、recovery semantics、replay window、consumer pause、event schema compatibility、DLQ drain 與 poison-message quarantine。這些卡片讓讀者能分辨「queue 有持久化」和「consumer 結果可恢復」分屬不同責任。

實作探討入口

佇列的第一條實作路徑是 3.8 Queue Consumer Retry 與 Replay Handoff（實作示範）。這篇以 order_created consumer 為例，說明 idempotency evidence、DLQ handling、replay runbook 與 incident decision route 如何一起成立。

這條路徑的前置引用應該是 3.2 durable queue、3.3 outbox pattern、3.4 consumer design、6.12 Idempotency 與 Replay 驗證 與 6.23 Verification Evidence Handoff。完成後可依 Backend 學習路線 進入下一條服務路徑。

佇列路徑的 artifact 對齊重點是「把投遞成功與處理成功拆開記錄」。對 4.20 要交 Source/Time range/Query link/Owner/Data quality，並覆蓋 consumer lag、retry、DLQ 與 duplicate side-effect；對 6.12 / 6.23 / 6.8 要交 Gate decision/Checks/Stop condition/Rollback window/Owner，呈現 replay 範圍、去重驗證與補償路徑；對 8.19 要交 Timestamp/Decision/Context/Evidence/Owner/Expected effect/Rollback condition，記錄 pause consumer、drain DLQ、重播啟停的決策序列。

業務背景

LinkedIn 是 Kafka 的誕生地，內部 Kafka 叢集承載的工作負載涵蓋即時推薦、搜尋索引更新、analytics pipeline、audit log 跟 monitoring。早期所有 workload 共用少數幾個大叢集，隨流量成長，叢集內不同 workload 的資源競爭開始互相影響。

LinkedIn 的 Kafka 規模是全球最大的之一 — 數千個 broker、每秒數百萬筆訊息、PB 級資料保留。在這個規模下，單一叢集的容量限制是 broker 數量跟 ZooKeeper 的 metadata 管理上限，但更早觸及的限制是 workload 之間的干擾。

技術挑戰

Noisy neighbor

即時推薦系統需要低延遲的 consumer（P99 < 50ms），analytics pipeline 是大量 batch consumer（高吞吐但延遲容忍到秒級）。兩者共用同一組 broker 時，batch consumer 的大範圍 sequential read 佔滿 disk I/O，擠壓即時推薦的 random read latency。

一個 analytics job 的重跑（backfill 歷史資料）可以讓推薦系統的 consumer lag 從毫秒跳到秒級。在共享叢集中，這種干擾難以預防 — 只能在事後發現、人工協調。

Broker 故障的影響面

單一叢集中 broker 故障會觸發 partition reassignment，reassignment 的資料搬移佔用 disk I/O 跟網路頻寬。在混合 workload 的叢集中，reassignment 同時影響所有 workload 的效能 — 包括跟故障 broker 無直接關係的 topic。

叢集越大、topic 越多、reassignment 的影響面越廣。

容量規劃的模糊邊界

共享叢集的容量規劃沒有清楚的 owner — analytics 團隊說「我們需要更多 retention」、推薦團隊說「我們需要更低 latency」、audit 團隊說「我們的資料不能丟」。三種需求各自合理，但共享叢集無法同時最佳化。

解法：分層叢集

LinkedIn 按業務風險跟效能需求把 workload 分配到不同叢集：

Tier 1 — 即時關鍵路徑：即時推薦、搜尋索引更新、使用者通知。Broker 配置偏向低延遲（SSD、高 IOPS）、replication factor 3、retention 短（保留足夠的 consumer catchup 時間）。

Tier 2 — 可靠性要求高但延遲容忍：audit log、合規事件、支付事件。配置偏向持久性（replication factor 3、min.insync.replicas 2、acks=all）、retention 長。

Tier 3 — 高吞吐分析：analytics pipeline、ETL、batch processing。配置偏向吞吐（大 batch size、長 linger.ms、HDD）、retention 最長、容忍偶發 consumer lag。

分層的判準

分層的判準是「這個 workload 故障時，業務影響有多大、多快」：

• 即時影響使用者體驗 → Tier 1
• 影響合規或財務但可容忍分鐘級延遲 → Tier 2
• 影響分析準確性但可容忍小時級延遲 → Tier 3

取捨

分層的成本是資源利用率下降 — 每層都需要保留一定的 headroom 應對高峰，加總起來比共享叢集多。LinkedIn 的判斷是隔離性的價值大於利用率的損失 — 推薦系統一次 P99 退化的業務損失遠大於多幾台 broker 的成本。

回寫教材的連結

• 3.1 broker basics：broker 配置怎麼影響延遲 vs 吞吐 vs 持久性的取捨。
• 6.14 dependency reliability budget：不同 tier 的 Kafka 叢集各自有不同的 reliability budget。
• 3.4 consumer design：batch consumer 跟 real-time consumer 的資源消耗差異。

判讀徵兆

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

• 即時消費者的 consumer lag 因為同叢集的 batch job 而上升
• Broker 故障後的 partition reassignment 影響到跟故障無關的 topic
• 容量規劃會議中不同團隊的需求互相矛盾、無法在同一組配置中滿足
• Kafka 叢集的 topic 數量超過 500 個、workload 類型超過三種

引用源

• Running Kafka at Scale at LinkedIn

對「已用 Redis、需要輕量 stream、不想引入額外基礎設施」這條路徑、Redis Streams 是務實選擇。本頁先給最短路徑、再展開日常 XADD/XREAD 操作與 consumer group 設計、最後進階治理（PEL、retention、Cluster 影響）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 redis-cli XADD / XREAD 操作 stream
2. 設計 consumer group + XCLAIM 處理 consumer 失敗的訊息接管
3. 看懂 pending entries list（PEL）累積訊號、定位 consumer 健康
4. 設計 MAXLEN / MINID retention 對齊記憶體預算
5. 評估 Redis Cluster 對 Streams 的影響與限制

最短路徑：5 分鐘把 Redis Streams 跑起來

 1# 1. 啟動 Redis（已有 Redis 跳過）
 2docker run -d --name redis -p 6379:6379 redis:7
 3
 4# 2. XADD 寫入 stream（'*' 由 Redis 產生遞增 entry ID）
 5docker exec redis redis-cli XADD mystream '*' field1 value1
 6
 7# 3. XREAD 讀取（從 0 起讀、最多 10 筆）
 8docker exec redis redis-cli XREAD COUNT 10 STREAMS mystream 0
 9
10# 4. 建 consumer group 後用 group 模式讀（'>' 取未投遞訊息、進 PEL 等 ack）
11docker exec redis redis-cli XGROUP CREATE mystream mygroup 0
12docker exec redis redis-cli XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream '>'

最短路徑驗證「Redis 起來、stream 能寫能讀」。實際用 consumer group 場景見日常操作。

日常操作與決策形狀

XADD / XREAD / XREADGROUP

子議題：

• XADD：寫入 entry、* 自動 ID vs 手動 ID
• XREAD：簡單讀取（無 consumer group、適合單 consumer）
• XREADGROUP：consumer group 模式、配合 ACK
• 對應指令範例：XADD、XREAD、XREADGROUP、XACK、XPENDING

Consumer group 與 PEL

Consumer group 是 Streams 的核心抽象、配合 Pending Entries List（PEL）追蹤未 ack 訊息。子議題：

• XGROUP CREATE / SETID / DESTROY
• XACK：明確 ack
• XPENDING：查 PEL 狀態
• XCLAIM / XAUTOCLAIM：consumer 失敗時接管訊息

Retention：MAXLEN / MINID

子議題：

• MAXLEN：保留最近 N 個 entry（近似或精確）
• MINID：保留 ID 大於某值的 entry
• XADD 寫入時帶 MAXLEN（最常用）
• XTRIM 手動修剪

進階主題（按需閱讀）

PEL 失敗接管、retention 與 cluster 影響已展開為 deep article：XCLAIM/PEL 失敗接管與 cluster 影響。下列子議題段保留選題判讀入口。

XCLAIM 與 consumer 失敗接管

子議題：

• Idle time 判讀（min-idle-time 參數）
• XAUTOCLAIM（Redis 6.2+、自動接管）
• 接管後的去重責任（仍需 idempotency）

Memory 與 retention 取捨

子議題：

• Stream 佔用 Redis 記憶體、MAXLEN 是主要旋鈕
• 近似修剪（~ 標記）vs 精確修剪的性能差異
• 配合 maxmemory-policy 與 eviction（注意 stream 不會被 eviction）

Redis Cluster 對 Streams 的影響

子議題：

• Stream key 只在單一 shard（無 partition 概念）
• 多 stream 跨 shard 的設計（用 hash tag 控制分布）
• Cluster failover 對 PEL 一致性的影響

Stream + Functions（Redis 7+）

子議題：

• Redis Functions（取代 Lua scripting）
• Stream 處理寫成 Redis-side function
• 適用 / 不適用場景

Redis Sentinel / Cluster 對可靠性的影響

子議題：

• Replication lag 對 Streams 一致性的影響
• AOF 與 RDB 對 Stream 持久化的差異
• Failover 期間 PEL 是否完整

排錯快速判讀

PEL 累積（XPENDING 數字持續增長）

操作原則：先看是單一 consumer 還是整 group 都累積、再定位 consumer 失敗 vs ACK 漏寫。

1redis-cli XPENDING mystream mygroup
2# 回傳 PEL 總數 + 每個 consumer 的待 ack 數、定位累積集中在哪個 consumer

判讀路徑：consumer crash 沒 ACK → consumer 慢 → ACK 程式碼漏寫。

Memory pressure（stream 佔用過大）

操作原則：MAXLEN 沒設或設太大、stream 持續增長。判讀：用 MEMORY USAGE 看 stream 佔用、調整 MAXLEN。

跨 shard stream 限制

操作原則：Streams 不支援 partition、單 stream 受單 shard 容量限制。設計：用 hash tag 強制分散到多 stream。

Consumer 重平衡（無原生機制）

操作原則：consumer group 沒有自動 rebalance、要手動 XCLAIM 接管。看 idle time 與 XPENDING 判斷該接管哪些。

Failover 後 PEL 不一致

操作原則：Sentinel / Cluster failover 後、replica 升 primary、PEL 可能不完整。對應 3.C9 語義誤配 的思路。

何時改走其他服務

不在本頁內的主題

• Redis 本體運維（見 02 cache 模組 redis vendor）
• 各語言 Redis client 完整 API
• Redis Pub/Sub 細節（不是 Streams、語意不同）

案例回寫

Redis Streams 專屬案例（C42-C47）

跨 vendor 對照

Stream + Functions / Redis Cluster on Streams 缺直接 customer case：公開資料多在 single-instance / Sentinel 規模、Cluster 跟 Functions 案例稀薄、撰寫該段時要明示。

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• Redis 本體：02 cache 模組
• 平行 vendor：Kafka、NATS
• 下游能力：3.4 consumer 設計

三層語意

consumer 端需要同時處理三層語意：

1. delivery semantics：訊息是否被成功投遞與確認，包含 ack/nack、retry、DLQ。
2. processing semantics：業務副作用是否可承受重複、亂序與部分失敗。
3. recovery semantics：故障後是否能重播、補償與回復到一致狀態。

這三層拆開後，才能看清問題落在哪一層。訊息送達不代表副作用完成；副作用完成不代表系統可恢復。

consumer group、partition 與順序責任

consumer group 與 partition 定義了並行與順序邊界。順序要求高的流程要把同一鍵值固定在同一 partition；吞吐優先的流程可提高 partition 數並分散處理。

分區策略會直接影響恢復成本。分區鍵混亂時，重播與補償很難限定範圍，事故期間容易擴大影響面。

checkpoint、offset 與 idempotency

checkpoint 與 offset 的責任是標記「處理到哪裡」，不是「業務一定完成」。寫 checkpoint 的時機要晚於副作用提交，避免進度前移導致資料遺漏。

idempotency key 的責任是讓重試與重播可重入。付款、發票、通知、庫存變更都需要明確冪等鍵與去重儲存策略，讓「至少一次投遞」不會變成「多次業務結果」。

replay safety

replay safety 的核心是先定義可重播範圍，再定義副作用控制。常見做法包含：

1. 限定 replay window，避免一次重播跨越多個版本邊界。
2. 將副作用拆成可比對與可補償動作，保留對帳路徑。
3. 對 replay 期間的下游壓力設置節流與停損條件。

poison message 要獨立隔離。持續重試同一壞訊息會壓垮整體吞吐，穩定做法是送入 dead-letter queue，再走診斷與修復流程。

Queue 語意誤配是 broker 遷移最常見的失敗模式

Broker 遷移失敗的根因通常是 consumer 對舊 broker 行為的隱式依賴、不是 broker 本身效能。表面上訊息仍被送達、但業務資料開始出現重複扣款、重複寄信、狀態漏更新。

對應 3.C9 反例：Queue Semantics Mismatch Cutover — case 揭露切換後語意誤配三個方向：consumer 依賴特定 offset 行為、依賴特定重試節奏、依賴特定 idempotency 行為。失敗重播時、新系統即使提供相近 delivery semantics、結果可能不同。語意誤配會沿著下游資料寫入擴散、難以靠 queue depth 判斷。

典型誤配場景（基於通用 broker 行為知識展開、非 3.C9 case 原文具體列舉）：

• At-least-once 假設變成 exactly-once 依賴：consumer 假設 broker 僅送一次、靠記憶單次處理；新 broker 重送同一 message、consumer 處理兩次
• Offset 跳號處理差異：舊系統重啟後 offset 從特定位置開始、新系統可能從 latest / earliest 不同位置開始
• Consumer group rebalance 行為差異：rebalance 期間舊系統會 pause 處理、新系統可能繼續處理、產生並發寫入衝突
• DLQ retry 節奏差異：舊系統 DLQ message 預設不重試、新系統可能自動重試、製造重複副作用

回退判讀：回退前要先確認哪一段資料已經被新語意處理過。直接切回舊 broker 可能讓同一批事件再次被處理。穩定做法是先凍結新 consumer、保留 offset 對照與 replay 範圍、再決定補償或重播。

詳細處理 / 恢復語意分層見 3.6 processing-recovery-semantics。規模差異判讀（小 / 中 / 大型服務的 job queue 治理重點）見 3.8 queue-consumer-retry-replay-handoff — 中型服務常見問題是 lag/DLQ 長期累積、需具備定向 replay 能力、否則退回全 topic 重播會放大下游壓力。

三個工程議題要一起設計

Consumer idempotency + 重播流程 + 下游承載能力 三件事是 consumer design 的鐵三角、需同步落地。缺一個會在規模化時暴露成事故：

• Consumer idempotency 不完整：DLQ replay 後產生重複副作用、即使 broker 切換成功、業務帳本仍然錯亂
• 重播流程不完整：事故當下需具備定向 replay 能力、否則退回全 topic 重播會放大下游壓力
• 下游承載能力不足：consumer 跟 broker 都健康、但下游 DB / API 撐不住 replay 速率、形成新事故

Job queue 的拓樸分工是另一個獨立議題、跟鐵三角互補但不重疊 — 詳見 3.8 Job queue 拓樸分工、主寫 Slack Kafka + Redis 案例。consumer 內部三件事要做好之外、不同類工作（高吞吐 / 即時 / 持久）也應專注單一目標、其他目標拆到對應路徑。

判讀訊號

常見誤區

把 consumer 設計等同於「把 handler 寫完」，會漏掉恢復責任。consumer 的工程價值在於故障後仍可追蹤、可補償、可重播。

把 DLQ 當成終點，會讓問題在下次事件再出現。DLQ 的責任是隔離與診斷入口，最終要回到 schema、邏輯或依賴治理。

案例回寫

consumer 恢復語意可用 3.C9 反例 與 3.C3 LinkedIn：TopicGC 對照回寫。先判讀問題是 idempotency 失效、checkpoint 前移，還是 replay 邊界失控，再對應本章的 processing/recovery 段落。 這組案例主要支撐的是「處理恢復語意」判讀，不直接支撐 deployment drain 或 cache eviction；若根因在切流順序或快取容量，應轉到 5.3 或 2.3。

若重播成功但業務狀態仍不一致，先補副作用補償與對帳路徑，並把決策證據同步到 8.19 Incident Decision Log。

跨模組路由

consumer 設計是 01/03/04/06/08 的交界點。

1. 與 03 內部的交接：processing/recovery 語意完整定義在 3.6 processing-recovery-semantics；event contract 跟 replay boundary 在 3.7；規模差異判讀跟 job queue 拓樸分工在 3.8。
2. 與 01 的交接：交易與發布一致性回到 3.3 outbox pattern 與 1.3 transaction boundary。
3. 與 04 的交接：lag、retry、DLQ、duplicate 指標進入 Observability Evidence Package。
4. 與 06 的交接：重試與重播驗證進入 6.12 Idempotency 與 Replay 驗證。
5. 與 08 的交接：pause consumer、replay 決策與補償判斷記錄到 Incident Decision Log。

下一步路由

要看 processing / recovery 三層語意完整定義、接著讀 3.6 processing-recovery-semantics。要建立 broker 層投遞模型，接著讀 3.1 broker 基礎與投遞模型 與 3.2 durable queue。要看錯誤切換案例，接著讀 3.C9 反例。

觀察

Slack 在 job queue 擴展中使用 Kafka 與 Redis 分工，處理吞吐與即時性需求。

判讀

當背景工作同時要高吞吐與快速反應，單一通道模型通常會變成瓶頸。

策略

1. 把不同工作類型切到不同傳遞路徑。
2. 分別治理持久性與即時性目標。
3. 以 lag、重試與失敗重播驗證穩定性。

下一步路由

回 3.2 durable queue 與 3.3 outbox pattern。

引用源

• Scaling Slack’s Job Queue

對「AWS 生態 task queue、不想自管 broker、配合 Lambda 事件處理」這條路徑、SQS 是首選。本頁先給最短路徑、再展開日常 SendMessage / ReceiveMessage 操作與 visibility timeout 設計、最後進階治理（FIFO、DLQ、IAM、VPC endpoint）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 AWS CLI 建 standard / FIFO queue、發送與接收訊息
2. 設計 visibility timeout 對齊 consumer 處理時間
3. 配置 DLQ（dead-letter queue）與 maxReceiveCount
4. 區分 long polling vs short polling、配合 Lambda event source mapping
5. 評估 IAM policy、VPC endpoint、cross-account 訪問等治理場景

最短路徑：5 分鐘把 SQS 跑起來

1# 1. 建 queue（回傳 QueueUrl、後續操作都用它）
2aws sqs create-queue --queue-name demo-queue
3
4# 2. 發送訊息
5aws sqs send-message --queue-url <url> --message-body "hello"
6
7# 3. 接收訊息（long polling、最多等 20 秒）
8aws sqs receive-message --queue-url <url> --wait-time-seconds 20

最短路徑驗證「queue 建得起來、能發能收」。實際應用配合 SDK / Lambda、見日常操作。指令對真實 AWS 需設定 credentials 與 region；本機要先驗證可加 --endpoint-url 指向 SQS-相容的 local 模擬器跑同一組指令。

日常操作與決策形狀

AWS CLI 與 SDK

子議題：

• AWS CLI 指令對照表（create-queue / send-message / receive-message / delete-message / set-queue-attributes）
• SDK 配置：region / credentials / retry policy / timeout
• Batch operation（SendMessageBatch、DeleteMessageBatch、最多 10 條）
• 對應指令範例：aws sqs get-queue-attributes --queue-url <url>

Standard vs FIFO queue

子議題：

• Standard：高吞吐、at-least-once、無 ordering、適合多數 task queue
• FIFO：exactly-once-ish（去重 5 分鐘窗口）、ordering（per MessageGroupId）、吞吐受限（3000 msg/sec with batching）
• 選擇判讀（ordering 需求 vs 吞吐）

Visibility timeout 與 in-flight

Visibility timeout 是 SQS 的 delivery 控制機制、取代 broker ACK：

• 訊息被接收後變 in-flight、其他 consumer 看不到
• Consumer 處理完呼叫 DeleteMessage、否則 timeout 後回到 queue
• ChangeMessageVisibility 動態延長（長任務）
• 預設 30 秒、上限 12 小時

DLQ 設計（dead-letter queue）

子議題：

• maxReceiveCount：訊息被接收 N 次後送 DLQ
• DLQ 監控與 alarm（CloudWatch metric）
• Redrive policy（從 DLQ 重新放回 main queue）
• 對應 poison message 處理思路

進階主題（按需閱讀）

visibility timeout、polling、Lambda event source 與 cost 已展開為 deep article：visibility timeout / long polling / Lambda + cost。下列子議題段保留選題判讀入口。

Long polling vs Short polling

子議題：

• Short polling（預設）：立即回應、可能空回（高 cost）
• Long polling（WaitTimeSeconds 1-20）：等到有訊息或超時
• 對 cost 與 latency 的取捨

SQS + Lambda event source mapping

子議題：

• Lambda 自動 poll SQS（managed event source）
• Batch size / batch window 配置
• Partial batch failure（ReportBatchItemFailures）
• 對應 3.C8 Cloudflare Queues 的全球交付對照

IAM / Cross-account 訪問

子議題：

• Queue policy（resource-based）vs IAM policy（identity-based）
• Cross-account producer / consumer 設定
• Encryption（SSE-SQS / SSE-KMS）

VPC endpoint（私網訪問）

子議題：

• Interface endpoint（PrivateLink）
• 適合不想經 public internet 的場景
• 跟 NAT Gateway 的 cost 對照

CloudWatch metric 與 alarm

子議題：

• ApproximateNumberOfMessagesVisible（queue depth）
• ApproximateAgeOfOldestMessage（lag 訊號）
• NumberOfMessagesSent / Received / Deleted
• Alarm 設計（depth 暴增、age 超 SLO）

Cost 模型

子議題：

• Request cost（每百萬 request）
• Data transfer cost（跨 region 才有）
• FIFO 比 standard 貴的判讀
• 對應 0.6 成本取捨

排錯快速判讀

Message 反覆 redelivery（看到同訊息多次）

操作原則：visibility timeout 設定 < consumer 處理時間、訊息回 queue 又被另一 consumer 領走。

1aws sqs get-queue-attributes --queue-url <url> --attribute-names VisibilityTimeout
2# 新建 queue 預設 VisibilityTimeout 為 30 秒、處理時間長於此值就會看到 redelivery

調整：延長 VisibilityTimeout 或 consumer 主動 ChangeMessageVisibility。

DLQ 累積

操作原則：先看 DLQ 訊息內容、判斷 poison message vs 下游卡。

判讀路徑：訊息格式錯（永遠失敗）→ 下游服務 down（暫時失敗、可 redrive）→ consumer bug。

Throttling（account quota）

操作原則：超過 account-level SendMessage / ReceiveMessage TPS、看 CloudWatch ThrottledRequests。處理：requeue exchange、quota 申請。

IAM 權限錯

操作原則：access denied 大多是 queue policy 跟 IAM policy 互動。判讀：用 IAM Policy Simulator 或 CloudTrail 看 deny 原因。

Lambda event source 失敗

操作原則：Lambda 失敗會自動 retry、超過 retry 進 DLQ。看 Lambda 的 DLQ 跟 SQS 的 DLQ 分工。

何時改走其他服務

不在本頁內的主題

• SNS / EventBridge 細節（另開 cloud event routing 章節）
• Step Functions / Lambda 完整功能
• AWS SDK 各語言完整 API

案例回寫

SQS 專屬案例（C48-C59）

跨 vendor 對照

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：Google Pub/Sub、RabbitMQ
• 下游能力：3.2 durable queue、3.4 consumer 設計

【判讀】傳遞層弱點的主要軸線

傳遞層弱點可分成三條軸線：投遞語意、處理語意、回復語意。投遞語意看 ack/nack 與重送條件；處理語意看 idempotency 與 side effect；回復語意看 dead-letter queue、replay runbook 與 data reconciliation。

【可觀察訊號】何時要提高紅隊檢查優先級

下列訊號出現時，傳遞層通常需要先做弱點盤點：

• consumer lag 持續增加，且重試量同步升高
• DLQ 累積速度高於排空速度
• 同一事件會被多路 consumer 讀取並觸發多個下游 side effect
• 回放流程缺少操作邊界與審核節點

【失敗代價】傳遞層弱點的代價型態

傳遞層弱點會把局部錯誤放大成系統性壓力。重複投遞會造成重複扣款、重複通知或重複建單；毒訊息會阻塞分區與 worker；重放策略缺少邊界會把歷史事件再次推進生產流程。這些問題的共同代價是資料偏移、事故窗口延長與操作風險上升。

【最低控制面】進入服務實體前要先定義

傳遞層在討論具體服務前，先定義四個控制面最穩定：

1. 投遞保證模型：哪些流程接受 at-least-once、哪些流程需要更嚴格保證。
2. 去重與副作用模型：哪些操作必須具備 idempotency，如何界定重複。
3. 重試與降載模型：重試節奏、上限、退避與壓力保護機制。
4. 回復與重放模型：DLQ 分流、回放準入條件與結果校正流程。

多租戶 broker 的隔離邊界

Multi-tenant broker 的隔離邊界承擔「單租戶故障不放大到其他租戶」的責任。Multi-tenant broker 的紅隊重點是跨租戶邊界能否擋住攻擊放大跟資源耗盡。3.1 已建立規模化分層討論、本段聚焦攻擊面跟控制面。

對應 3.C6 Uber Kafka Infrastructure Evolution — case 提出方向：定義租戶隔離、配額規則、標準化 topic 治理、平台指標治理。對應 3.C4 LinkedIn Tiered Clusters — 規模化分層 cluster、高優先 workload 跟低優先 workload 各自獨立、降低 noisy neighbor 風險。以下攻擊面 taxonomy 基於通用 multi-tenant broker 知識展開、非 case 原文列舉。

Multi-tenant broker 的攻擊面：

• 配額耗盡：單一 tenant 大量 publish 占光 broker bandwidth / storage、其他 tenant 投遞延遲拉長。對應控制是 per-tenant quota + rate limit。下游推送 quota 作為硬上限見 3.2 下游推送是隱性瓶頸
• Topic 命名衝突 / 越權：tenant A 透過命名衝突或缺失 ACL 取得 tenant B topic 存取權限。對應控制是 namespace 強制隔離 + IAM topic-level ACL
• DLQ 跨租戶污染：tenant A 的 poison message 進共用 DLQ、影響 tenant B 的 DLQ 處理流程。對應控制是 per-tenant DLQ + 獨立排空策略
• Consumer group 命名衝突：意外或惡意註冊跟其他 tenant 同名的 consumer group、搶 partition 分配。對應控制是 consumer group naming convention + prefix-based ACL

判讀重點：multi-tenant broker 的紅隊不只看 broker 容量是否充足、還要看單一 tenant 出事時其他 tenant 是否受影響。單一租戶事件擴散到其他租戶屬隔離失敗、非 broker 效能問題。

Replay 攻擊跟 DLQ 濫用

Replay 機制是事故恢復工具、也是攻擊面。攻擊者可能濫用 replay 重複觸發副作用（重複退款、重複送通知、重複下單）、或讓 DLQ 變成 backdoor 通道。以下 3 個攻擊向量基於通用紅隊知識展開、非 case 原文列舉。

Replay 攻擊向量：

• 未授權 replay 觸發：攻擊者拿到 replay 控制權、replay 舊事件造成重複副作用。對應控制是 replay 授權需獨立審核 + audit trail 記錄誰 replay 什麼
• Replay window 越界：replay 跨越 idempotency 紀錄到期、舊事件被當新事件處理。對應控制是 replay window 上限 = idempotency 保留期、見 3.6 processing-recovery-semantics 的 replay 跟 idempotency 共設計
• DLQ message 注入：攻擊者把惡意 message 直接寫進 DLQ、繞過主通道驗證、等 replay 時觸發副作用。對應控制是 DLQ 寫入權限獨立於主通道 + replay 前 schema 重新驗證

判讀重點：replay 屬 production 操作、跟 1.9 reconciliation 修復權限管理 同層級、要 audit trail + 審核流程。合規 replay 路徑應具備 audit trail + window 上限 + DLQ 寫入隔離三層控制、把 replay 從事故工具升級為可稽核的 production 操作。

【案例對照】

以上 3.C6 / 3.C4 屬治理視角案例、紅隊章節做反推使用（從控制面反推攻擊面）。

跨模組路由

1. 與 03 內部：規模化分層治理回 3.1 broker-basics；下游推送 quota 攻擊面跟 3.2 durable-queue 下游推送是隱性瓶頸 互補；replay 跟 idempotency 共設計回 3.6
2. 與 01 的交接：replay / 補償權限管理回 1.9 reconciliation 修復權限管理
3. 與 04 的交接：紅隊偵測訊號（DLQ 速率、retry storm、duplicate）進 4.20 Observability Evidence Package
4. 與 06 的交接：rule rollout 安全閘門進 6.24 rule-rollout-safety-gate
5. 與 08 的交接：事故當下決策進 8.19 Incident Decision Log

【關聯卡片】

• Poison Message
• Duplicate Delivery
• Retry Storm
• Backpressure
• Runbook

Delivery / Processing / Recovery

三層語意的責任不同：

delivery semantics 成立不代表 processing 成立。訊息被 ack 也不代表發票、email、search index 或 webhook 都已完成。

Delivery 層的判讀重點是 broker 是否還能掌握訊息位置。Processing 層的判讀重點是 consumer 是否已經完成業務副作用。Recovery 層的判讀重點是事故後能否用 replay、checkpoint 與 reconciliation 回到一致狀態。這三層拆開後，隊列工具選型才會對到真正問題。

Processing Semantics

Processing semantics 的責任是讓 consumer 副作用在重複投遞與部分失敗下仍可控。常見副作用包含寫資料庫、呼叫外部 API、寄信、建立發票、更新 search index。

每個副作用都要先回答：

1. idempotency key 是什麼。
2. 副作用完成後如何記錄。
3. 重複執行時結果是否穩定。
4. 部分成功時如何補償。

缺少這些答案時，at-least-once delivery 會轉成多次業務結果。

Recovery Semantics

Recovery semantics 的責任是讓系統在 consumer crash、DLQ 爆量、下游故障或資料修復後能恢復一致。它依賴 replay window、checkpoint、offset、去重紀錄與對帳查詢。

恢復流程要先分範圍。按時間、tenant、partition、schema version 或 event type 分段，能降低 replay 造成的下游壓力與重複副作用。

Checkpoint 與 Side Effect

checkpoint 的責任是標記處理進度，業務完成則要由副作用紀錄與對帳證據證明。若 checkpoint 早於副作用提交，consumer crash 後可能漏做副作用；若 checkpoint 太晚，重啟後會造成重複處理。

穩定設計通常讓副作用具備 idempotency，再把 checkpoint 放在可恢復的位置。checkpoint 與 idempotency 是一組設計，需要一起審查。

Poison Message 的處理層次

Poison message 屬於觸發 consumer 持續失敗、需要被隔離處理的訊息類型。處理流程從 偵測 / 隔離 / 診斷 / 修復 四個層次設計、屬於 DLQ 之後的延伸責任。

對應 3.C9 反例：Queue Semantics Mismatch — case 提供切換後 DLQ 激增的觀察方向、是 broker 遷移時 consumer 沒對齊 processing/recovery 語意的訊號、poison message 是其下游表徵之一。

四個處理層次：

• 偵測：retry count 超過組織自定閾值後識別為 poison candidate。早期偵測訊號是 retry rate 升高但 success rate 沒同步上升、單一 consumer 反覆失敗
• 隔離：把 poison message 移出主通道、進 DLQ 或 quarantine queue。隔離要即時、避免持續占用主通道吞吐
• 診斷：DLQ 內 poison message 要分群分析、找出共同 failure pattern（payload schema 不符、外部 API 永久失敗、邏輯 bug）
• 修復：依據 root cause 修 consumer / contract / 邏輯後、再定向回放 DLQ 內 poison message、避免 zombie cycle（同一 message 反覆進 DLQ）

判讀重點：DLQ size 持續增加但沒有對應修復 commit、表示處理流程斷在「隔離」這層、要回到「診斷 / 修復」。release gate 加「DLQ 排空速率 >= 流入速率」的條件、讓 DLQ 維持診斷入口的角色。未授權 replay 跟 window 越界攻擊面見 3.5 紅隊章 Replay 攻擊。

Replay 跟 Idempotency 的共設計

Replay safety 跟 idempotency 屬於同一個設計階段、需共設計並落地後才能上線。replay window 設多大、idempotency key 怎麼定、checkpoint 何時提交、三者互相影響、任一改動都會破壞其他。

共設計的判讀順序：

1. 先定 idempotency key：什麼欄位組合能唯一標記副作用（event_id、entity_id + version、business operation id）
2. 再定 idempotency 儲存策略：去重紀錄存多久（決定 replay window 上限）、儲存在 cache / DB / 應用層 memory
3. 依儲存策略反推 replay window：去重紀錄保留 7 天、replay window 上限就是 7 天、超過會出現重複副作用
4. 再依 replay window 反推 checkpoint 策略：checkpoint 落地時機要保證 crash 後 replay window 內可恢復

對應 9.C9 Spotify Kafka → Pub/Sub — broker 遷移要驗證業務語意跟新 broker 兼容、replay 模型在 Kafka（offset）跟 Pub/Sub（snapshot + seek）不同、idempotency 策略要重新校準。

判讀重點：replay window 由 idempotency 儲存策略反推、不是 broker 設定值。先看 idempotency key 跟去重儲存、再決定 replay window 安全範圍。順序顛倒會踩到「replay 跨越去重紀錄到期」的事故、表現是 replay 後出現本來該被去重的重複副作用。

選型前判準

Queue 選型前要先回答：

1. 需要保證的是投遞、處理還是恢復。
2. 哪些副作用必須 idempotent。
3. 哪些事件需要順序，順序邊界是全域、tenant、entity 還是 partition。
4. Replay 時下游能承受多少吞吐。
5. DLQ 是診斷入口還是已經變成長期倉庫。

這些答案會決定後續比較 Kafka、RabbitMQ、SQS、NATS 或 Redis Streams 時該看哪些能力。

實體服務討論承接點

實體 queue/broker 文章要承接本篇的 processing 與 recovery semantics。Kafka、RabbitMQ、SQS、NATS 或 Redis Streams 的比較，應先問服務需要什麼投遞、處理與恢復責任，再比較 topic、queue、partition、consumer group、DLQ 或 retention。

若主問題是高吞吐事件流，後續文章要比較 partition、retention、consumer lag 與 replay 能力。若主問題是工作派發，後續文章要比較 ack/nack、routing、DLQ 與 retry。若主問題是受管服務操作成本，後續文章要比較可觀測性、IAM、區域能力與 failure mode。

跨模組路由

1. 與 03 內部：consumer 端去重跟 ack timing 詳見 3.4 consumer-design；event payload 跟 replay 邊界寫入事件契約見 3.7；規模差異判讀跟 job queue 拓樸分工見 3.8
2. 與 04 的交接：lag、retry、DLQ、duplicate 訊號進 4.20 Observability Evidence Package
3. 與 06 的交接：idempotency 跟 replay 驗證進 6.12 Idempotency 與 Replay 驗證

下一步路由

要把 event payload 跟 replay 邊界寫進事件契約、接著讀 3.7 Event Contract 與 Replay Boundary。要建立 broker 投遞模型，接著讀 3.1 broker 基礎與投遞模型。要把三層語意放進完整服務路徑，接著讀 3.8 Queue Consumer Retry 與 Replay Handoff。

業務背景

Uber 的事件流涵蓋行程追蹤、司機定位、計費事件、推播通知、即時定價、ETA 計算跟 analytics。早期各團隊各自架設 Kafka 叢集，隨著 Kafka 在 Uber 內部的採用率上升，叢集數量跟 topic 數量快速增長，但沒有統一的治理。

Uber 的 Kafka 規模峰值達到每秒數百萬筆訊息、數十個叢集、數千個 topic。在這個規模下，管理壓力從「單一叢集的 broker 夠不夠」轉到「誰在用、用多少、怎麼收費、故障時誰負責」。

技術挑戰

團隊自管的碎片化

各團隊各自架設 Kafka 時，每個叢集的版本、配置、監控、備份策略都不同。運維知識散落在各團隊，沒有共享的 runbook 或值班流程。某個團隊的 Kafka 出問題時，其他團隊幫不上忙；知識在人員流動時遺失。

碎片化的另一個後果是資源浪費。每個團隊各自預留的容量加總起來遠大於集中管理所需。低流量團隊的叢集常年使用率低於 10%，但因為自管模式下沒有共享容量的機制，資源無法調配。

Topic 爆炸與無主 topic

沒有 topic 建立的治理流程時，任何人都可以建 topic。Topic 的命名不一致、retention 設定不一致、owner 不明。離職的工程師建立的 topic 仍在接收資料、佔用 broker 資源，但沒人知道這些 topic 服務什麼業務。

LinkedIn 後來也遇到同樣的問題並開發了 TopicGC 做 topic 生命週期管理。Uber 的解法路線類似 — 把 topic 建立變成需要 owner、retention policy 跟業務標籤的審核流程。

故障排查的責任不清

叢集內的故障（broker OOM、partition leader 不均衡、consumer lag spike）需要 Kafka 專業知識排查。團隊自管模式下，每個團隊都需要一定程度的 Kafka 運維能力，但多數團隊的核心能力是業務邏輯而非 MQ 運維。

故障排查的慣性是「先問 Kafka 團隊有沒有人可以幫忙」— 但沒有正式的 Kafka 團隊，所以問的是「上次修過 Kafka 的那個人」。

解法：平台化

Uber 的解法是把 Kafka 從分散自管收斂到集中平台 — 一個專責的 Kafka platform team 統一管理所有叢集、提供標準化的使用介面。

多租戶治理

平台化的核心是多租戶模型 — 每個業務團隊是一個 tenant，tenant 有 quota（ingestion rate、partition 數量上限、retention 上限）跟 cost attribution。

Quota 的目的是防止單一 tenant 的爆量拖累整個平台。Cost attribution 的目的是讓 tenant 看到自己的用量跟成本，驅動合理使用。

標準化 topic 管理

Topic 的建立走 self-service portal — 團隊填寫 owner、業務用途、預估流量、retention 需求，portal 自動配置 topic 並建立監控。沒有 owner 的 topic 不允許建立；owner 離職時 topic 需要交接或標記為候選淘汰。

統一監控與值班

Platform team 統一監控所有叢集的 broker 健康（replication lag、under-replicated partitions、disk usage、CPU），提供共用的 dashboard 跟 alert。值班由 platform team 負責 broker 層面的問題，業務層面的問題（consumer 設計錯誤、message 格式不對）由各 tenant team 自行處理。

取捨

平台化的最大風險是共享平台成為單點 — broker 故障影響所有 tenant。Uber 用跟 LinkedIn 類似的分層叢集策略（critical vs best-effort）降低共享風險，但這也讓平台的運維複雜度上升。

回寫教材的連結

• 3.1 broker basics：broker 容量規劃跟 topic 管理的基礎。
• 6.14 dependency reliability budget：共享 Kafka 平台作為 dependency，tenant team 的 reliability budget 怎麼計算。
• 3.4 consumer design：平台化後 consumer 設計的規範跟限制。
• 4.15 cost attribution：平台成本歸因到 tenant 的做法。

判讀徵兆

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

• 組織內有 3 個以上團隊各自架設 Kafka、版本跟配置不統一
• Topic 數量持續增長但沒人能說清楚哪些 topic 還在用
• 故障排查依賴特定個人而非共用的 runbook
• 叢集資源利用率低但各團隊仍要求擴容
• 管理層問「Kafka 總共花多少錢、誰在用」但沒人能回答

引用源

• Building Uber’s Kafka Infrastructure

對「GCP 生態事件分發、跨 region 全球路由、push HTTP endpoint 接收事件、Dataflow streaming」這條路徑、Pub/Sub 是首選。本頁先給最短路徑、再展開日常 topic / subscription 操作與 ack deadline 設計、最後進階治理（ordering、DLT、push endpoint、IAM）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 gcloud CLI 建 topic / subscription、publish / pull 訊息
2. 區分 push vs pull subscription、選擇對應的 delivery 模型
3. 設計 ack deadline 與 ackExtension、處理長任務
4. 配置 dead-letter topic 與 retry policy
5. 評估 ordering key、Pub/Sub Lite、BigQuery subscription 等延伸場景

最短路徑：5 分鐘把 Pub/Sub 跑起來

1# 1. 建 topic
2gcloud pubsub topics create demo-topic
3
4# 2. 建 subscription（pull 模式、綁定 topic）
5gcloud pubsub subscriptions create demo-sub --topic=demo-topic
6
7# 3. publish + pull 驗證
8gcloud pubsub topics publish demo-topic --message="hello"
9gcloud pubsub subscriptions pull demo-sub --auto-ack

最短路徑驗證「topic / subscription 建得起來、能發能收」。實際應用見日常操作。指令對真實 GCP 需設定 project 與認證；本機要先驗證可啟動 Pub/Sub emulator、用 gcloud config set api_endpoint_overrides/pubsub 把同一組 CLI 指向 emulator 跑通。

日常操作與決策形狀

gcloud CLI 與 client library

子議題：

• gcloud CLI 指令對照表（topics / subscriptions / publish / pull / ack）
• Client library 配置：credentials / flow control / async vs sync
• Batch publish（提高吞吐、增加延遲的取捨）
• 對應指令範例：gcloud pubsub subscriptions describe <sub>

Topic / Subscription 設計

Topic 是 first-class entity、跟 Kafka 不同的是 subscription 才是 consumer 抽象：

• 1 topic ↔ N subscription（fan-out 內建）
• Subscription 各自進度（無 consumer group 概念）
• Subscription expiration policy（閒置 N 天自動刪）

Push vs Pull subscription

子議題：

• Push：Pub/Sub 主動 POST 到 HTTP endpoint、適合無狀態 worker / Cloud Run
• Pull：consumer 主動拉取、適合長 worker / 需要 flow control
• Push endpoint 要求（HTTPS、認證）
• 兩者的可靠性 / latency / cost 對照

Ack deadline 與 ack extension

子議題：

• Ack deadline：subscription 等待 ack 的時間（預設 10 秒、上限 600 秒）
• Modify ack deadline（長任務動態延長）
• Client library 的自動 ack extension
• 跟 SQS visibility timeout 的對照（語意類似、機制不同）

進階主題（按需閱讀）

ordering key、dead-letter topic 與 schema enforcement 已展開為 deep article：ordering key / DLT / schema enforcement、push / pull / ack flow control。下列子議題段保留選題判讀入口。

Ordering key

子議題：

• 啟用 ordering 的限制（subscription 設定 enableMessageOrdering）
• Ordering 在 push 跟 pull 的差異
• 跟 Kafka partition + key 的對照
• 性能影響（throughput 受限）

Dead-letter topic

子議題：

• 設定 max delivery attempt、超過送到 DLT
• DLT 是另一個 topic、可以再訂閱重處理
• 跟 SQS DLQ 的差異（DLT 是 topic、不是 queue）

Pub/Sub Lite

子議題：

• Pub/Sub Lite vs Pub/Sub（partition-based、zonal、cost 低）
• 何時用 Lite（高吞吐、確定 region）
• 何時用 standard（global routing 內建）

BigQuery subscription / Cloud Storage subscription

子議題：

• BigQuery subscription：訊息直接寫入 BQ table（無需 Dataflow）
• Cloud Storage subscription：訊息批次寫入 GCS object
• 適合 streaming analytics / data lake 場景

Schema enforcement

子議題：

• Topic 綁定 schema（Avro / Protobuf）
• Schema evolution
• 跟 Kafka Schema Registry 的對照

IAM / Service Account

子議題：

• Pub/Sub IAM role（publisher / subscriber / viewer）
• Service Account 認證（push endpoint 用）
• VPC Service Controls

排錯快速判讀

Subscriber backlog（unacked messages 累積）

操作原則：先看是 push 還是 pull、再定位 endpoint 失敗 vs flow control 限制。

1gcloud pubsub subscriptions describe <sub>
2# 看 ackDeadlineSeconds（預設 10s）與 messageRetentionDuration（預設 604800s / 7 天）是否符合處理時間與 replay 需求

判讀：Cloud Monitoring metric 的 num_undelivered_messages 與 oldest_unacked_message_age。

Push endpoint 500（retry storm）

操作原則：push endpoint 持續 500、Pub/Sub 會 backoff retry、看 retry policy 設定。判讀：endpoint 健康 vs 訊息毒性。

Ordering key 限制誤用

操作原則：啟用 ordering 後 throughput 變低、單一 ordering key 是順序的。判讀：throughput 是否被 ordering 限制、可拆 ordering key。

IAM 權限錯

操作原則：publish / pull / ack 各自需要不同 IAM role。判讀：用 Cloud Logging 看 deny 原因。

Subscription expired

操作原則：閒置太久 subscription 被 GC。判讀：subscription expiration policy 設定 + 監控 lastReceiveTime。

何時改走其他服務

不在本頁內的主題

• Dataflow / BigQuery 完整功能（另開 streaming analytics 章節）
• Cloud Run / Functions 整合細節
• 各語言 client 完整 API

案例回寫

Pub/Sub 專屬案例（C60-C69）

跨 vendor 對照

IAM + Service Account 缺直接 customer engineering case：customer engineering blog 著墨少、建議撰寫該段時依 GCP 官方 IAM 文件 + 通用安全原則。

下一步路由

• 上游概念：0.3 非同步選型、3.1 broker basics
• 平行 vendor：AWS SQS、Kafka
• 下游能力：3.4 consumer 設計、6.12 idempotency / replay

Event Contract

Event contract 的責任是定義 producer 發出的事實、consumer 能依賴的欄位，以及版本演進時的相容窗口。最小 contract 包含 event id、schema version、occurred time、producer、entity id、dedup key 與資料保護範圍。

event id 讓訊息可追蹤；schema version 讓版本演進可判斷；occurred time 讓 replay 可分時間窗；dedup key 讓 consumer 可去重；PII scope 讓事件能接到資料保護。

event id 支撐 incident timeline 與重複投遞判讀。schema version 支撐新舊 consumer 共存。occurred time 支撐 replay window 與對帳查詢。dedup key 支撐 idempotency。PII scope 支撐 audit 與資料保護。這些欄位先成立，broker retention 或 partition 設計才有可依附的語意。

Schema Compatibility

Schema compatibility 的責任是讓 producer 與 consumer 可以分批升級。新增欄位要保留 optional，移除欄位要有相容窗口，語意改變要用新 version 或新 event type。

序列化能解析是相容性的第一層。若欄位仍存在但語意改變，consumer 仍可能產生錯誤副作用。這類變更需要在 release gate 中驗證。

Replay Boundary

Replay boundary 的責任是限制重播範圍，避免修復動作擴大事故。Replay 要能指定 time range、tenant、partition、event type、schema version 與 downstream capacity。

replay window 要和 time range 與 query link 對齊，讓事後能回放當時重播的是哪一批事件。

Compensation

Compensation 的責任是處理副作用已經發生但結果不正確的情況。寄信、發票、付款通知與 webhook 都可能需要補償，重播是其中一種恢復方式。

補償前要先判斷副作用是否可逆、是否會通知使用者、是否需要人工審核。不可逆副作用要比可重播副作用更早接到 Incident Decision Log。

跨 broker 業務語意對映

跨 broker migration 的工程責任是維持業務語意對映、broker 吞吐是次要驗證項。同一份 event contract 在 Kafka、Pub/Sub、SQS、NATS 的對映概念不同、需要逐項校準。

對應 9.C9 Spotify Kafka → Pub/Sub Migration — Spotify 7500 萬用戶事件交付系統遷移、case 明確點出 Kafka 的 partition / offset / consumer group 對映成 Pub/Sub 的 subscription / ordering key / message attribute、需要校準業務語意而非直接搬。

典型概念對映差異（依據 9.C9 case 列出的三組對映展開、Pub/Sub 實際 API 細節為文章補充）：

• Partition (Kafka) 跟 Subscription (Pub/Sub)：Kafka partition 是物理分片 + 順序邊界；Pub/Sub subscription 是邏輯 fan-out、無物理分片概念。靠 Kafka partition 保證 per-key 順序的 consumer、遷到 Pub/Sub 改用 ordering key
• Offset (Kafka) 對映成 message attribute (Pub/Sub)：9.C9 case 原文對映方向；replay 模型差異上、Kafka offset 是位置指標、可任意回放到某個 offset；Pub/Sub 用 Snapshot + Seek API 達成類似 replay 能力、模型不同
• Consumer Group (Kafka) 跟 Subscription (Pub/Sub)：Kafka consumer group 內部 rebalance 自動分 partition；Pub/Sub subscription 自動分 message、語意接近但 rebalance 細節差異會影響 in-flight message 處理順序

遷移評估要驗證的業務語意：

• 順序保證：原系統靠 partition / consumer group 保證什麼順序、新系統能否複製
• Replay 模型：原系統 replay 方式、新系統的 replay 工具能否達成同範圍。replay window 上限由 idempotency 保留期反推、見 3.6 Replay 跟 Idempotency 共設計
• 失敗模式：consumer 故障時、原系統的 rebalance / redelivery 行為、新系統會不會差異

判讀重點：broker migration 屬語意對映工程、吞吐能力比較是次要驗證項。對應 3.3 outbox pattern 的「Broker 遷移階段流程」、實作面用 dual-write + shadow consume + cutover、驗證面靠 event contract 跟 replay 邊界做對帳。

跨模組路由

1. 與 03 內部：replay window 跟 idempotency 共設計回到 3.6 processing-recovery-semantics；broker 遷移階段流程回到 3.3 outbox pattern
2. 與 04 的交接：event contract 演進 + replay 邊界進 4.20 Observability Evidence Package
3. 與 06 的交接：event contract 跟 replay 驗證進 6.12 Idempotency 與 Replay 驗證 跟 6.23 Verification Evidence Handoff
4. 與 07 的交接：event payload 的 PII / audit 邊界進 7.4 data protection and masking

選型前判準

Broker 選型前要先回答：

1. event contract 是否能支援版本相容。
2. consumer 是否能用 dedup key 判斷重複。
3. replay window 是否能用查詢與指標證明。
4. 不可逆副作用是否有補償流程。
5. event payload 是否包含 PII 或 audit-sensitive 欄位。

這些問題決定後續要比較 broker retention、schema registry、DLQ、partition 與 replay 工具，並把吞吐放回服務語意下判讀。

實體服務討論承接點

實體 broker 文章要承接本篇的 event contract 與 replay boundary。Kafka 的長期 retention、RabbitMQ 的 routing 與 DLQ、SQS 的 visibility timeout、NATS JetStream 的 stream/consumer 模型，都要放回事件契約與重播邊界下判讀。

若事件需要長期 replay，後續文章要比較 retention、offset、partition 與 schema evolution。若事件主要是工作任務，後續文章要比較 visibility、ack、DLQ 與重試治理。若事件包含 PII 或高風險副作用，後續文章要比較 audit、encryption、access control 與補償流程。

下一步路由

要處理 outbox 與事件發布一致性，接著讀 3.3 outbox pattern 與發佈一致性。要處理 consumer 端去重與重播，接著讀 3.4 consumer 設計與去重。

觀察

LinkedIn 在 Kafka 維運中導入自動化治理，降低人工介入與恢復時間波動。

判讀

當叢集規模超過人力可及範圍，自動修復與治理工具會成為必要能力。

策略

1. 明確定義可自動修復的故障類型。
2. 將自動修復與人工升級條件分離。
3. 把修復過程納入可觀測證據鏈。

下一步路由

回 3.2 與 8.16。

引用源

• Automating Kafka Self-Healing at LinkedIn

服務路徑與語意分層

這條路徑是 order-service -> broker -> order-created-consumer -> invoice/email/search/webhook。Producer 把事件交給 broker 後，真正的業務完成要看 consumer 是否正確提交副作用。

這篇先固定三層語意：

1. Delivery semantics：訊息是否投遞與確認。
2. Processing semantics：副作用是否可承受重複與部分失敗。
3. Recovery semantics：故障後是否可重播並恢復一致。

ack/nack 成功只代表 delivery 進度，不代表發票與通知已完成。

Event Contract 與相容邊界

Event contract 的責任是讓 producer 與 consumer 在版本演進時仍可互通，且可被觀測與回放。

order_created 最小欄位：

1. event_id：全域唯一識別。
2. schema_version：事件版本。
3. occurred_at：事件發生時間。
4. order_id、tenant_id：業務定位。
5. idempotency_key：副作用去重鍵。
6. pii_scope：敏感欄位範圍。

版本演進採向後相容優先：新增欄位可選、舊欄位保留窗口。schema 演進前要先確認 consumer 端 fallback 解析邏輯存在，避免切版後整批進 DLQ。

Retry / DLQ / Quarantine

Retry 的責任是吸收暫時性故障，不把短暫抖動升級成事故。這條路徑使用有限重試 + backoff + jitter：

DLQ 的責任是隔離與診斷，不是永久儲存。重點是把異常訊息分群後對應修法，修完再定向回放。

Idempotency 與 Ack Timing

Idempotency 的責任是把 at-least-once 交付轉成可接受業務結果。副作用如發票、email、webhook 都要以 idempotency_key 做去重。

Ack timing 的原則是「核心副作用提交後再 ack」：

1. 先執行副作用或落地可追蹤結果。
2. 成功後寫去重紀錄或 checkpoint。
3. 最後 ack broker。

先 ack 再副作用會造成資料遺失；副作用成功但去重紀錄失敗，則要由 recovery 層補償。

Replay Runbook

Replay 的責任是故障後在可控範圍內恢復，不把修復變成第二次事故。

這條路徑的 replay runbook：

1. 選定 replay window：依 occurred_at 與 schema_version 分段。
2. Dry run：先在影子通道跑去重與下游容量驗證。
3. 限速回放：按 tenant 或 partition 分批，監控下游錯誤率。
4. Reconciliation：對帳發票、通知、索引結果。
5. Stop condition：duplicate side-effect、downstream timeout、DLQ 再爆發即停。

replay window 要能被明確描述與回放，不可用「重播昨天全部」這種不可驗證句子。

Job queue 的拓樸分工

當背景工作同時要 高吞吐 跟 快速反應、單一通道模型會變成瓶頸。job queue 的擴展通常是 拓樸重整、把不同工作類型切到不同傳遞路徑、而非單點替換。

對應 3.C5 Slack Job Queue 演進到 Kafka + Redis — Slack 在 job queue 擴展時把工作切到不同傳遞路徑、Kafka 跟 Redis 分別承擔持久性跟即時性目標、分開治理 lag、重試跟失敗重播。

拓樸分工的判讀（基於 Slack case 揭露的雙通道分工方向）：

• 持久性主導的 job（發票、付款通知、合規記錄）→ Kafka / 持久 queue、保證 at-least-once
• 即時性主導的 job（線上提醒、playback control、UI 更新）→ Redis / 輕量 queue、low latency

設計含義：同一 consumer 應專注單一目標（高吞吐 / 即時 / 持久擇一）、其他目標拆到對應路徑。對應 3.4 consumer-design 三個工程議題鐵三角 — idempotency / 重播流程 / 下游承載能力是 consumer 內部設計、拓樸分工是 跨 consumer 的責任拆分、兩者互補。

Job queue 規模差異的治理重點

不同規模服務的 job queue 治理問題差異大、SSoT 在本章。對應 3.C10 對照：規模差異下的佇列模型：

• 小型服務：優先用 managed queue（SQS / Pub/Sub）、運維成本最低。最容易忽略的是語意邊界（重試次數、死信規則、重播責任）、規模一上來會出現資料重複與漏處理。升級訊號：team 數超 3-5 個、各自寫 consumer 開始出現 idempotency 不一致、進中型階段
• 中型服務：常見問題是 lag 與 DLQ 長期累積。原因是 consumer idempotency + 重播流程 + 下游承載能力沒一起設計。對應前段 Job queue 拓樸分工。升級訊號：DLQ 累積速度高於排空速度連續 7 天、單一 tenant 流量尖峰拖垮其他 tenant、進大型階段
• 大型服務：需要處理跨租戶跟跨區壓力。單叢集思維會讓任何一類流量尖峰拖垮整體。對應 3.C4 LinkedIn Tiered Clusters 跟 3.1 broker-basics 分層治理平台、重點從「怎麼送訊息」轉成「怎麼隔離失敗」

判讀重點：當前服務規模決定要處理的 主要 問題。規模尚小的服務硬上 multi-tenant 隔離治理屬過度設計、規模化服務應同時考慮 broker 容量是否充足跟隔離邊界是否完整。判斷自己在哪個階段、看 升級訊號 對應的指標。

Evidence Package

Queue evidence 的責任是證明「投遞可達」與「處理可恢復」兩者同時成立。

這份 evidence 要對齊 4.20 Observability Evidence Package 與 6.23 Verification Evidence Handoff。

Release Gate

Queue release gate 的責任是決定是否擴大回放或恢復主通道，而不是只看單一 lag 指標。

這組欄位對齊 6.12 Idempotency 與 Replay 驗證 與 6.8 Release Gate。

Incident Decision Log

pause consumer、drain DLQ、啟動 replay、停止 replay、執行補償都屬事故決策，需寫入 8.19 Incident Decision Log。

 1incident_decision:
 2  timestamp: 2026-05-11T13:18:00Z
 3  decision: "pause invoice consumer and start scoped replay for tenant A"
 4  context: "duplicate invoices increased after consumer version rollout"
 5  evidence:
 6    - query: duplicate_invoice_ratio_tenant_a
 7    - query: dlq_events_by_schema_version
 8  owner: queue-incident-commander
 9  expected_effect: "stop duplicate side effects and restore invoice consistency"
10  rollback_condition: "duplicate ratio does not decrease within two replay batches"

Case Write-back 與邊界

這篇回寫對齊 3.C9 反例，重點是切換時語意分層混淆導致 delivery 成功但業務結果失真。

這篇不處理同步 API latency、cache TTL 或 deployment drain。若風險在同步交易壓力、快取失效或流量切換，路由到 4.22 Checkout API Evidence Package、2.9 Cache Migration 與 Stampede Rollback 或 5.8 Deployment Rollout with Drain and Rollback。

觀察

Cloudflare Queues 以邊緣網路為背景，提供事件傳遞與 consumer 處理能力。

判讀

全球部署下，queue 模型要同時考慮延遲、重試語義與跨區運維一致性。

策略

1. 明確設定 delivery semantics 與重試策略。
2. 把 consumer 行為與死信處理流程標準化。
3. 將 queue lag 與失敗率接入平台觀測。

下一步路由

回 3.4 與 4.11。

引用源

• Introducing Cloudflare Queues

事故長相

切換 broker 或 consumer group 後，表面上訊息仍然被送達，但業務資料開始出現重複扣款、重複寄信、狀態漏更新這類問題。這種事故很難只靠 queue depth 判斷，因為錯誤發生在「處理語義」而不是「是否有訊息」。

為什麼會擴大

舊系統若依賴特定 offset 行為、重試節奏或 consumer idempotency，新系統即使名稱上提供相近 delivery semantics，也可能在失敗重播時產生不同結果。語義誤配會沿著下游資料寫入擴散。

回退判讀

回退前要先確認哪一段資料已經被新語義處理過。若直接切回舊 broker，可能讓同一批事件再次被處理。更穩定的做法是先凍結新 consumer，保留 offset 對照與 replay 範圍，再決定補償或重播。

Queue 專屬告警條件

• 下游 reconciliation 同時出現重複與遺漏
• DLQ 激增且重播後仍回到相同錯誤
• consumer lag 下降但業務結果沒有收斂

下一步路由

回 3.4 與 6.10。

小型服務常見判讀

小型服務優先用 managed queue 往往最穩，因為運維成本最低。這時候最容易忽略的是語義邊界：重試次數、死信規則、重播責任如果沒先定義，規模一上來就會出現資料重複與漏處理。

中型服務常見判讀

中型服務常見問題是 lag 與 DLQ 長期累積。根因通常是 consumer idempotency、重播流程、下游承載能力沒有一起設計，broker 效能本身很少是單點問題。

大型服務常見判讀

大型服務需要處理跨租戶與跨區壓力。此時若還用單叢集思維，任何一類流量尖峰都會拖垮整體。重點會從「怎麼送訊息」轉成「怎麼隔離失敗」。

這個情境的專屬告警條件

• consumer lag 連續超出 SLO 窗口
• DLQ 速率上升且無法在固定時間內回收
• 重播後仍出現相同失敗模式

出現上述條件應先凍結切換，回到前一語義設定，再逐步修正 consumer 契約與重播流程。

本文是跨 vendor migration playbook、cross-link 到 AWS SQS 跟 Google Pub/Sub。這是一個 跨雲 managed-to-managed 遷移：兩端都是 cloud-managed、運維負擔都低、但 資料拓樸 跟 消費抽象 不同 — SQS 是 region-scoped 的單一 pull queue、Pub/Sub 是 global topic + 多個 first-class subscription。主結構走 operational redesign hybrid（Type C）、額外為 components / data topology 兩個高維度抽獨立段。

SQS 跟 Pub/Sub 不是同一種訊息抽象

SQS 跟 Pub/Sub 都是 cloud-managed 非同步訊息服務、都解「解耦 producer / consumer、不自管 broker」這個問題、application 程式碼裡都是「發訊息、收訊息、處理完確認」的形狀。從這層看兩者可互換、遷移像是換 SDK。

差別在 消費抽象 跟 資料拓樸。SQS 的核心實體是 queue：一條 region-scoped 的訊息隊列、訊息被一個 consumer 領走（in-flight）就對其他 consumer 隱形、處理完 DeleteMessage 就消失。要讓同一筆事件送給多個下游、SQS 端的做法是在 SNS 前面 fan-out、再各接一條 SQS queue。Pub/Sub 的核心實體是 topic + subscription 兩層：topic 收訊息、subscription 是 first-class 的消費端點、一個 topic 可掛 N 個 subscription、每個 subscription 各自維護消費進度、fan-out 是模型內建而不是外接。

這個差別決定了遷移的形狀。如果原系統只是「一條 queue、一群 worker 競爭領取」、那 Pub/Sub 端是「一個 topic、一個 pull subscription」、對位乾淨、application 改動小。如果原系統靠 SNS-to-many-SQS 做扇出、那 Pub/Sub 端是「一個 topic、多個 subscription」、整個 fan-out 拓樸要重畫、這不是換 SDK、是重設計訊息流。先判斷自己屬於哪一種、再決定 playbook 的重量。

為什麼會跨雲遷這條路徑

跨雲從 SQS 遷到 Pub/Sub 的 driver 跟同雲 vendor 切換不同、通常不是「Pub/Sub 比 SQS 好」、而是 整體 workload 的重心移到 GCP：

1. 資料平台落在 GCP：下游分析走 BigQuery、streaming 走 Dataflow、容器跑 Cloud Run。事件如果留在 AWS、每筆都要跨雲搬到 GCP 才能進 BigQuery、跨雲 egress 費用跟延遲都是常態成本。把訊息層也移到 Pub/Sub、事件可以用 BigQuery subscription 直接落地、省掉中間搬運。
2. 需要 global topic、不想管 region：SQS queue 綁 region、跨 region 要自己複製或在前面架路由。Pub/Sub topic 沒有 region 概念、publish 進去全球可訂閱、多區域服務的事件分發是 first-class。
3. fan-out 從外接變內建：原本靠 SNS + 多條 SQS 維護的扇出拓樸、在 Pub/Sub 是「一個 topic 掛多個 subscription」、少一層 SNS、扇出關係在 subscription 列表一覽。

這三條 driver 都假設 重心已經或即將在 GCP。如果系統長期紮根 AWS、只為了「換個 queue」跨雲、會付出跨雲 IAM 重對位、雙雲計費、跨雲網路延遲的代價、ROI 通常不成立。遷移前先確認 driver 是 workload 重心轉移、不是單純偏好。

結構為什麼是 operational hybrid 加兩個高維度獨立段

寫這篇前先跑 diff dimension audit、6 維評級如下：

主導維度是 operational model（跨雲身份與監控全換）、所以主結構走 Type C operational redesign hybrid。但 components 跟 data topology 也是 High — 不是把它們塞進 operational 段就能講清楚的、消費抽象從「一條 queue」變「topic + 多 subscription」是讀者最容易踩雷的地方。按 migration 方法論的 multi-axis 規則、高維度抽成獨立段補充、不硬塞進單一 type 標籤。所以本篇結構是：operational 對位主軸 + 「消費抽象重設計」獨立段（components / topology 軸）+ 跨雲特有的 IAM 與網路段。

Operational 對位：機制名詞換、語意要逐一確認

跨雲遷移最容易出錯的環節、是 找到語意相近的功能、卻假設行為一致。SQS 跟 Pub/Sub 多數機制都有對位、但每一組都有行為差、找得到對應功能只是第一步。下表先給對照、後面逐項展開語意陷阱。

Visibility timeout → ack deadline

Visibility timeout 跟 ack deadline 都回答同一個問題：consumer 領走訊息後、多久沒確認就視為失敗、把訊息重新投遞。語意對位成立、但兩端的數字與延長機制不同。

SQS visibility timeout 預設 30 秒、上限 12 小時、consumer 要延長就主動呼叫 ChangeMessageVisibility。Pub/Sub ack deadline 預設 10 秒、上限 600 秒（10 分鐘）、而且 client library 預設會 自動 在背景延長 deadline（lease management）。這個自動延長是最容易踩到的差異：在 SQS 端習慣「設一個夠長的 visibility timeout、處理完再 delete」、搬到 Pub/Sub 如果只把 ack deadline 設成 600 秒上限、卻沒意識到 client library 在背景幫忙延長、長任務的行為會跟預期不同；反過來、如果關掉自動延長又設了預設 10 秒、處理稍久就重投。對位的正確做法是先理解 client library 的 lease 行為、再決定 ack deadline 跟 MaxAckPending、而不是把 SQS 的 timeout 數字直接搬過去。

maxReceiveCount / redrive → dead-letter topic

兩端都用「重試 N 次仍失敗就隔離」防止 poison message 阻塞 pipeline、但隔離後的容器不同。SQS 的 DLQ 是另一條 queue、用 maxReceiveCount 控制門檻、修好下游後用 redrive policy 把訊息放回原 queue。Pub/Sub 的 dead-letter topic 是另一個 topic、用 subscription 的 max delivery attempt 控制門檻、超過就 publish 到 DLT。

差別在重處理路徑。SQS redrive 是把 DLQ 訊息搬回 main queue、是一個 queue-to-queue 的搬移動作。Pub/Sub 的 DLT 是 topic、要重處理得在 DLT 上再開一個 subscription 來消費、沒有內建的「放回原 topic」按鈕。Mercari item feed 的案例就是用 DLT 把重試多次仍失敗的訊息隔離、讓後續訊息優先處理、同時把 topic 當突發流量的 load-leveling buffer。從 SQS 搬過來時、redrive 的心智模型要換成「DLT 是一個獨立 topic、重處理是另開 subscription」、不是「按一個按鈕放回去」。設定 DLT 還需要給 Pub/Sub service account 對 DLT 的 publisher 權限跟對原 subscription 的 subscriber 權限、漏設會讓訊息卡住不進 DLT。

Long polling → streaming pull

這一組不是等價對位、是機制不同。SQS long polling 是 consumer 發一個 ReceiveMessage 請求、最多等 20 秒、有訊息就回、沒有就空回、本質仍是 輪詢、只是把空輪詢的頻率降下來省 cost。Pub/Sub 的 pull 在 client library 預設是 streaming pull：consumer 跟 Pub/Sub 建一條長連線、訊息一到就推過來、不是 consumer 反覆問。

對位時不要把 long polling 的「WaitTimeSeconds 20 秒」翻譯成某個 Pub/Sub 參數 — 沒有對應參數、因為機制不同。要關注的是 flow control：streaming pull 因為訊息會主動推來、要用 MaxOutstandingMessages / MaxAckPending 控制同時在處理的訊息量、否則 consumer 會被一次塞太多訊息壓垮。SQS 端「一次拉最多 10 條」的批次節流、在 Pub/Sub 端變成 flow control 設定。Spotify autoscaling 的案例揭露了相關陷阱：下游失敗時 consumer 不 ack 仍持續消耗 CPU、autoscaling 反而把資源越拉越高 — autoscale 訊號要看處理成功率、不是 backlog 加 CPU。

IAM policy → Service Account

跨雲遷移裡、身份模型是 重對位 而不是改語法的部分。SQS 的存取控制是 IAM policy（identity-based、掛在 user / role）加 queue policy（resource-based、掛在 queue）兩層、cross-account 靠這兩層互動。Pub/Sub 是 GCP IAM role（publisher / subscriber / viewer 等）加 Service Account、push subscription 要用 Service Account 認證到目標 endpoint。

兩套身份模型沒有自動轉換工具、要逐條重畫：誰能 publish 對應誰有 topic 的 publisher role、誰能消費對應誰有 subscription 的 subscriber role。跨雲場景還多一層 — 如果遷移期 AWS 端的服務要 publish 到 GCP 的 topic、得用 workload identity federation 或 service account key、讓 AWS 的工作負載拿到 GCP 身份。這部分沒有 case 可引、依 GCP 官方 IAM 文件加最小權限原則設計：每個 service account 只給它實際需要的 role、不要為了遷移方便給 broad role 再說以後收緊、那個「以後」通常不會來。

CloudWatch → Cloud Monitoring

監控訊號要重建、不是改名。SQS 在 CloudWatch 看 ApproximateNumberOfMessagesVisible（queue 深度）跟 ApproximateAgeOfOldestMessage（lag）。Pub/Sub 在 Cloud Monitoring 看 num_undelivered_messages（backlog）跟 oldest_unacked_message_age（最老未確認訊息年齡）。語意相近、但 alarm 邏輯要重寫、而且 Pub/Sub 的 backlog 數字要配合 subscription 維度看 — 同一個 topic 的不同 subscription 各自有 backlog、一個堵住不代表全部堵住。遷移時要把原本對 queue 深度的告警、改成對每個 subscription 的 backlog 與 age 告警。

消費抽象重設計：從一條 queue 到 topic 加多 subscription

這是 components 跟 data topology 兩個高維度的核心、也是從 SQS 搬到 Pub/Sub 最需要重新畫圖的地方。SQS 的世界裡、一條 queue 對應一群競爭領取的 worker；要扇出就在前面架 SNS、SNS 後面接多條 SQS、每條 queue 各一群 worker。Pub/Sub 把這個拓樸壓平：一個 topic 收訊息、掛多少個 subscription 就有多少條獨立的消費流、每個 subscription 各自記進度、彼此不影響。

重設計從盤點現有拓樸開始。先列出：哪些是「單一 queue、一群 worker」的簡單情境、哪些是「SNS fan-out 到多條 SQS」的扇出情境。簡單情境對位乾淨 — 一個 topic、一個 pull subscription、原本競爭領取的 worker 改成同一個 subscription 的多個 consumer、Pub/Sub 自動把訊息分給它們。扇出情境要把 SNS + 多 SQS 換成「一個 topic + 多 subscription」、原本每條 SQS queue 變成一個 subscription、SNS 那一層消失。

扇出情境裡有個方向相反的陷阱要避免：不要把「多個下游」誤設計成「多個 consumer 共用一個 subscription」。同一個 subscription 的多個 consumer 是 競爭 關係、訊息只會給其中一個 — 那是負載分攤、不是扇出。要每個下游都收到完整一份、就要每個下游一個 獨立 subscription。這跟 SQS 端「一條 queue 一個下游、扇出靠 SNS 複製」的直覺方向一致、但實體換了：在 SQS 是多條 queue、在 Pub/Sub 是多個 subscription。畫遷移圖時、SQS 的每條 fan-out queue 一對一映射到 Pub/Sub 的一個 subscription、不要合併。

Application 重設計範例：SQS receive-delete 換成 Pub/Sub pull-ack

 1// SQS 端：long polling receive、處理完 DeleteMessage
 2svc := sqs.NewFromConfig(cfg)
 3for {
 4    out, _ := svc.ReceiveMessage(ctx, &sqs.ReceiveMessageInput{
 5        QueueUrl:            &queueURL,
 6        MaxNumberOfMessages: 10,
 7        WaitTimeSeconds:     20, // long polling
 8    })
 9    for _, m := range out.Messages {
10        process(m.Body)
11        svc.DeleteMessage(ctx, &sqs.DeleteMessageInput{
12            QueueUrl:      &queueURL,
13            ReceiptHandle: m.ReceiptHandle,
14        })
15    }
16}

1// Pub/Sub 端：streaming pull、處理完 Ack、用 flow control 節流
2sub := client.Subscription("orders-sub")
3sub.ReceiveSettings.MaxOutstandingMessages = 100 // flow control、取代「一次拉 10 條」
4err := sub.Receive(ctx, func(ctx context.Context, msg *pubsub.Message) {
5    process(msg.Data)
6    msg.Ack() // 取代 DeleteMessage；client library 在背景自動延長 ack deadline
7})

差異：

• SQS 主動輪詢（ReceiveMessage 迴圈）→ Pub/Sub 回呼模型（Receive 把訊息推進 callback）
• SQS DeleteMessage → Pub/Sub msg.Ack()、語意都是「確認處理完、別重投」
• SQS WaitTimeSeconds 控制輪詢等待 → Pub/Sub MaxOutstandingMessages 控制 flow control
• SQS 一次最多 10 條的批次上限 → Pub/Sub 沒有這個上限、改用 flow control 設同時在途量
• ack deadline 的延長在 SQS 要主動 ChangeMessageVisibility、在 Pub/Sub 由 client library 自動處理

application 邏輯的商業處理部分（process 函式）多數可保留、改動集中在收訊息的框架跟確認語意、估計 20-40% 程式碼。

Production 故障演練

Case 1：fan-out 設計成共用 subscription、下游各收到一部分

徵兆：把原本 SNS fan-out 到 3 條 SQS 的拓樸搬到 Pub/Sub、為了省事建一個 topic + 一個 subscription、讓 3 個下游服務都連這個 subscription。上線後發現每個下游只收到大約三分之一的訊息、不是各收完整一份。

根因：同一個 subscription 的多個 consumer 是負載分攤關係、Pub/Sub 把訊息分給其中一個 consumer、不是每個都送。這對應到 SQS 端「一條 queue 多個 worker 競爭領取」的行為、但被誤用在需要扇出的場景。SQS 端的扇出靠 SNS 複製訊息到多條 queue、那個複製動作在 Pub/Sub 應該由「多個 subscription」承擔、不是多個 consumer 共用一個 subscription。

修法：

1. 每個下游一個獨立 subscription：3 個下游就建 3 個 subscription 掛同一個 topic、每個各收完整一份
2. 遷移圖一對一映射：SQS 的每條 fan-out queue 對應一個 Pub/Sub subscription、不合併
3. 負載分攤跟扇出分開設計：同一下游要多 worker 分攤、是同一 subscription 多 consumer；不同下游各收一份、是多 subscription

Case 2：ack deadline 沿用 SQS 數字太短、長任務反覆重投

徵兆：SQS 端 visibility timeout 設 5 分鐘跑得好好的、搬到 Pub/Sub 隨手把 ack deadline 設成預設或一個小數字、結果處理時間稍長的訊息被反覆重投、同一筆訊息處理多次、下游出現重複副作用。

根因：Pub/Sub ack deadline 預設 10 秒、上限 600 秒、跟 SQS visibility timeout 上限 12 小時差很多。如果關掉 client library 的自動 lease extension、又把 ack deadline 設小、處理時間一超過就被判定失敗重投。SQS 的「設一個夠長的 timeout」直覺搬過來不適用、因為 Pub/Sub 的上限低很多、且延長機制是 client library 自動做。

修法：

1. 理解 client library 的 lease 行為：多數 client library 預設會背景自動延長 ack deadline 到處理完、優先依賴這個而不是手動設超長 deadline
2. 長任務拆短或改架構：單筆處理超過 10 分鐘上限的、考慮拆成多階段或把長任務移出訊息處理路徑
3. 下游做 idempotency：跟 SQS 一樣、Pub/Sub 是 at-least-once、重投本來就會發生、下游用 message ID 去重才是根本解

Case 3：FIFO 順序需求對位到 ordering key、吞吐落差超出預期

徵兆：原系統用 SQS FIFO queue + MessageGroupId 保證同一群訊息順序處理、搬到 Pub/Sub 啟用 ordering key 對位、上線後吞吐比預期低很多、且某些情境順序仍亂。

根因：SQS FIFO 跟 Pub/Sub ordering key 都提供順序、但取捨點不同。SQS FIFO 同時給「順序」跟「5 分鐘去重窗口」、吞吐受限（每 MessageGroupId 串行）。Pub/Sub ordering key 給「同一 key 的訊息按 publish 順序送達」、但要 publish 端跟 subscription 端都正確設定（publish 要設 ordering key、subscription 要 enableMessageOrdering）、漏一邊順序就不保證；而且啟用 ordering 後同一 key 串行、吞吐同樣受限。把 FIFO 的「去重 + 順序」一包功能、誤以為 ordering key 也一包提供、是落差來源。

修法：

1. 拆開「順序」跟「去重」兩個需求：Pub/Sub ordering key 只管順序、去重要 application 端自己用 message ID 做
2. publish 跟 subscription 兩端都設 ordering：缺一邊順序不保證、遷移檢查清單要把兩端都列上
3. 重新評估是否真需要全域順序：FIFO 常被過度使用、很多場景只需要 per-entity 順序、用 ordering key 按 entity 分 key、比強制全域串行吞吐高很多

Case 4：跨雲遷移期雙雲都在跑、egress 成本與延遲被低估

徵兆：漸進 cutover 期間 AWS 跟 GCP 兩邊都在處理訊息、為了對帳把訊息在兩雲之間搬、月底帳單跨雲 egress 費用遠超預估、且跨雲呼叫的尾延遲拖慢端到端處理。

根因：SQS 在 AWS region 內、Pub/Sub 在 GCP、遷移期的 dual publish 或對帳如果讓資料反覆跨雲、每一筆出 AWS 的訊息都計 egress 費。跨雲不只是錢、跨雲網路的延遲跟抖動比同雲高、放在同步處理路徑上會放大尾延遲。同雲 vendor 切換沒有這個維度、跨雲遷移必須把它列進成本模型。

修法：

1. 縮短雙雲並行窗口：dual publish 的對帳期越短越省、設明確的並行截止日、不要無限期雙跑
2. 對帳用抽樣不用全量搬運：驗證一致性用抽樣比對 message ID / count、不要把所有訊息都搬到對面雲比對
3. 生產者就近落點：遷移後讓 producer 直接 publish 到 Pub/Sub、不要繞 AWS 再跨雲、消除穩態的跨雲 egress

Case 5：dead-letter topic 權限沒配齊、毒訊息卡住不進 DLT

徵兆：subscription 設了 dead-letter topic 跟 max delivery attempt、預期重試超限的訊息進 DLT、實際上毒訊息一直在原 subscription 反覆重投、DLT 是空的、後續訊息被堵。

根因：Pub/Sub 要把訊息送進 DLT、是由 Pub/Sub 的 service account 代為 publish 到 DLT topic；同時它也要對原 subscription 有 subscriber 權限才能 ack 掉原訊息。這兩個權限漏任一個、forwarding 到 DLT 就失敗、訊息卡在原 subscription。SQS 端 DLQ 是 queue 屬性、不需要額外給 service 權限、所以這個跨雲差異容易被漏掉。

修法：

1. 配齊 DLT 雙權限：給 Pub/Sub service account 對 DLT topic 的 publisher role、跟對原 subscription 的 subscriber role
2. 遷移後做毒訊息演練：故意 publish 一筆會失敗的訊息、確認它真的在 max attempt 後進 DLT、不是卡在原 subscription
3. 監控 DLT backlog：DLT 開一個 subscription 監控其 num_undelivered_messages、確認毒訊息有被導流且有人處理、對照 Mercari DLT 案例的設計

漸進 cutover：dual publish 加雙消費對帳

跨雲遷移風險高、不適合一次切換、走漸進 cutover 把可逆邊界拉長：

1. Phase 0：拓樸盤點 — 列出所有 SQS queue、標記哪些是單一 queue、哪些是 SNS fan-out、各自映射到 Pub/Sub 的 topic / subscription 結構
2. Phase 1：Pub/Sub 端建好對位資源 — 建 topic / subscription / DLT、配齊 IAM 與 service account、重建 Cloud Monitoring 告警、application 寫好 Pub/Sub consumer 但先不收流量
3. Phase 2：dual publish — producer 同時 publish 到 SQS 跟 Pub/Sub、兩邊 consumer 都跑、Pub/Sub 端的處理結果先寫到隔離區或標記、不影響正式下游
4. Phase 3：雙消費對帳 — 抽樣比對兩邊處理的訊息 ID 與數量、確認 Pub/Sub 端沒漏、沒重複到無法接受的程度、ack deadline / fan-out / ordering 行為都符合預期
5. Phase 4：流量切換 — 對帳通過後、把正式下游切到 Pub/Sub 端、SQS 端轉成備援、保留一段觀察期可回切
6. Phase 5：下線 SQS — 觀察期穩定後停掉 dual publish、移除 SQS 資源、消除穩態跨雲 egress（這是不可逆階段、不要在對帳沒過時提前做）

對帳期是這套流程的核心保險、也是 Case 4 跨雲成本的來源 — 對帳用抽樣、並行窗口設明確截止日、平衡「驗證信心」跟「雙雲成本」。

Capacity / cost 對照

判讀：穩態成本兩者量級相近、真正的成本差在 遷移期 — dual publish 雙雲並行加跨雲對帳搬運是一次性高峰、不是穩態。把這段窗口縮短、是控制跨雲遷移成本的關鍵、不是去比 SQS 跟 Pub/Sub 的單價。扇出重度的系統遷到 Pub/Sub 後、少掉 SNS 那一層、扇出的計費結構也變簡單。

整合 / 下一步

遷移後事件可直接落 GCP 資料平台

遷到 Pub/Sub 的一個結構性好處、是事件可以用 BigQuery subscription 直接寫進 BigQuery、不需要再寫 Dataflow pipeline 搬運；或用 Cloud Storage subscription 批次落 GCS。這正是「workload 重心在 GCP」這條 driver 的回報 — 事件層跟資料平台同雲、省掉跨雲搬運。這也是評估是否該跨雲遷移時、要放進 ROI 的一邊。

跟 Kafka 遷移的結構對照

結論：SQS → Pub/Sub 不是 paradigm shift（兩端都是 cloud-managed 訊息服務、可收斂成單一目標）、是 operational redesign 為主、消費抽象重設計為輔的跨雲遷移；結構由主導差異維度（operational）決定主軸、高維度（components / topology）抽獨立段補充。

相關連結

• Source / target vendor：AWS SQS / Google Pub/Sub
• 平行 vendor：Kafka / RabbitMQ / NATS
• 平行 migration playbook：Kafka ↔ NATS
• 引用案例：3.C64 Mercari Item Feed DLT / 3.C61 Spotify autoscaling
• Methodology：Migration Playbook 寫作方法論
• 上游概念：0.3 非同步選型 / 6.12 idempotency / replay

本文是 Google Cloud Pub/Sub overview 的 implementation-layer deep article。選型層（Pub/Sub vs Kafka / SQS）見 overview；本文只處理「決定用 Pub/Sub 後，subscription 與 ack 怎麼設」。Pub/Sub 是 managed SaaS、無法本機 docker 驗證，本文 config 依 Pub/Sub 官方文件 與下列 production case、最後檢查日 2026-06-16；引數與計費以官方為準。

push vs pull 不是實作偏好

把 Pub/Sub 的 subscription 設成 push 還是 pull，常被當成「看團隊習慣」的實作選擇。但它其實是一個關於下游容量的判讀。差別在流量控制權在誰手上：push subscription 由 Pub/Sub 主動把訊息 HTTP POST 到目標 endpoint——流量節奏由 Pub/Sub 決定，尖峰時瞬間打過來；pull subscription 由 consumer 主動拉，要拉多少、多快由 consumer 自己控制。

Mercari 的 LINE 整合把這個判讀講得很具體：Braze webhook 進來轉成 Pub/Sub event，下游要呼叫 LINE API——而 LINE API 有 RPS 限制。如果用 push，Pub/Sub 會把訊息瞬間打到 worker、worker 再打 LINE、直接超過 LINE 的 RPS 上限。所以他們用 pull subscription，worker「精確控制每秒處理訊息數」來對齊 LINE 的限制。這個案例揭露的原則是——push vs pull 不是實作偏好，是「下游能不能承受 push 的流量衝擊」的判讀：下游有速率限制、處理能力有限、或需要平滑流量，就走 pull 自我節流。

本文展開 subscription 模型、ack deadline、flow control 與 dead-letter topic——這些決定了訊息怎麼被可靠地、以下游能承受的速度消費。

核心概念：subscription、ack deadline 與 flow control

Pub/Sub 把「topic（發布）」跟「subscription（訂閱）」分開，可靠消費的旋鈕都在 subscription 上。

一個 topic、多個 subscription、各自獨立。發布者發到 topic，每個 subscription 收到一份完整的訊息流、各自維護消費進度。這天然支援 fanout（多個服務各建一個 subscription）。Mercari 的另一個案例還揭露 topic 的雙重角色——它同時是「dispatch」跟「load-leveling buffer」，突發流量先進 topic 緩衝、consumer 按自己節奏消化。

ack deadline 是 Pub/Sub 版的可見性逾時。consumer 收到訊息後，有一段 ack deadline 來處理並 ack。在 deadline 內沒 ack，Pub/Sub 重新投遞（at-least-once）。跟 SQS visibility timeout 同樣是雙邊風險：太短→處理中就重投、太長→失敗後恢復慢。處理中可用 modifyAckDeadline（client library 通常自動 lease extension）延長。

flow control 限制 client 端同時持有的未 ack 量。pull subscription 的 client library 可設 max_outstanding_messages / max_outstanding_bytes——consumer 最多同時持有多少未 ack 訊息。這是 consumer 端自我節流的旋鈕，避免一次拉太多撐爆自己或下游。Mercari 對齊 LINE RPS 靠的就是這層控制。

dead-letter topic（DLT）給毒訊息出口。subscription 設 dead-letter policy（maxDeliveryAttempts + dead-letter topic）後，重投超過上限的訊息被轉到 DLT，不再阻塞後續。Mercari item feed 正是「重試多次仍失敗送 DLT、後續訊息優先處理」——避免 poison message 卡住 pipeline。

配置：subscription + ack deadline + DLT（依官方文件）

Pub/Sub 是 managed、以下 gcloud 依官方文件（未本機 docker 驗證、引數以官方為準）：

 1# 1. 建 topic + dead-letter topic
 2gcloud pubsub topics create orders
 3gcloud pubsub topics create orders-dlt
 4
 5# 2. pull subscription：ack deadline + dead-letter policy
 6gcloud pubsub subscriptions create orders-worker \
 7  --topic=orders \
 8  --ack-deadline=60 \
 9  --dead-letter-topic=orders-dlt \
10  --max-delivery-attempts=5
11
12# 3. consumer 端 flow control（client library、以 Python 為例、概念跨語言一致）
13#    flow_control = FlowControl(max_messages=100, max_bytes=10*1024*1024)
14#    subscriber.subscribe(sub_path, callback=handle, flow_control=flow_control)
15#    handle 內：處理成功 message.ack()、失敗 message.nack()
16
17# push subscription（僅當下游能承受 Pub/Sub 主動推的流量時）：
18# gcloud pubsub subscriptions create orders-push \
19#   --topic=orders --push-endpoint=https://my-svc/handler --ack-deadline=60

判讀：

• 下游有 RPS 限制 / 處理能力有限 → pull + flow control（self-throttle，Mercari 模式）
• 下游能吸收推送尖峰、要 serverless 簡單 → push
• ack-deadline 略高於處理時間；長任務靠 client library 的 lease extension
• max-delivery-attempts + DLT 給毒訊息出口

Production 故障演練

Case 1：用 push、下游被瞬間流量打爆

徵兆：流量尖峰時下游 endpoint 5xx 暴增、或下游的第三方 API 回 429（rate limited），訊息大量重投惡化。

根因：用 push subscription，Pub/Sub 把訊息瞬間 POST 到 endpoint，超過下游（或下游依賴的外部 API）的處理 / 速率上限。正是 Mercari LINE 要避開的情形。

修法：

1. 下游有速率限制改用 pull subscription + flow control，由 consumer 自我節流
2. flow control 的 max_outstanding_messages 對齊下游能承受的並發
3. push 只用在下游能吸收推送尖峰的場景
4. push 場景下游要自己擋（rate limit / 佇列），不能假設 Pub/Sub 會幫你平滑

Case 2：ack deadline 太短、訊息處理中就被重投

徵兆：同一則訊息被處理多次，尤其處理較慢時；訂閱的 redelivery 指標偏高。

根因：ack deadline 設得比處理時間短，訊息在處理途中 deadline 到期、Pub/Sub 重投。跟 SQS visibility timeout 太短同類。

修法：

1. ack deadline 設成略高於處理時間 p99
2. 用 client library 的自動 lease extension（modifyAckDeadline）處理長尾任務
3. 消費端冪等——at-least-once 本來就可能重投（見 6.12 idempotency）
4. 監控 redelivery 率，偏高代表 deadline 偏短或處理變慢

Case 3：沒設 DLT、毒訊息一直重投阻塞

徵兆：某則訊息一直失敗、一直被重投，後續訊息處理被拖慢。

根因：subscription 沒設 dead-letter policy。處理失敗（nack 或沒 ack）的訊息一再重投、沒有上限與出口，毒訊息反覆消耗 consumer。

修法：

1. 設 dead-letter policy（max-delivery-attempts + DLT），重投達上限轉 DLT
2. DLT 是另一個 topic，要有處理 / 告警流程（Mercari「送 DLT、後續訊息優先處理」）
3. max-delivery-attempts 平衡暫時性失敗重試與毒訊息隔離
4. 對照 SQS redrive：兩者都是 managed 原生 DLQ/DLT、比自建省事

Case 4：flow control 沒設、consumer 一次拉太多撐爆

徵兆：consumer 記憶體暴增 / OOM，或一次拉太多把下游打爆。

根因：pull subscription 沒設 flow control，client library 預設可能持有大量未 ack 訊息，consumer 端記憶體與下游壓力失控。

修法：

1. 設 max_outstanding_messages / max_outstanding_bytes 限制同時持有量
2. 對齊 consumer 處理能力與下游容量（Mercari 對齊 LINE RPS）
3. 監控 consumer 記憶體與未 ack 數，調 flow control 參數
4. flow control 是 pull 自我節流的核心，不設等於放棄背壓

Case 5：誤用 ordering key、吞吐受限

徵兆：開了 message ordering 後吞吐明顯下降、特定 ordering key 的訊息處理變慢。

根因：Pub/Sub 的順序保證是 per-ordering-key 的——同一個 ordering key 的訊息嚴格按序、必須序列處理（前一則 ack 才處理下一則）。把所有訊息塞同一個 ordering key 等於序列化整條流、吞吐崩。

修法：

1. ordering key 用細粒度（per-entity，如 per-user），讓不同 key 可並行
2. 不需要嚴格順序的就別開 ordering（預設無序、吞吐高）
3. 評估順序需求的真實範圍——多數場景只需 per-entity 順序，不是全域
4. 嚴格全域順序 + 高吞吐有本質衝突，重新審視需求或走 Kafka 的 partition 模型

Capacity / cost 邊界

Pub/Sub 的容量判讀（managed、無 broker 運維）：

撞牆後的路由判斷：

• 需要長期保留 + 任意 replay：Pub/Sub 有 retention（可設、seek 到時間點）但事件流長期 replay + 生態走 Kafka。
• 嚴格全域順序 + 高吞吐：Pub/Sub ordering 是 per-key 序列化，全域順序高吞吐走 Kafka partition 設計。
• 不在 GCP 生態：Pub/Sub 綁 GCP，跨雲走 Kafka / NATS 或對應雲的 managed（SQS）。
• 複雜 routing（topic exchange 式）：Pub/Sub 是 topic→subscription 扇出，複雜 routing 規則走 RabbitMQ exchange。

整合 / 下一步

push/pull 判讀與 ack 是 Pub/Sub 可靠消費的核心，它跟其他議題交織：

• 跟 3.4 consumer design：push/pull、ack deadline、flow control 是 consumer 設計的具體選項。
• 跟 6.12 idempotency / replay：at-least-once + 重投要求消費冪等。
• 跟 SQS visibility timeout：ack deadline 對應 visibility timeout、DLT 對應 redrive，兩個 managed queue 的可靠消費模型高度對位、可對照閱讀。
• 跟 webhook buffer 模式：Pub/Sub topic 當 load-leveling buffer（Mercari）對應 SQS Twilio webhook buffer——把不可控的外部 webhook 流量先緩衝再按自己節奏消化。

相關連結

• 上游 vendor 頁：Google Cloud Pub/Sub
• 對照 vendor：AWS SQS visibility timeout、RabbitMQ DLQ
• 對應案例：3.C65 Mercari LINE flow control、3.C64 Mercari item feed DLT
• 上游概念：3.4 consumer design

本文是 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 語義

本文是 NATS overview 的 implementation-layer deep article、定位在「要不要從 core NATS 跨進 JetStream」的決策入口。選型層（NATS vs Kafka / RabbitMQ）見 overview；本文只處理 core 與 JetStream 的邊界與基本 consumer 設定。決定採用 JetStream 後的完整實作（stream / consumer 每個旋鈕、跨區拓樸、多租戶）見 JetStream 設計與 supercluster / leaf node。JetStream 實機驗證於 nats:latest（-js）、最後檢查日 2026-06-16；機制以 NATS JetStream 官方文件 為準。

fire-and-forget 在 rolling deploy 那一刻掉訊息

Core NATS 的低延遲來自它什麼都不記——一則訊息發布出去，當下有訂閱者就送達、沒有就丟棄。沒有儲存、沒有 ack、沒有重送。這適合「即時但可丟」的場景（metrics、presence、即時通知）：訂閱者暫時離線錯過幾則無所謂，下一則馬上來。

但這個設計有一條清楚的邊界。Clarifai 用 NATS 跑 ML 模型訓練的非同步任務，任務從幾秒到幾分鐘，原本同步呼叫——結果每次 rolling deployment（pod 輪流重啟）就掉訊息：訊息發布的瞬間目標 worker 正在重啟，core NATS 找不到訂閱者就丟了。他們的解法是改用 NATS（當時是 NATS Streaming、JetStream 的前身）的 at-least-once delivery + redelivery + queue group，每日 100k+ 訊息、達成 100% uptime。這個案例揭露的邊界是——ML 長尾任務不能容忍 rolling deploy 掉訊息，core NATS 的 fire-and-forget 到此為止，要跨進 JetStream。

JetStream 在 core NATS 之上加了一層持久化的 stream + 可重送的 consumer。本文處理這條邊界：什麼時候 core 夠用、什麼時候要 JetStream、跨過去的 consumer 模型怎麼設才不會丟訊息或重投風暴。

核心概念：stream 與 consumer 的求值模型

JetStream 把「訊息儲存」跟「消費進度」拆成兩個獨立物件——stream（存什麼、留多久）跟 consumer（誰讀、怎麼 ack）。理解 JetStream 就是理解這兩者。

stream 決定訊息怎麼被儲存與保留。一個 stream 綁定一組 subject、把符合的訊息持久化。三個關鍵維度：storage（file 持久 / memory 重啟即失）、retention（limits 依大小/時間/數量保留、workqueue 消費後即刪、interest 有訂閱者才留）、limits（max-msgs / max-bytes / max-age）。retention 選錯是常見陷阱——workqueue 是「每則訊息只被一個 consumer 消費一次就刪」，limits 是「保留著、多個 consumer 各自讀」。

consumer 是 stream 上的一個可重播視圖。同一個 stream 可以有多個 consumer，各自維護自己的消費位置。consumer 的關鍵屬性：

• push vs pull：push 由 server 主動推給訂閱者；pull 由 client 主動拉（consumer next），pull 對流量控制與 worker pool 更可控
• durable vs ephemeral：durable consumer 的進度持久（重啟後從上次位置續讀），ephemeral 在 client 斷線後消失（進度丟失）
• ack policy：explicit（每則都要 ack、at-least-once 的基礎）/ all（ack 一則等於 ack 之前所有）/ none（不需 ack、近似 fire-and-forget）
• max_deliver + ack_wait：沒 ack 的訊息在 ack_wait 後重送，最多 max_deliver 次

at-least-once 來自「explicit ack + redelivery」。consumer 取出訊息、處理、明確 ack；沒 ack（處理失敗或 crash）的訊息在 ack_wait 逾時後重送。這就是 Clarifai 要的「rolling deploy 不丟訊息」——worker 重啟時沒 ack 的任務會被重送給其他 worker。

配置：durable pull consumer（實機驗證）

 1# 啟動 JetStream（server 加 -js）
 2# docker run -d --name nats nats:latest -js
 3
 4# 1. 建 stream：file storage、limits retention
 5nats stream add ORDERS --subjects "orders.>" --storage file --defaults
 6#   Subjects: orders.>   Storage: File   Retention: Limits   Replicas: 1
 7
 8# 2. publish
 9nats pub orders.new "order-1"   # Published 7 bytes to "orders.new"
10
11# 3. stream info 確認持久化
12nats stream info ORDERS
13#   Storage: File   Messages: 3   Bytes: 141 B   ← 訊息已落盤、consumer 重啟不丟
14
15# 4. durable pull consumer（explicit ack、可重送）
16nats consumer add ORDERS workers --pull --ack explicit --deliver all --defaults
17#   Pull Mode: true   Ack Policy: Explicit
18
19# 5. 拉取消費（worker pool 多個實例共用同一 durable consumer = queue group 語意）
20nats consumer next ORDERS workers --count 3
21#   order-1  order-2  order-3

實機驗證於 nats:latest（最後檢查日 2026-06-16）：file storage 的 stream 把訊息落盤（Messages: 3）、durable pull consumer 用 explicit ack 消費。多個 worker 連到同一個 durable pull consumer 形成 worker pool（訊息分給其中一個），這正是 Clarifai 的 queue group 模式。

判讀：

• worker pool 用同一個 durable pull consumer（共享進度、訊息分流），不是每個 worker 一個 consumer
• --ack explicit 是 at-least-once 的前提；處理成功才 ack
• pull 模式比 push 對 worker pool 更可控（worker 按自己能力拉、不會被 push 淹）

Production 故障演練

Case 1：用 core NATS 跑該持久的任務、rolling deploy 掉訊息

徵兆：平時正常，但每次部署（pod 輪流重啟）就有一批任務消失、沒有錯誤。

根因：用 core NATS（fire-and-forget）跑需要可靠處理的任務。發布瞬間目標訂閱者正在重啟，core NATS 找不到訂閱者就丟棄——這是 core 的設計，不是故障。正是 Clarifai 的原始問題。

修法：

1. 需要不丟的任務用 JetStream（持久 stream + durable consumer + explicit ack）
2. 訊息落盤後 consumer 重啟從上次位置續讀，rolling deploy 不丟
3. 釐清邊界：可丟的即時資料（metrics / presence）留 core NATS、不可丟的跨 JetStream
4. 不要用 core NATS 當任務隊列——它沒有持久化與重送

Case 2：ephemeral consumer 斷線、消費進度全丟

徵兆：consumer 重連後從頭重讀整個 stream、或漏掉斷線期間的訊息，進度不連續。

根因：用了 ephemeral consumer——它的進度不持久，client 斷線後 consumer 本身消失。重連是建一個全新 consumer，從 deliver policy 的起點開始（all 從頭、new 只看新的），不接續之前的進度。

修法：

1. 需要跨重啟接續的用 durable consumer（具名、進度持久）
2. ephemeral 只適合臨時、一次性的讀取（debug、一次性掃描）
3. worker pool 一定用 durable（多 worker 共享持久進度）
4. 確認 deliver policy（all / new / last）符合預期的起讀位置

Case 3：ack_wait 太短、處理還沒完就重送風暴

徵兆：長任務還在處理中就被重送給另一個 worker，同一任務被多個 worker 重複執行，負載放大。

根因：ack_wait（等 ack 的逾時）設得比任務處理時間短。JetStream 以為訊息處理失敗（沒在 ack_wait 內 ack），重送給別人——但其實第一個 worker 還在跑。ML 長尾任務（幾秒到幾分鐘）特別容易踩。

修法（本文層級的判讀）：ack_wait 必須涵蓋任務的 p99 處理時間，否則長任務會在處理中被重送。設值方法（量測 p99、長任務用 in-progress ack 延長 deadline、消費端冪等兜底）與實機重現（AckWait 設 1s 觀察 tries 1→2、Redelivered 計數）在 JetStream 設計與 supercluster/leaf node 的故障演練有完整步驟，採用 JetStream 後依該篇落地。

Case 4：retention 選 workqueue 但想多 consumer fanout

徵兆：想讓多個獨立服務各自消費同一 stream，但發現訊息被一個消費掉就消失、其他服務讀不到。

根因：stream retention 設成 workqueue——每則訊息只被消費一次就從 stream 刪除（隊列語意）。它不適合 fanout（多個 consumer 各自要完整一份）。fanout 要 limits 或 interest retention。

修法：

1. fanout（多服務各讀一份）用 limits retention（訊息保留、多 consumer 各自 offset）
2. 單一 worker pool 競爭消費用 workqueue（消費即刪、省空間）
3. 釐清需求：競爭消費（worker pool）vs 廣播消費（fanout）對應不同 retention
4. Clarifai 用「3 個獨立 NATS 實例做 fanout 隔離」是另一種 fanout 做法，按隔離需求選

Case 5：memory storage 的 stream 重啟全失

徵兆：broker 重啟後 stream 裡的訊息全沒了，consumer 從空的開始。

根因：stream storage 設成 memory——快但不持久，broker 重啟即失。誤把它當持久 stream 用。

修法：

1. 需要持久的 stream 用 file storage（落盤、重啟不丟，實機驗證過）
2. memory 只適合「快取式、可重建」的 stream（如即時聚合的中間狀態）
3. 要更高可靠性加 replicas（JetStream 用 Raft 跨節點複製 stream）
4. 容量規劃時 file storage 的磁碟與 memory 的 RAM 是不同維度

Capacity / cost 邊界

JetStream 的容量判讀：

撞牆後的路由判斷：

• 可丟的即時資料：不需要 JetStream 的持久化開銷，用 core NATS（更快更輕）。
• 超大吞吐 + 長期保留 + 複雜 replay：JetStream 適合中等規模可靠 messaging；超大規模 event streaming + 長期保留走 Kafka（log-based、生態成熟）。
• 複雜 routing / 任務隊列語意：JetStream 的 subject 是樹狀，複雜 routing + DLQ 拓樸用 RabbitMQ 更直接。
• 不想自管：NATS 的 managed 選項（Synadia Cloud）或其他 managed broker。

整合 / 下一步

JetStream 的邊界判斷是 NATS 使用的核心，它跟其他議題交織：

• 跟 3.4 consumer design：push/pull、durable/ephemeral、ack policy 是 consumer 設計的具體選項。
• 跟 3.2 durable queue：JetStream 的 file storage stream 是 NATS 的 durable queue 實現。
• 跟 6.12 idempotency / replay：at-least-once + redelivery 要求消費冪等，否則重送造成重複副作用。
• 跟 RabbitMQ DLQ deep article：max_deliver 達上限後的處理對應 RabbitMQ 的 DLQ，兩者都是「重試上限後往哪去」的問題。

相關連結

• 上游 vendor 頁：NATS
• 對照 vendor：RabbitMQ DLQ 與分層 retry、Kafka
• 對應案例：3.C38 Clarifai NATS ML 非同步任務
• 上游概念：3.4 consumer design、3.2 durable queue

本文是 Google Cloud Pub/Sub overview 的 implementation-layer deep article。Overview 回答「Pub/Sub 該不該選、跟 Kafka / SQS 差在哪」；本文回答「ordering key 怎麼設、DLT 怎麼擋 poison message、schema 怎麼守契約，各自踩哪些坑」。閱讀前可先讀 overview 的 ordering / DLT / schema 各段建立 context。

文中 gcloud 指令的語法以 Pub/Sub emulator 實機驗證（topic / subscription / schema / ordering key / DLT / push 各操作均跑通），標準版的雲端配額、IAM 與計費行為依官方文件。

三道治理共用同一個交付骨架

Pub/Sub 的 ordering key、dead-letter topic、schema enforcement 看似三個獨立功能，實際都掛在同一個交付骨架上：subscription 是消費進度的 first-class 抽象、訊息經 ackDeadline 控制重投、失敗訊息經投遞次數計數決定去留。理解這個骨架之後，三道治理只是骨架上的三個切面 — ordering 切的是「投遞順序」、DLT 切的是「投遞次數上限」、schema 切的是「投遞前的內容守門」。

這條骨架跟 Kafka 思路不同。Kafka 的消費進度綁在 consumer group + partition offset；Pub/Sub 的 topic 是 first-class，subscription 才是 consumer 抽象，一個 topic 可以掛 N 個 subscription、各自有獨立進度與獨立的 ackDeadline / DLT / ordering 設定。同一份 event 流，A subscription 可以開 ordering 嚴格有序、B subscription 可以不開 ordering 換吞吐，互不影響。

把這三道治理寫進一篇的理由是：它們在 production 會互相牽制。Ordering key 開了之後 DLT 的隔離行為會變（有序流裡一則 poison message 會卡住整把 key 的後續訊息）；schema enforcement 擋下的不相容 publish 不會進 DLT（根本沒進 topic）。分開讀三個官方頁面看不到這層耦合。

subscription 是 first-class：ackDeadline 與 extension

subscription 承擔「這個消費者讀到哪、還有多少沒 ack」的責任。每則訊息投遞給 subscriber 後，Pub/Sub 啟動一個 ackDeadline 倒數；倒數內收到 ack 就移除訊息、倒數結束沒收到 ack 就重投。預設 ackDeadline 是 10 秒、上限 600 秒。

 1# subscription 的 ackDeadline 預設 10 秒、retention 預設 7 天
 2gcloud pubsub subscriptions describe demo-sub
 3# ackDeadlineSeconds: 10
 4# messageRetentionDuration: 604800s   # 7 天
 5
 6# 建 subscription 時可顯式設更長的 ackDeadline 與更短的 retention
 7gcloud pubsub subscriptions create cfg-sub \
 8  --topic=demo-topic \
 9  --ack-deadline=120 \
10  --message-retention-duration=3d
11# ackDeadlineSeconds: 120
12# messageRetentionDuration: 259200s   # 3 天

ackDeadline 是一道「處理時間預算」。設太短，處理還沒完訊息就被重投，consumer 會收到重複；設太長，consumer crash 後訊息要等滿 deadline 才重投，延遲拉高。長任務不靠把 ackDeadline 一次設到 600 秒解決，而是靠 ack deadline extension：consumer 在處理中週期性發 modifyAckDeadline 把單則訊息的 deadline 往後延，處理完才 ack。

1# pull 一則但不 auto-ack，拿到 ackId
2ACKID=$(gcloud pubsub subscriptions pull demo-sub --limit=1 --format='value(ackId)')
3
4# 處理中動態延長這則訊息的 ackDeadline 到 300 秒
5gcloud pubsub subscriptions modify-message-ack-deadline demo-sub \
6  --ack-ids="$ACKID" \
7  --ack-deadline=300

實務上不手動發 modifyAckDeadline，而是用 client library 的自動 lease 管理：client 在背景對 outstanding 訊息週期性續約，直到 application code 回 ack / nack。這跟 SQS 的 visibility timeout 語意類似 — 都是「訊息正在被處理、暫時別重投」的租約 — 但 Pub/Sub 是 per-message lease + client 自動續約，SQS 是 per-receive visibility window + 手動 ChangeMessageVisibility。

ackDeadline 的陷阱在 batch 邊界。client library 常以 batch 為單位 pull，但 ackDeadline lease 是 per-message。若 application 把整個 batch 當一個工作單元處理、處理時間超過單則 ackDeadline 且 client 未對每則續約，未 ack 的訊息會被重投。Mercari 的 actionable history pipeline 揭露的正是這個 client library 行為：ack deadline 以整批 batch 為粒度運作，同批只要有一則過期或被 nack，已 ack 的訊息會跟著一起重投（3.C63）。

Push、Pull、Streaming Pull 與 flow control

subscription 有兩種交付方向，pull 之下又分 unary pull 與 streaming pull。三者對應不同的下游承壓能力。

Push 把投遞節奏交給 Pub/Sub：endpoint 回 2xx 視為 ack、回非 2xx 或逾時視為 nack 並 backoff 重投。Pull 把節奏交給 consumer：consumer 想拉才拉、拉多少自己定。Streaming pull 是 production 高吞吐場景的主力 — client library 預設用它，因為它能在單一長連線上做精細的 flow control。

flow control 是 pull 的核心優勢：consumer 用 max_outstanding_messages 與 max_outstanding_bytes 設定「同時最多持有多少未 ack 訊息」，超過上限 client 就暫停從連線拉取，等 application ack 釋放額度才繼續。這讓 consumer 能把消費速率對齊到下游能吃的速率，而不是被 broker 灌爆。

Push vs pull 不是實作偏好，是「下游能否接受 push 衝擊」的判讀。Mercari 把外部行銷 webhook（Braze）轉成 Pub/Sub event 後，下游 worker 刻意用 pull subscription 精確控制每秒處理訊息數，因為下游要呼叫的外部 LINE API 有 RPS 限制 — push 會把瞬間流量直接打到受限的外部 API（3.C65）。下游有硬性 RPS 上限時，pull + flow control 是讓消費速率可控的手段。

Ordering Key：有序的代價是吞吐

Ordering key 讓「帶同一個 ordering key 的訊息，在 subscription 端按 publish 順序投遞」。它把全域無序的 Pub/Sub 變成 per-key 有序 — 不同 key 之間仍可並行、亂序，只有同 key 內部保證順序。要生效需要兩端配合：subscription 建立時開 --enable-message-ordering，publish 時帶 --ordering-key。

1# subscription 端開啟 ordering
2gcloud pubsub subscriptions create ord-sub \
3  --topic=ord-topic \
4  --enable-message-ordering
5# describe 可見 enableMessageOrdering: true
6
7# publish 端帶 ordering key（同一 key 的訊息會保序）
8gcloud pubsub topics publish ord-topic --message=m1 --ordering-key=user-123
9gcloud pubsub topics publish ord-topic --message=m2 --ordering-key=user-123

Ordering key 的設計責任在於選對 key 的粒度。粒度太粗（例如所有訊息共用一個 key）會把整條 topic 退化成單線序列、吞吐崩塌；粒度太細（例如每則訊息一個 key）等於沒開 ordering。正確做法是按「需要保序的業務實體」選 key — 同一個 user-123 的事件要保序、不同 user 之間不需要 — 這樣並行度等於活躍 key 數，既保序又不犧牲整體吞吐。

跟 Kafka 對照能看清取捨。Kafka 用 partition + 同 key hash 到同 partition 達成保序，partition 數是固定預先規劃的並行上限；Pub/Sub 沒有顯式 partition，ordering key 的並行度是動態的、由活躍 key 數決定。代價是 Pub/Sub 的有序投遞要求同 key 訊息送到同一個內部處理單元，這個約束讓單一 ordering key 的吞吐有上限（官方標稱單 ordering key 約 1 MB/s）。

Ordering 跟 DLT 在 production 會耦合：有序流裡若一則訊息反覆失敗、Pub/Sub 為維持順序不會跳過它去投後面的訊息，整把 key 的後續訊息全卡住，直到該訊息 ack 或送進 DLT。沒開 ordering 時 poison message 只卡自己；開了 ordering 後它卡住整條 key 序列。這是下一節 DLT 要解的問題在 ordering 場景下被放大的原因。

Dead-Letter Topic：投遞次數上限決定隔離時機

Dead-letter topic 是 poison-message quarantine 在 Pub/Sub 的實作：subscription 對每則訊息計數投遞次數，超過 max-delivery-attempts 就把訊息轉發到另一個 topic（DLT），主 subscription 不再重投它，後續正常訊息得以前進。

 1gcloud pubsub topics create main-topic
 2gcloud pubsub topics create dl-topic
 3
 4gcloud pubsub subscriptions create main-sub \
 5  --topic=main-topic \
 6  --dead-letter-topic=dl-topic \
 7  --max-delivery-attempts=5
 8# deadLetterPolicy:
 9#   deadLetterTopic: projects/<proj>/topics/dl-topic
10#   maxDeliveryAttempts: 5

DLT 是 topic 不是 queue，這是 Pub/Sub 跟 SQS DLQ 的關鍵差異。SQS 的 DLQ 是另一個 queue、消費者直接 receive；Pub/Sub 的 DLT 是 topic，要再掛一個 subscription 才能讀。好處是 DLT 上可以同時掛多個 subscription — 一個給人工檢視、一個給自動 replay、一個給長期歸檔 — fan-out 內建。代價是多一層 subscription 配置，且 DLT 也有自己的 retention（同樣預設 7 天，poison message 要在這之內處理掉）。

max-delivery-attempts 設定的是「容忍多少次暫時性失敗」與「多快放棄」之間的平衡。設太低（例如 1-2 次），下游短暫抖動就把訊息丟進 DLT、誤殺可恢復的訊息；設太高（例如 50 次），一則真正壞掉的訊息會反覆重試半天、占用 consumer 資源、在有序流裡還會長時間卡住整條 key。官方允許範圍 5-100，常見起點是 5。

搭配 retry policy 的 backoff 能讓重投不至於太密集：

1gcloud pubsub subscriptions create retry-sub \
2  --topic=main-topic \
3  --min-retry-delay=10s \
4  --max-retry-delay=600s
5# retryPolicy:
6#   minimumBackoff: 10s
7#   maximumBackoff: 600s

啟用 DLT 需要把 Pub/Sub service account 授權對主 subscription 有 subscriber、對 DLT 有 publisher（emulator 不校驗 IAM，正式環境若漏授權，訊息超過 max attempts 後不會進 DLT、而是繼續留在主 subscription 重投，看起來像 DLT 沒生效）。授權細節依 GCP 官方 IAM 文件。

Mercari 的商品 feed 同步示範了 DLT 的標準用法：pull subscription + 自家 batch requester、成功 ack 整批、失敗 nack 讓 Pub/Sub 重送、重試多次仍失敗送 DLT、後續訊息優先處理；同一個 topic 還兼當突發流量的 load-leveling buffer（3.C64）。

Schema Enforcement：投遞前的契約守門

Schema enforcement 把 event schema compatibility 從「應用層約定」提升到「broker 強制」。topic 綁定一個 Avro 或 Protobuf schema 後，不符 schema 的 publish 在進 topic 前就被拒絕 — 訊息根本不會被儲存、不會投遞、不會進 DLT。

1# 1. 建 schema（Avro，一個必填 string 欄位 id）
2gcloud pubsub schemas create order-schema \
3  --type=avro \
4  --definition='{"type":"record","name":"Order","fields":[{"name":"id","type":"string"}]}'
5
6# 2. topic 綁 schema + 指定 message encoding
7gcloud pubsub topics create sch-topic \
8  --schema=order-schema \
9  --message-encoding=json

綁定後的 publish 行為（emulator 實機驗證 enforce）：

 1# 符合 schema：通過
 2gcloud pubsub topics publish sch-topic --message='{"id":"abc"}'
 3# messageIds: ['4']
 4
 5# 欄位不符 schema：被拒
 6gcloud pubsub topics publish sch-topic --message='{"wrong":123}'
 7# ERROR: INVALID_ARGUMENT: Could not parse message
 8
 9# 非 JSON 垃圾：被拒
10gcloud pubsub topics publish sch-topic --message='not-json'
11# ERROR: INVALID_ARGUMENT: Could not parse message

schema 守門的價值在於把契約破壞擋在 producer 端、而不是 consumer 端。沒有 schema enforcement 時，producer 改了 payload 結構、不相容的訊息照樣進 topic、要到 consumer 解析失敗才爆 — 此時訊息已經在系統裡流動、可能已 fan-out 到多個 subscription、修復成本高。有 schema enforcement 時，不相容的 publish 在源頭就失敗，問題暴露在「誰送了壞訊息」而不是「誰收到壞訊息」。

schema evolution 要在「擋住破壞性改版」與「不阻塞合理演進」之間取捨。新增可選欄位或帶預設值的欄位維持相容、可以平滑演進；新增必填欄位、刪欄位、改型別是破壞性改版，會讓既有 producer 或 consumer 失效。設計上先定相容性等級（backward / forward / full）再演進，刪欄位分兩步（先停用再移除），避免一次破壞性改版打掛下游。

跟 Kafka Schema Registry 對照：Kafka 的 schema 校驗在 client 端（producer / consumer 各自向 Registry 查 schema、序列化時校驗），broker 本身不認識 schema；Pub/Sub 的 schema 綁在 topic、校驗在 broker 端 publish 路徑上。前者校驗點分散、靈活但要求所有 client 守規矩；後者校驗點集中在 broker、強制但耦合到 topic 配置。

五個 Production 故障演練

deep article 的差異化價值在故障演練。以下五個徵兆對應前述三道治理在 production 的典型失效。

演練一：Ordering key 把吞吐限到單線

徵兆：開了 ordering 後整條 topic 的吞吐從數萬 msg/s 掉到數百 msg/s，subscription backlog（num_undelivered_messages）持續攀升、oldest_unacked_message_age 越拉越長，但 consumer CPU 並不滿載 — consumer 在等訊息、不是在忙。

根因：ordering key 粒度太粗。最常見是「所有訊息共用同一個 ordering key」（例如固定字串、或單一租戶 ID），整條 topic 退化成單一有序序列，並行度等於 1。單一 ordering key 的吞吐有上限（官方標稱約 1 MB/s），所有訊息擠進一個 key 就被這個上限封頂。

判讀與修法：

1. 確認 ordering key 的基數（cardinality）。gcloud pubsub topics publish 帶的 --ordering-key 在 production 是業務欄位映射來的 — 檢查映射邏輯是否塌縮成低基數。
2. 把 key 粒度對齊到「真正需要保序的業務實體」：同一筆訂單 / 同一個 user / 同一個 device 內要保序，跨實體不需要。粒度從「全域一個 key」改成「per-user 一個 key」，並行度從 1 拉到活躍 user 數。
3. 評估是否真的需要 ordering。多數 pipeline 靠 consumer 端 idempotency + 版本號就能容忍亂序，不需要 broker 層保序 — 把保序成本從吞吐換成 consumer 設計（見 3.7 event contract 的 idempotency key 段）。

演練二：Ack deadline 太短導致重複投遞

徵兆：consumer 處理邏輯正確、下游也成功，但同一則訊息被處理多次；DELIVERY_ATTEMPT 計數異常偏高、下游出現重複副作用（重複扣款 / 重複發信）。Backlog 不一定高，但「處理量」遠大於「publish 量」。

根因：ackDeadline 比實際處理時間短。預設 10 秒對「呼叫一個慢的外部 API」「處理大 payload」這類任務不夠，訊息在 application 還沒 ack 前就過了 deadline、被 Pub/Sub 重投，於是同一則訊息有多個 consumer 副本在跑。若 client library 的自動 lease extension 沒生效（例如 application 阻塞在同步呼叫、background lease thread 餓死），重投更嚴重。

判讀與修法：

1. 量測 p99 處理時間，把 ackDeadline 設到 p99 之上留 buffer，但不要不加判斷地設到 600 秒上限 — deadline 越長，consumer crash 後訊息重投的延遲越長。
2. 長任務靠 lease extension 而非長 ackDeadline：確認 client library 的自動續約有在跑，application code 不要在處理迴圈裡阻塞到讓 background 續約 thread 餓死。
3. consumer 端做 idempotency：用 message 的 dedup key（3.7）讓重複投遞變成無害 — at-least-once 交付下重複是常態，不靠調 ackDeadline 消除、靠 consumer 設計吸收。

演練三：DLT max delivery attempts 設定誤判

徵兆：兩種反向徵兆。其一，DLT 堆滿了「其實能恢復」的訊息 — 下游一抖動就被丟進 DLT，DLT backlog 暴增、人工 replay 不完。其二，主 subscription 卡著一則壞訊息反覆重投半天都不進 DLT、後面訊息（尤其在 ordering 流裡）全堵住。

根因：第一種是 max-delivery-attempts 設太低（1-2 次），暫時性失敗就被當成 poison。第二種是設太高（數十次）或根本沒設 DLT，真正的 poison message 反覆重試、占資源、卡序列。

判讀與修法：

1. 區分「暫時性失敗」與「結構性失敗」。暫時性（下游超時、限流）需要重試容忍度，結構性（payload 解析不了、業務規則永久拒絕）越早隔離越好。
2. max-delivery-attempts 起點設 5，搭配 retry policy backoff（--min-retry-delay / --max-retry-delay）讓重試之間有間隔、給下游恢復時間，而不是密集重打。
3. 確認 DLT 真的接得到訊息：檢查 Pub/Sub service account 對 DLT 的 publisher 授權（漏授權會讓訊息超過 attempts 後繼續留在主 subscription、看起來像沒進 DLT）。
4. DLT 要掛 subscription 才讀得到 — DLT 是 topic 不是 queue，建完 DLT 還要建 DLT 的 subscription 並設好 retention，否則 poison message 在 DLT 裡放滿 7 天後一樣丟失。

演練四：Push endpoint 500 觸發 retry storm

徵兆：push subscription 的下游 HTTP endpoint 開始大量回 500，Pub/Sub backoff 重投、但 endpoint 仍 500，重投量隨 backlog 累積越滾越大；endpoint 一旦短暫恢復就被積壓的重投流量瞬間打回 500，形成「恢復即再掛」的震盪。

根因：push 的 flow control 由 Pub/Sub 掌握、按 ack 動態調速 — endpoint 回 2xx 視為 ack、非 2xx 視為 nack 並重投。當 endpoint 因下游依賴（DB / 外部 API）掛掉而持續 500，Pub/Sub 的 backoff 重投跟累積的 backlog 疊加，恢復瞬間的流量遠超 endpoint 平時負載。這正是「下游能否接受 push 衝擊」的反面 — push 沒有 consumer 端的 flow control 閥門。

判讀與修法：

1. 先判訊息毒性 vs endpoint 健康。若是 endpoint 整體掛（所有訊息都 500），是容量 / 依賴問題；若是特定訊息 500（多數成功、少數失敗），是 poison message，該走 DLT。
2. endpoint 整體掛的場景，push 不是好選擇 — 改 pull + flow control，讓 consumer 用 max_outstanding_messages 把消費速率對齊到下游能吃的速率，避免恢復瞬間被積壓流量打垮（對照 3.C65 的下游 RPS 限制場景）。
3. 對 push 配 DLT，把反覆 500 的特定訊息隔離出去，避免單一 poison message 混在正常流量裡放大 retry。
4. endpoint 側對「Pub/Sub 重投」做 idempotency，因為 push 也是 at-least-once、500 後的重投會帶來重複。

演練五：Schema enforcement 擋下不相容 publish

徵兆：某次 producer 部署後，該 service 的 publish 開始大量回 INVALID_ARGUMENT: Could not parse message，訊息發不出去；但 consumer 端風平浪靜、沒有任何解析錯誤、backlog 也沒異常。

根因：這通常不是故障、是 schema enforcement 正常運作。producer 改了 payload 結構（加必填欄位 / 改型別 / 漏欄位），新 payload 不符 topic 綁定的 schema，broker 在 publish 路徑上擋下、訊息根本沒進 topic。徵兆出現在 producer 端（publish 失敗）而非 consumer 端（解析失敗），正是 schema 守門把問題前移到源頭的設計意圖。

判讀與修法：

1. 先確認是「該擋」還是「誤擋」。對照 producer 的新 payload 與 topic schema：若是破壞性改版（加必填欄位 / 改型別），enforcement 擋對了 — 該回滾 producer 或先演進 schema。
2. 用 gcloud pubsub schemas validate-message 在部署前 dry-run 校驗 payload 對 schema，把「不相容」暴露在 CI 而不是 production publish。
3. schema 演進走相容路徑：新增欄位帶預設或設可選、刪欄位分兩步、避免一次破壞性改版。先升 schema 再升 producer，順序反了就會出現這個徵兆。
4. 區分 schema enforcement 失敗與 DLT：schema 擋下的訊息不進 topic、不進 DLT（DLT 隔離的是「進了 topic 但消費反覆失敗」的訊息）。兩者是交付管線的不同關卡，徵兆與修法都不同。

容量與選型邊界：標準版 vs Pub/Sub Lite

前述配置適用標準版 Pub/Sub。標準版的計費與容量模型偏向「全域路由內建、按用量計費、不需預先規劃容量」；當吞吐極高且 region 確定時，Pub/Sub Lite 的 partition-based / zonal 模型成本更低。

Pub/Sub Lite 是獨立的 CLI surface（gcloud pubsub lite-topics / gcloud pubsub lite-subscriptions），不是標準版的一個 flag。選 Lite 的代價是要自己 provision partition 數與 throughput capacity（回到接近 Kafka 的容量規劃），換來的是高吞吐穩定流量下顯著更低的成本。判準是吞吐「夠高且夠穩定到值得自己管容量」— 流量彈性大、或不想管 partition 的場景仍該留在標準版。

Spotify 的 autoscaling 案例揭露 backlog 不等於 consumer healthy：下游 export 失敗時 consumer 不 ack 仍持續耗 CPU，autoscaling 把 CPU 越拉越高、反而擴出更多空轉 consumer；解法是 exponential backoff 抑制 CPU 消耗（3.C61）。容量規劃的 autoscale signal 要看「處理成功率」而非「CPU + backlog」，否則擴縮方向會反。

整合與下一步

BigQuery / Cloud Storage subscription：免 consumer 的落地路徑

標準版提供兩種「不需要自寫 consumer」的 subscription，直接把訊息落地到分析 / 儲存層：

• BigQuery subscription（--bigquery-table）：訊息直接寫進 BQ table，免 Dataflow 中介，適合 streaming analytics。可搭配 --use-topic-schema 讓 BQ table schema 對齊 topic schema — schema enforcement 在這裡延伸成「落地結構也受契約約束」。
• Cloud Storage subscription（--cloud-storage-bucket）：訊息批次寫成 GCS object，適合 data lake / 歸檔。

這兩種 subscription 把「event 流 → 分析 / 儲存」的常見管線收進 Pub/Sub 配置，省掉一層自管 consumer。它們仍受同一套 ackDeadline / DLT 骨架管轄。

Cross-link

• 上游 vendor 頁：Google Cloud Pub/Sub overview — 選型層、跟 Kafka / SQS 取捨
• 契約與重播邊界：3.7 Event Contract 與 Replay Boundary — schema / idempotency key / replay window 先於 broker 選型
• 知識卡：Event Schema Compatibility（schema enforcement 守的契約等級）、Poison-Message Quarantine（DLT 的隔離機制）
• 對應 case：3.C64 Mercari Item Feed DLT、3.C65 Mercari LINE flow control、3.C61 Spotify autoscaling、3.C63 Mercari actionable history
• 方法論：Vendor 深度技術文章的寫作方法論

何時 revisit

• ordering key 吞吐撞上單 key 上限、且無法再細分 key：評估改用 Kafka partition 模型，或把保序成本移到 consumer 端 idempotency
• 高吞吐穩定流量 + 成本壓力浮現：評估標準版 → Pub/Sub Lite，接受自管 partition 容量換成本
• schema 需要跨多 vendor 共用契約（同一份 event 同時進 Pub/Sub 與 Kafka）：評估把 schema source of truth 抽到 broker 外的 registry

本文是跨 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 寫作方法論

本文是 RabbitMQ overview 的 implementation-layer deep article。選型層（RabbitMQ vs Kafka / SQS、何時選 RabbitMQ）見 overview；本文只處理「決定用 RabbitMQ 後，失敗訊息怎麼 retry 才不會卡死隊列」。DLX 拓樸實機驗證於 rabbitmq:3-management、最後檢查日 2026-06-16；機制以 RabbitMQ DLX 官方文件 為準。

失敗訊息 requeue 回隊首，會卡住整條隊列

消費一則訊息失敗了——下游 API 超時、資料還沒就緒、暫時性錯誤。最直覺的處理是 nack 加 requeue=true，讓它重新排隊再試一次。問題是 RabbitMQ 的 requeue 把訊息放回原隊列的隊首，於是它立刻又被同一個 consumer 取出、再次失敗、再 requeue……在「下游還沒恢復」的那段時間裡，這則訊息反覆佔據隊首，後面所有正常訊息全被卡住。這就是 head-of-line blocking：一則毒訊息（poison message）拖垮整條隊列。

Indeed 每天處理 35M+ 職缺訊息，原本的架構正是把失敗訊息 requeue 回隊首，造成阻塞。他們的解法是設計 Requeue → Delay queue → Dead Letter Queue 三層 escalation：retry 幾次後讓訊息進延遲隊列（隔一段時間再試）、再失敗幾次才進 DLQ（停止重試、留待人工或專門處理）。這個案例揭露的核心原則是——retry 策略要跟隊列拓樸一起設計，不是純 client 端的 backoff。

本文展開 RabbitMQ 實現這套分層 retry 的機制（dead-letter exchange + TTL）、實機驗證的拓樸、以及把它寫成事故的踩坑。

核心概念：dead-letter exchange 的求值模型

RabbitMQ 的失敗訊息處理建立在 dead-letter exchange（DLX）上。理解它要抓住「訊息在什麼條件下被 dead-letter、去哪裡」。

訊息在三種情況被 dead-letter。一則訊息會從它所在的隊列被轉送到該隊列設定的 DLX：(1) 被 consumer nack / reject 且 requeue=false；(2) 訊息 TTL 到期（x-message-ttl 或 per-message expiration）；(3) 隊列達到長度上限（x-max-length）被擠掉。這三種 reason 會記在訊息的 x-death header 裡。

DLX 是隊列的屬性、不是訊息的。在宣告隊列時用 x-dead-letter-exchange 指定這個隊列的「死信要送去哪個 exchange」，搭配 x-dead-letter-routing-key 指定送過去時用什麼 routing key。死信被當成一則新訊息發布到那個 exchange，再依綁定路由到 DLQ。

TTL + DLX 組出「延遲隊列」。RabbitMQ 沒有原生的延遲投遞，但可以用「一個沒有 consumer、只設 TTL + DLX 的隊列」模擬：訊息進這個隊列、躺到 TTL 到期、被 dead-letter 回工作 exchange——等於延遲了 TTL 那麼久才重新可被消費。這是分層 retry 的關鍵積木。

x-death header 累積重試歷史。每次 dead-letter，RabbitMQ 在 x-death header 追加一筆記錄（哪個隊列、什麼 reason、次數 count）。消費端讀這個 count 就能判斷「這則訊息重試幾次了」，決定要再延遲還是進 DLQ。這是實現「retry n 次後升級」的依據。

配置：work → delay → DLQ 三層拓樸

實機驗證的最小 DLX 拓樸（工作隊列的訊息 TTL 到期後 dead-letter 到 DLQ）：

 1# 宣告 DLX exchange 與 DLQ
 2rabbitmqadmin declare exchange name=dlx type=direct
 3rabbitmqadmin declare queue name=dlq
 4rabbitmqadmin declare binding source=dlx destination=dlq routing_key=app.work
 5
 6# 工作隊列：設 TTL + 指向 DLX（TTL 到期或 nack(requeue=false) 都會 dead-letter）
 7rabbitmqadmin declare queue name=app.work \
 8  arguments='{"x-message-ttl":2000,"x-dead-letter-exchange":"dlx","x-dead-letter-routing-key":"app.work"}'
 9
10# 驗證：發一則、等 2s TTL 到期、它從 app.work 搬到 dlq
11rabbitmqadmin publish routing_key=app.work payload="poison-msg"
12# 等 TTL（2s）過期後（實測等 4s 確保）：
13rabbitmqctl list_queues name messages
14# app.work   0     ← TTL 到期被搬走
15# dlq        1     ← 落到 DLQ（訊息帶 x-death header、reason=expired）

實機驗證於 rabbitmq:3-management（最後檢查日 2026-06-16）：publish 後等 TTL 過期，app.work 歸零、dlq 出現該訊息。

三層 escalation 的完整拓樸（對應 Indeed 模式）：

1app.work（主工作隊列）
2  └─ consumer nack(requeue=false) 或處理失敗
3       ↓ dead-letter 到
4app.retry（延遲隊列：x-message-ttl=30s、無 consumer、DLX 指回 app.work）
5  └─ TTL 到期
6       ↓ dead-letter 回
7app.work（再次嘗試；消費端讀 x-death count）
8  └─ 重試達上限（例如 count >= 3）→ 消費端主動 nack 到
9app.dlq（死信終點：無自動重試、人工 / 專門 consumer 處理）

判讀：

• 延遲時間靠 app.retry 的 TTL 控制；要指數退避就設多個不同 TTL 的 delay 隊列（30s / 5m / 1h）逐層升級
• 「重試幾次」由消費端讀 x-death 的 count 判斷、達上限才送終點 DLQ
• DLQ 不該有自動重試的 consumer（否則又是迴圈）；它是給人看的、或給冪等的專門修復流程

Production 故障演練

Case 1：requeue 回隊首、毒訊息卡死整條隊列

徵兆：下游短暫故障期間，整條隊列的消費停滯、consumer CPU 衝高但吞吐歸零，恢復後發現大量正常訊息延遲。

根因：失敗時用 nack(requeue=true)，訊息回到隊首被立刻重取、反覆失敗，head-of-line blocking。下游故障越久，毒訊息霸佔隊首越久。

修法：

1. 失敗一律 nack(requeue=false) 走 DLX，不要 requeue 回原隊列
2. 用 delay 隊列（TTL + DLX）讓重試隔一段時間，給下游恢復時間
3. 重試有上限，達上限進終點 DLQ，停止自動重試
4. 這正是 Indeed 案例 的核心教訓：retry 拓樸化，不要 requeue-to-head

Case 2：delay 隊列綁錯、retry 變無限迴圈

徵兆：某些訊息永遠在重試、x-death count 累積到幾百次，DLQ 卻一直是空的。

根因：delay 隊列的 DLX 指回工作隊列，但消費端沒有檢查 x-death count、或上限判斷寫錯，訊息在 work ↔ retry 之間無限往返、永遠到不了終點 DLQ。

修法：

1. 消費端每次處理前讀 x-death 的 count，超過上限就主動投遞到終點 DLQ（不再走 retry）
2. 上限判斷要涵蓋所有 retry 路徑，不要漏掉某條
3. 監控 x-death count 分布，出現高 count 訊息代表升級邏輯漏了
4. 終點 DLQ 絕對不要接會 nack-to-DLX 的 consumer，否則迴圈

Case 3：per-queue TTL 的隊首阻塞陷阱

徵兆：用 x-message-ttl 設隊列級 TTL 做延遲，但發現訊息沒有按預期時間 dead-letter，延遲時間忽長忽短。

根因：隊列級 TTL（x-message-ttl）只在訊息到達隊首時才檢查是否過期。如果用 per-message TTL 且不同訊息 TTL 不同，前面一則長 TTL 的訊息會擋住後面短 TTL 的——後者明明過期了卻因為不在隊首而沒被 dead-letter。

修法：

1. delay 隊列用統一的隊列級 TTL（同一個 delay 隊列裡所有訊息延遲時間相同），不要在同隊列混用 per-message TTL
2. 要多種延遲時間就開多個 delay 隊列（每個固定 TTL），不要靠 per-message TTL
3. 理解 TTL 是「到隊首才檢查」的惰性求值，不是精準定時器
4. 需要精準排程的延遲用專門的 delay 機制（rabbitmq-delayed-message-exchange plugin），不靠 TTL 模擬

Case 4：DLX 沒綁好、死信靜默消失

徵兆：訊息明明該 dead-letter，但 DLQ 一直收不到，訊息憑空消失。

根因：DLX exchange 存在、隊列也設了 x-dead-letter-exchange，但 DLX 到 DLQ 的 binding 不存在或 routing key 對不上。死信被發布到 DLX 後沒有任何隊列接收（unroutable），直接被丟棄。

修法：

1. 確認 DLX → DLQ 的 binding 存在且 routing key 匹配（x-dead-letter-routing-key 對上 binding key）
2. 沒設 x-dead-letter-routing-key 時死信沿用原 routing key，binding 要對應原 key
3. 給 DLX 設 alternate exchange 或在 DLX 上掛一個 catch-all 隊列，避免 unroutable 死信靜默消失
4. 監控 DLX 的 unroutable / drop 指標，死信消失是嚴重的資料遺失

Case 5：DLQ 無上限成長、變成第二個問題

徵兆：DLQ 累積到幾十萬則訊息、記憶體吃緊，沒人處理。

根因：DLQ 是終點但沒有處理流程——訊息一直進、沒人消費，DLQ 變成一個越長越大的垃圾堆，最終吃光 broker 記憶體（classic queue 訊息在記憶體）。

修法：

1. DLQ 要有處理流程：告警 + 人工 / 自動修復 consumer（冪等地重新投遞或記錄）
2. DLQ 設 x-max-length 或自己的 TTL，避免無限成長（但要先確認丟棄可接受）
3. 監控 DLQ 深度與成長速率，持續成長代表上游有系統性失敗、要根治而非堆 DLQ
4. quorum queue 對 DLQ 是合理選擇（持久、不純靠記憶體），見 quorum vs mirrored queue deep article

Capacity / cost 邊界

分層 retry 拓樸的容量判讀：

撞牆後的路由判斷：

• 重試量大、delay 隊列堆積：重試治標、下游系統性故障要根治；考慮 circuit breaker 在上游擋住而非無限重試。
• 需要精準延遲排程：TTL 模擬的延遲不精準（惰性求值），用 rabbitmq-delayed-message-exchange plugin。
• DLQ / 隊列要持久可靠：classic queue 靠記憶體 + 鏡像，大量積壓有風險；用 quorum queue（Raft 持久）。
• 吞吐 / 保留需求超過 RabbitMQ：retry / replay 是 log-based broker 的強項，大規模 replay 走 Kafka（consumer 各自 offset、可重讀）。

整合 / 下一步

分層 retry 是 RabbitMQ 可靠消費的核心，它跟其他議題交織：

• 跟 3.2 durable queue：DLQ 要持久才不會在 broker 重啟時丟失死信。
• 跟 3.4 consumer design：prefetch / ack 策略決定毒訊息影響範圍，跟 retry 拓樸一起設計。
• 跟 6.12 idempotency / replay：retry 與 DLQ 重新投遞都要求消費冪等，否則重試造成重複副作用。
• 跟 quorum vs mirrored queue：DLQ 與重試隊列的持久性選 quorum queue，避開 mirrored queue 的網路成本。

相關連結

• 上游 vendor 頁：RabbitMQ
• 同 vendor deep article：quorum vs mirrored queue
• 對應案例：3.C25 Indeed delay queue + DLQ 三層 escalation
• 上游概念：3.2 durable queue、3.4 consumer design

本文是跨 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

本文是 AWS SQS overview 的 implementation-layer deep article。本文的 CLI 指令語法經 LocalStack round-trip 驗證、真實 AWS 的 scaling 行為、Lambda event source mapping 細節與計費數字依 AWS 官方文件。

SQS 沒有 broker ACK，delivery 控制全靠 visibility timeout

SQS 跟自管 broker（RabbitMQ / Kafka）最大的操作差異是：consumer 不會跟 broker 維持一條長連線、也沒有 channel-level 的 ack / nack 協議。SQS 的整個 delivery 保證建立在一個計時器上 — visibility timeout。訊息被 ReceiveMessage 拉走後進入 in-flight 狀態、在 timeout 視窗內對其他 consumer 不可見；consumer 處理成功就呼叫 DeleteMessage 把它移除、處理失敗或當機則什麼都不做、等 timeout 到期訊息自動回到 queue 重新可見。

這個設計把「確認處理完成」的責任從 broker 連線狀態轉移到 consumer 的主動刪除。好處是 consumer 可以隨時死掉、重啟、水平擴縮、不需要維持任何 session 狀態 — 訊息不會因為連線斷掉而遺失。代價是 visibility timeout 這個數字變成最容易設錯、後果最隱蔽的參數：設太短訊息會在 consumer 還在處理時就重新可見、被另一個 consumer 重複領走；設太長則 consumer 當機後訊息要等很久才回到 queue、retry 延遲拉長。

實機建立一個 queue 並查 default、可以確認這個視窗的起點。新建 queue 的 VisibilityTimeout 預設 30 秒：

1# 不帶任何 attribute 建 queue
2aws sqs create-queue --queue-name demo-default
3
4# 查 default visibility timeout
5aws sqs get-queue-attributes \
6  --queue-url <url> \
7  --attribute-names VisibilityTimeout
8# => "VisibilityTimeout": "30"

30 秒對「處理時間穩定在數百毫秒」的 task 綽綽有餘、對「呼叫第三方 API、跑批次轉檔、寫多個下游」的 task 則經常不夠。下一節先把這個參數設對，後面的故障演練再展開它設錯時的具體徵兆。

對齊 visibility timeout 與 consumer 處理時間

設定 visibility timeout 的判準是「略高於 consumer 處理單則訊息的最大時間」、不是平均時間。Capital One 的官方 tech blog 在講 SQS + Lambda 時明示這條原則：visibility timeout 應比最大處理時間略高 — 因為決定 redelivery 的是尾端那幾則最慢的訊息、不是中位數。處理時間 p50 是 2 秒、p99 是 25 秒時、visibility timeout 要對齊 p99 加緩衝、設到 30-40 秒、而不是看 p50 設 10 秒。

建 queue 時直接帶 VisibilityTimeout attribute，或對既有 queue 用 set-queue-attributes 調整：

1# 建立時指定（單位：秒；上限 12 小時 = 43200）
2aws sqs create-queue \
3  --queue-name demo \
4  --attributes VisibilityTimeout=60
5
6# 對既有 queue 調整
7aws sqs set-queue-attributes \
8  --queue-url <url> \
9  --attributes VisibilityTimeout=120

處理時間本身不可預測的場景（例如轉檔大小差異大、下游 API 偶發慢）、用一個固定的 queue-level visibility timeout 會兩頭不討好：對齊最壞情況會讓正常訊息當機後 retry 太慢、對齊正常情況會讓慢訊息 redelivery。SQS 給的工具是 ChangeMessageVisibility — consumer 在處理過程中發現這則會花更久時，主動延長這一則訊息的 visibility timeout，而不影響 queue default：

1# consumer 拿到 ReceiptHandle 後，動態把這則延長到 120 秒
2aws sqs change-message-visibility \
3  --queue-url <url> \
4  --receipt-handle <receipt-handle> \
5  --visibility-timeout 120

實務上長任務 consumer 的常見寫法是「heartbeat extension」：每處理一段就呼叫一次 ChangeMessageVisibility 往後推、形成一個續命迴圈、直到處理完成才 DeleteMessage。這把「我還活著、還在處理這則」的訊號明確化、避免用一個保守的 queue-level 大數字一刀切。ReceiptHandle 是每次 ReceiveMessage 回傳的一次性 token、不是 message id — 同一則訊息被重新領取後 ReceiptHandle 會變、延長操作必須用當次領取拿到的那一個。

Long polling 決定空輪詢成本，short polling 是預設陷阱

Polling 模式直接決定 SQS 的 request 帳單，因為 SQS 按 request 數計費、而 ReceiveMessage 即使沒拿到訊息也算一次 request。Short polling（預設、WaitTimeSeconds=0）的行為是「立即回應」：consumer 發 ReceiveMessage、SQS 抽樣一部分 server 立刻回、queue 空的時候回一個空 response。Consumer 為了即時拿到訊息會緊接著再發一次、形成高頻空輪詢 — 在低流量 queue 上、絕大多數 request 都是空回、帳單全花在「問有沒有訊息」上。

Long polling（WaitTimeSeconds 設 1-20 秒）改變這個行為：SQS 收到 ReceiveMessage 後、若 queue 當下沒訊息、會 hold 住這條連線最多 WaitTimeSeconds 秒、期間一有訊息到達就立刻回傳、整段時間都沒訊息才回空。對 consumer 端來說一個 20 秒的 long poll 取代了 20 秒內可能發出的數十次 short poll、空 request 數量大幅下降。

1# long polling：等到有訊息或最多 20 秒才回
2aws sqs receive-message \
3  --queue-url <url> \
4  --wait-time-seconds 20

設定 long polling 有兩個位置：per-request 帶 --wait-time-seconds、或 queue-level 設 ReceiveMessageWaitTimeSeconds attribute 讓所有 receive 預設走 long polling。後者更穩、不依賴每個 consumer 都記得帶參數。20 秒幾乎總是對的選擇：它把空輪詢壓到最低、而 latency 代價只在「queue 剛好空、訊息在 poll 結束後才到」這個邊界出現 — 大多數有持續流量的 queue 根本碰不到 20 秒上限。唯一要留意的是 consumer 的 socket timeout 必須大於 WaitTimeSeconds、否則 client 會在 SQS 還在 hold 連線時自己先 timeout 斷線。

SQS + Lambda：event source mapping 把 polling 交給 AWS

把 SQS 接上 Lambda 時、polling 這件事整個從應用程式碼消失、改由 Lambda 的 event source mapping 接管。Event source mapping 是 Lambda service 內部一組 managed poller、持續對 queue 做 long polling、把拉到的訊息打包成 batch 同步 invoke 函式、函式正常返回就由 service 代為 DeleteMessage。Consumer 端不再寫 receive / delete 迴圈、只寫處理單一 batch 的 handler。

這套 managed poller 的 scaling 不是線性的、有 ramp-up 上限。Capital One 觀察到的行為是：Lambda 初始開 5 個並行的 long polling 連線、隨 queue 累積每分鐘最多增加 60 個 instance、standard queue 的並行 batch 上限到 1000。這意味著 queue 突然湧入大量訊息時、Lambda 不會瞬間炸開到滿並行、而是分鐘級爬升 — 容量規劃時要把這段 ramp-up 期算進 backlog 消化時間、不能假設「訊息一到就有足夠 consumer」。

兩個核心參數決定每次 invoke 的形狀：

Batch size 拉大表面上省錢 — invoke 次數少、每則訊息分攤的 request 成本低。但它跟下一節的部分失敗處理直接耦合：batch 越大、一則毒訊息拖累整批重投的範圍越大。Batch window 則是流量稀疏時讓 batch 攢滿的手段、流量本來就密集時設不設都差不多、反而會引入不必要的 latency。

DLQ 與 redrive policy：用 maxReceiveCount 隔離毒訊息

毒訊息（永遠處理失敗的訊息 — 格式損壞、引用了已刪除的資源、觸發 consumer 確定性 bug）會在 visibility timeout 機制下無限重投：處理失敗、timeout 到期、重新可見、再次被領取、再次失敗。沒有上限的話這則訊息會永遠佔用 consumer 資源、且其他正常訊息的處理被它反覆插隊。Dead-letter queue（DLQ）加 maxReceiveCount 是 SQS 對這個問題的標準解 — 訊息被接收超過 N 次後、SQS 自動把它移到另一個指定的 queue（DLQ）、主 queue 不再被它卡住。

設定分兩步：先建一個普通 queue 當 DLQ、取它的 ARN、再對主 queue 設 redrive policy 指向這個 ARN 並設 maxReceiveCount：

 1# 1. 建 DLQ 並取得 ARN
 2aws sqs create-queue --queue-name demo-dlq
 3aws sqs get-queue-attributes \
 4  --queue-url <dlq-url> \
 5  --attribute-names QueueArn
 6# => "QueueArn": "arn:aws:sqs:us-east-1:000000000000:demo-dlq"
 7
 8# 2. 對主 queue 設 redrive policy（被接收 5 次後送 DLQ）
 9aws sqs set-queue-attributes \
10  --queue-url <main-url> \
11  --attributes '{"RedrivePolicy":"{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:000000000000:demo-dlq\",\"maxReceiveCount\":\"5\"}"}'

DLQ 不是訊息的墳場、是待診斷的暫存區。對應 poison message quarantine 的思路、DLQ 累積要分兩種根因處理：訊息格式錯（永遠失敗、需要修 producer 或人工丟棄）vs 下游服務暫時 down（訊息本身沒問題、修好下游後可以重放）。後者用 redrive 把訊息從 DLQ 批次放回主 queue 重新處理、對應 dlq drain 的排空流程。判斷之前先看 DLQ 裡訊息的內容、不要不加判斷地 redrive — 把毒訊息 redrive 回去只會再走一輪 maxReceiveCount 又回到 DLQ。

maxReceiveCount 設多少是取捨：太小（例如 1-2）會讓「下游短暫抖動」這種暫時性失敗被誤判成毒訊息、過早送進 DLQ；太大（例如 100）會讓真正的毒訊息浪費大量 consumer 重試。多數 task queue 設 3-5 是合理起點 — 足以吸收幾次暫時性失敗、又不至於讓確定性失敗的訊息空轉太久。

Message size 限制與 extended client

SQS 單則訊息上限是 256 KB（含 message body 與 attributes）。這對純事件通知、id 引用、小型 payload 足夠、但對「訊息本身要攜帶大檔案內容」的場景不夠 — 例如要傳一份報表、一張圖、一段長文字。直接的反模式是把大內容塞進 message body、撞上 256 KB 限制後 SendMessage 直接報錯。