前言

如果說平日流量考驗的是架構是否合理，那麼黑五、Prime Day、雙 11 或大型品牌聯名活動，考驗的就是整個平台是否真的具備營運層級的生存能力。因為在這種時候，系統面對的不是一般的成長曲線，而是極短時間內的大量湧入、熱門商品極端集中、促銷邏輯突然變複雜，以及支付、物流、客服、通知等外部依賴一起被放大。

很多平台平常看起來都跑得很穩，但一到大促就出現同樣的劇本：首頁變慢、搜尋爆掉、熱門 SKU 超賣、訂單佇列堆積、支付 callback 延遲、通知亂序、客服查不到狀態、營運臨時改規則又把系統推向更高風險。這些問題之所以反覆出現，不是因為工程師不努力，而是因為大促本來就是把系統設計中所有被延後處理的矛盾一次攤開。

所以這篇不只談技術，也談營運現實。我們會從限流、降級、觀測、queue buffering、災難復原與成本治理這幾個角度，整理超大型電商在活動高峰場景下最值得優先處理的設計原則。

系列文章導航

  1. 從商品瀏覽到訂單履約，超大型電商平台到底怎麼拆
  2. 商品目錄、搜尋、推薦、快取與 CDN，為什麼電商本質上是讀流量主導的系統
  3. 購物車、庫存預留、下單流程與超賣治理
  4. 支付、退款、帳務、對帳與交易一致性
  5. MySQL、PostgreSQL、DynamoDB、Redis、OpenSearch 與 S3，資料到底該放哪裡
  6. CloudFront、WAF、ALB、EKS、Aurora 與 Multi-Region，AWS 基礎設施如何規劃
  7. 黑五與大促場景下的限流、降級、觀測、災難復原與成本控制（本篇）

大促時真正危險的不是流量大，而是流量集中且錯誤會連鎖放大

大型活動最麻煩的地方，不只是請求數量上升，而是請求會集中在：

  • 少數熱門商品
  • 少數熱門分類
  • 少數熱門搜尋字詞
  • 少數支付方式
  • 少數履約節點或倉庫

也就是說，整個平台不會平均受壓，而是某些局部熱點會先爆，再把壓力傳遞到其他系統。例如熱門商品頁快取 miss 增加，導致搜尋與商品服務變慢，接著購物車 API 變慢，再接著訂單與庫存確認壓力上升，最後支付 callback 也因為 queue backlog 而延遲。

成熟架構面對的不是「如何讓任何情況都不出錯」，而是如何在局部失控時，把問題限制在局部，而不是拖垮整個平台。

限流的目的不是擋人，而是保住核心交易鏈路

很多團隊提到限流時，第一反應是「會不會影響轉換率」。但在大促情境下，不限流的結果常常不是所有人都買得到，而是整個平台一起掛掉，最後誰都買不到。

所以超大型電商常見的限流策略通常不是單一層，而是多層漏斗：

  • 邊緣層與 CDN 先擋掉明顯異常流量
  • API gateway 或入口層針對高風險 API 做 request rate control
  • 熱門商品或熱門活動獨立做令牌或排隊控制
  • 下單與付款入口做每使用者、每裝置、每 IP、每帳號級別保護

這裡的核心觀念是：讓有限資源被有秩序地消耗，而不是被無差別競爭。

對熱門商品，排隊與令牌通常比單純重試更健康

熱門 SKU 搶購最常見的災難之一，是所有人同時打同一支下單 API，然後客戶端與中間層都開始重試。結果不是吞吐量變高，而是把本來就已經熱的核心鏈路打到更熱。

比較穩健的做法通常包括：

  • 提前發放搶購資格令牌
  • 進站排隊頁
  • 每人限購與短時間內限次
  • reservation 漏斗控制
  • 在前端明確顯示目前狀態，避免使用者狂按重試

真正成熟的設計，不會把所有人都直接放進最熱的庫存與下單路徑，而是讓入口先把峰值切平。

降級策略要以業務價值排序，而不是以技術容易度排序

大促時，所有功能理論上都重要，但它們的重要性並不一樣。對平台來說，更合理的優先順序通常是：

  1. 先保住商品可瀏覽。
  2. 再保住庫存與下單正確性。
  3. 再保住支付與訂單查詢可追蹤。
  4. 最後才是推薦、評論、個人化、部分次要通知與某些後台查詢。

這代表活動期間常見的降級策略包括：

  • 關閉部分高成本推薦區塊
  • 搜尋先退化成較簡單排序
  • 延後非關鍵通知
  • 暫停部分後台即時報表
  • 客服查詢切到快照或延遲資料

這裡的重點不是「功能變少」，而是讓有限資源優先服務最重要的鏈路。

Queue buffering 與 backpressure，是把尖峰流量變可處理流量的核心

大型活動期間，前台尖峰與後台實際可處理能力幾乎不可能完全同步。因此成熟平台通常會透過 queue 與 worker 模型，把那些不需要同步回應的工作抽離主線。

常見被事件化的工作包括：

  • 發送通知
  • 更新推薦與分析資料
  • 補寫搜尋與查詢 projection
  • 後續履約與物流任務建立
  • 稽核與報表事件寫入

但 queue 並不是萬靈丹。如果沒有 backpressure 設計，佇列只會變成延遲被藏起來的地方。所以你還需要觀測：

  • queue backlog
  • consumer lag
  • worker latency
  • dead-letter queue 數量
  • retry rate

一旦這些數字失控，就代表問題正在從同步主線向非同步世界蔓延。

可觀測性不只要看技術指標，還要看業務指標

很多系統在平時監控 CPU、memory、latency 都做得不錯，但一到大促卻不知道到底是哪一段業務流程開始歪掉。原因通常是只監控了技術健康，沒有監控業務健康。

大型電商在高峰場景下，至少應該同時關注兩類指標：

技術指標

  • API p95 / p99 latency
  • error rate
  • queue backlog
  • cache hit ratio
  • DB CPU / IOPS / connections
  • search latency
  • callback delay

業務指標

  • 加購率與結帳轉換率
  • reservation 成功率
  • 建單成功率
  • 付款成功率
  • 超賣件數
  • 補償任務量
  • 對帳差異筆數

只有把這兩類資料放在一起看，團隊才能知道問題是「機器慢了」，還是「流量還沒壞，但業務已經在失血」。

災難復原不是只準備切換腳本，而是要準備補償與修復能力

對超大型電商來說，真正痛的不是服務重啟，而是資料狀態不一致。例如：

  • 訂單成功了，但通知沒送
  • 付款成功了，但訂單還卡在待付款
  • reservation 逾時沒釋放
  • 部分退款成功了，但帳務沒沖回

所以災難復原至少應該包含三個層次：

  1. 基礎設施恢復：服務、資料庫、快取、網路恢復。
  2. 流程恢復：queue 重啟、worker 追上、callback 補處理。
  3. 資料恢復：對帳、補償、修單、人工介入流程。

如果只準備好第一層，平台仍然可能在服務恢復後繼續混亂很久。

成本治理在大促場景特別重要，因為高峰不是常態

大型活動有一個很現實的特徵：高峰很貴，但不是天天都在發生。所以平台需要的是能在高峰前預熱、高峰中承接、高峰後縮回的能力，而不是永遠維持最極端規模。

這意味著成本治理重點通常包括：

  • 哪些容量需要預留
  • 哪些資源適合臨時放大
  • 哪些快取與搜尋節點在活動結束後可以縮回
  • 哪些跨區流量其實是架構設計失當造成的浪費

如果平台沒有把 FinOps 與流量治理結合起來，很容易出現活動結束後才發現成本結構完全失衡。

一個比較務實的大促防護漏斗

flowchart TD
    A[使用者流量] --> B[CloudFront / WAF / Bot Protection]
    B --> C[排隊頁 / 活動令牌]
    C --> D[首頁 / 商品頁 / 搜尋快取]
    D --> E[購物車 / reservation]
    E --> F[下單 / 支付核心鏈路]
    F --> G[MQ / Async Workers]
    G --> H[通知 / 報表 / 履約 / 分析]

這張圖的核心概念只有一句話：越靠近交易核心，越不能讓所有流量無條件直通。

平台真正要保住的是 E 到 F 這段鏈路；其他地方則要盡可能快取、限流、排隊、降級與分流。

總結

大促場景下，真正考驗的平台能力不是平均效能，而是是否能在局部熱點、外部依賴波動與錯誤連鎖下，依然保住核心交易鏈路。這需要的不只是技術元件，更需要一整套營運層思維：限流、令牌、降級、queue buffering、業務監控、災難復原與成本治理必須一起出現。

從這個角度回頭看整個系列，你會發現超大型電商的系統設計從來不是某個單點技巧，而是一套從讀流量治理、交易狀態治理、資料分層、雲端規劃到營運穩定性的整體方法。真正成熟的平台，不是高峰時永遠不出錯，而是錯了不會全面崩、崩了找得到、找到了補得回、補回來之後成本還能接受。