加機器解決不了熱點問題，只會讓熱點更貴。 這是處理高併發系統時最常被忽略的事實。當每秒請求數開始往上跳，第一反應通常是擴容、加 Pod、升等資料庫規格——但若請求集中打在同一筆熱門商品、同一個排行榜 key、同一張訂單表，水平擴容只是把問題分攤到更多閒置資源上，瓶頸還是在那一點。
設計大流量架構前，先回答一個問題：你的流量是均勻分布，還是長尾集中？ 兩者要用完全不同的策略。
從讀寫比與熱點分布開始拆
大部分電商或內容型系統都是讀多寫少，而且讀請求高度集中。這時候快取策略決定了一切。
常見的順序是：CDN 擋住靜態與可快取的動態回應 → 應用層用 Redis 或本地快取擋住熱資料 → 資料庫只服務真正的長尾與寫入。聽起來理所當然，但實務上踩坑的地方在於三件事：
- 快取穿透：查不到的 key 一直打到 DB。對策是 null value 也要快取，或用 bloom filter 先擋。
- 快取雪崩：大量 key 同時過期。對策是過期時間加隨機 jitter，或關鍵 key 改成主動更新。
- 快取擊穿：熱 key 過期瞬間，大量請求湧入重建。對策是用 singleflight 或互斥鎖讓只有一個請求去回源。
舉個例子，假設一個電商首頁推薦清單會被大量用戶同時請求，把這份清單放 CDN 邊緣快取幾十秒，比任何資料庫優化都有效。但如果這份清單需要個人化，就要往應用層快取退一步，用 user segment 當 key 而不是 user id，避免 key 爆炸。
寫入端的故事不一樣。寫入通常無法快取，只能用三招：非同步化、批次化、分片。訊息佇列（Kafka、RabbitMQ、SQS）的價值不是「解耦」這種抽象說法，而是讓你能把瞬間尖峰攤平到後端能承受的速率。下訂單、扣庫存、寄信、寫 log 這類動作，能延後一兩秒完成的就不要同步處理。
分片、無狀態與看得見的系統
當單一資料庫實例真的撐不住，才考慮分片。分片是有代價的——跨片 join 變難、交易變複雜、rebalance 是工程惡夢——所以順序應該是：先做讀寫分離、再做垂直拆分（按業務域拆庫）、最後才水平分片。
分片鍵的選擇比分片本身更重要。用 user_id 分片，單一用戶的資料都在同一片，查詢友善但容易出現大戶熱點；用 hash 分片，分布均勻但範圍查詢痛苦。沒有銀彈，只有取捨。
應用層則要堅持無狀態。session 放 Redis、檔案放物件儲存、任何節點掛掉都能被立刻替換。這樣 auto scaling 才有意義，否則擴出來的新節點什麼都做不了。
最後是可觀測性。大流量系統最可怕的不是壞掉，是慢慢壞掉而沒人發現。三件事是底線：
- Metrics：至少要有 RED（Rate、Error、Duration）三個維度，每個服務每個 endpoint 都要有。
- Distributed tracing：一個請求跨多個服務時，能完整看到每一段耗時。
- 結構化 log：用 JSON 而不是純文字，方便後續查詢與告警。
沒有這三樣，效能調校就是憑感覺，擴容就是憑運氣。
我們的觀察
在替中小企業客戶報價大流量架構時，我們通常會建議先別急著上 Kubernetes 或微服務。先把熱點圖畫清楚、把快取層補上、把同步寫入改成非同步——這些動作的投資報酬率往往比架構大改造高得多。架構複雜度是有利息的，借了就要還。等真的撐不住，再拆。