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

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