本章目標

學完本章後，你將能夠：

1. 理解為什麼 Redis client 應該共用
2. 分辨單鍵操作、pipeline、transaction 與 Lua 的邊界
3. 了解高併發下的 cache stampede 與 hot key 問題
4. 用 context 與 timeout 保護 Redis 呼叫
5. 把 Redis 用在適合的資料角色，並保留正式狀態來源

【觀察】Redis 呼叫大多是短網路 I/O

應用端對 Redis 的操作通常是短小但頻繁的網路請求。這代表真正影響效能的往往是 RTT、連線重用、批次送出與 key 設計。

所以高併發時，重點是控制 Redis 邊界：

• 用同一個 client 共用連線池
• 對獨立操作使用合理的 pipeline
• 熱門資料要避免集中到單一 key

【判讀】client 共用比每次建立更重要

Redis client 的核心設計通常就是讓應用共用同一個實例。每個 request 都 new client，會把連線管理成本、握手成本與資源回收問題全部放大。

高併發服務通常會採用：

• process 啟動時建立一個 Redis client
• request handler、worker、service layer 共用它
• 所有操作都帶 context
• timeout 與取消由上層傳入

【策略】pipeline 用來節省 RTT

pipeline 的價值是把多個獨立命令一次送出，減少往返次數。它很適合：

• 多個彼此獨立的讀取
• 批次寫入
• 一次更新多個 cache key

pipeline 的核心限制是批次大小仍要受控。太大的 pipeline 會帶來：

• 內存壓力
• 回應延遲變大
• 單次失敗影響更多操作

【判讀】原子性需求要分清楚

Redis 的很多操作本身就可以很快，但原子性與一致性需要額外設計。當需求需要多個資料變更形成同一個結果時，才應該考慮：

• 單鍵原子操作
• transaction
• Lua script
• 由上層做去重或補償

transaction 應服務明確的一致性需求，cache 寫入也應維持輔助狀態定位。Redis 很常是輔助狀態，真正的 source of truth 通常還是在 SQL 或 domain store。

【策略】cache stampede 與 hot key 要先處理

高併發快取最常見的兩個問題，是大量 goroutine 同時 miss 同一筆資料，以及大量流量打到同一個 key。

cache stampede

當 cache miss 發生時，如果每個 request 都直接回源查 DB，會把後端放大成更大的壓力。常見的處理方式包括：

• 設定合理 TTL
• 加 single-flight 類型的去重
• 讓部分請求等待同一批重建結果
• 對重建失敗設退避或短暫保護

hot key

如果某些 key 過度熱門，壓力會集中到 Redis 甚至單一 shard。處理方式通常是：

• 拆 key 或拆資料粒度
• 讓讀取走多層 cache
• 降低單點依賴
• 在應用端做短暫本地快取或節流

Cache 在規模化服務的角色光譜（主寫於 _index）

Cache 在規模化服務的角色從「DB 補救」逐步轉變到「主要服務面」再到「資料平面」、是橫跨整個 02 模組的入門 frame。完整光譜跟判讀條件主寫於 模組入口的「規模化下 cache 的角色光譜」段；本章從 高併發讀寫 角度補充：當 cache 已落在「主要服務面」或「資料平面」角色、cache lookup 是 critical path、容量規劃跟 stampede 防護要按本章「Cache 容量規劃跟 DB 不一樣」段執行。

對應 9.C6 Tinder ElastiCache — 4700 萬 MAU 配對引擎、每次滑動查多個 cache（用戶 profile、距離、偏好過濾、推薦池）、cache lookup 屬 critical path。詳細 cache vs persistent store 取捨見 2.7 cache copy boundary。

Cache 容量規劃跟 DB 不一樣

容量規劃基準在 cache 跟 DB 有本質差異：DB 容量受 total dataset size 影響（要存所有資料）；cache 容量受 working set size 影響（只存熱資料）。兩者的擴容邏輯、成本曲線、評估指標都不同、不能套用相同規劃模板。

對應 9.C6 Tinder — 47M MAU sustained growth、容量規劃變成「每月線性擴容 X%」的長期決策、不是峰值規劃。對應 2.C4 Meta CacheLib / Kangaroo — 當熱資料超過 DRAM 經濟範圍、單層 cache 同時遇到成本跟命中率瓶頸、要分層（DRAM + flash、詳見 2.3 ttl-eviction 分層快取段）。

Cache 容量規劃的三個維度：

• Working set size：熱資料大小決定 cache 需要多少 RAM。監控指標是 hot key 分布 跟 resident set growth。working set 估算方式因 workload 不同、要靠實測得出。
• 命中率目標：命中率目標決定 cache 大小的成長曲線。90% / 95% / 99% 對應不同 cache 大小、每加一個 9 需要的 cache size 通常顯著增加（具體倍數依 access pattern 分布、Zipfian 分布越平倍數越高）。
• 回源 budget：cache miss 後 origin（DB / 重算）能承受多少 QPS、決定 cache 命中率下限。命中率掉幾個 percentage point 可能讓 origin QPS 翻數倍、容量規劃要按命中率敏感度反推 origin headroom。

判讀重點：cache 命中率變化是 業務變化訊號、可能是新功能影響 access pattern（推薦演算法改、查詢條件擴大、tenant 結構變化）、應先看業務側、再考慮加 cache capacity。

Redis 規模化的單執行緒邊界

Redis command 執行至今仍 single-threaded、單實例 command 吞吐受 CPU 單核限制。6.0+ 起可開啟 I/O thread 提升 I/O 吞吐、但 command 執行仍序列化。規模化服務遇到這個邊界時、四個選項各自適合不同壓力：

1. 拆 cluster（應用層分散 key）：Redis Cluster 自帶分片、適合 key 數量多、單 key 不熱的場景。每 shard 仍 single-threaded、但總吞吐線性擴展。典型壓力是「KV 種類多、每種 key 不算熱、整體流量大」、跟 Tinder 47M MAU 同類 — 用戶 profile 跨大量 key 分散、每個 key 流量不極端、cluster 切片足夠。

2. Redis 6.0+ I/O thread：保留 Redis protocol、I/O 處理 multi-threaded、command 執行仍 single-threaded。提升 read-heavy 場景吞吐、實測倍數依 workload 跟 thread 數而定。適合「主要瓶頸在 I/O syscall 不在 command CPU」的場景、是低改動量的階段性升級、不換 broker。

3. KeyDB / Dragonfly（multi-threaded fork）：command 執行也 multi-threaded。對應 9.C35 Snap KeyDB — Snap 採用 KeyDB 在 GCP 上替代原生 Redis、9.C35 判讀段提出「單實例 throughput 提升 5-10x」（屬案例 derived 推論、實測倍數依 workload）。適合「單 key 極熱、cluster 切不開、需要單實例多執行緒撐單 partition」的壓力。代價是 vendor lock-in、fork 治理走向不確定（KeyDB 公司被收購後策略未明）。

4. Memcached（multi-threaded、功能少）：純 KV 不支援複雜資料結構（hash / sorted set / stream）、適合「資料形狀單純、要 multi-threaded」的 cache-only 場景。如果 application 不需要 Redis 的進階資料結構、Memcached 通常單實例吞吐更高、運維更簡單。

規模化常用組合：ElastiCache for Redis 7.1 在 r7g.4xlarge 上的 AWS 公布上限（單節點百萬級 RPS、單 cluster 5 億 RPS）+ Cluster 模式 + 應用層 connection multiplexing。實際配置依工作量跟成本邊界決定、不是「規模化必然全配滿」。對應 9.C6 Tinder 的設計方向。

判讀順序：先確認瓶頸是不是單實例 command 吞吐（CPU 單核滿載 vs 整體 RAM / network 是否還有 headroom）、再選方案。應用層 key 分布不均（hot key）跟 single-threaded 限制是兩個獨立議題、混在一起會誤選方案。

【執行】把 Redis 用在對的角色

Redis 在高併發場景常見角色有：

• cache
• session store
• counter / rate limit
• presence / online state
• dedup / idempotency key
• lightweight queue / stream

每一種角色都有不同容錯方式。counter、presence 和 cache 的失敗語意各自不同，因此需要依資料角色選擇處理策略。

【策略】分散式 lock 要謹慎使用

Redis 常被拿來做 distributed lock，但這類機制要非常清楚 lease、過期、持有者與失效風險。高併發下最怕的是鎖住之後沒有安全釋放，或以為鎖保證了完整業務一致性。

原則上：

• 鎖應該短
• 鎖持有者要可辨識
• 鎖過期要可接受
• 業務上若能不用分散式鎖，通常應優先考慮更簡單的設計

【延伸】語言端仍然要負責限流與取消

Redis 很快，但應用端仍然要設計邊界。語言端應使用 timeout、cancellation、worker pool、rate limit 或 backpressure 把壓力收斂起來；否則排隊等待 Redis 回應的工作會越堆越多。

跨語言適配評估

Redis 高併發邊界會受語言 runtime 影響。Thread-based runtime 要管理 client pool 與 blocking command；async runtime 要確認 Redis client 不會阻塞 event loop；輕量 task runtime 要限制同時呼叫 Redis 的工作數量。動態語言要特別控制 cache value schema 與序列化格式；強型別語言要避免把內部型別直接當成跨服務 cache contract。

案例對照

這六個案例可以分成兩群讀。規模化容量群（Tinder、Tubi、Snap）的共同訊號是「sustained growth 下 cache 變主要服務面、容量規劃跟單實例邊界要重新設計」、本章「Cache 容量規劃跟 DB 不一樣」跟「Redis 規模化的單執行緒邊界」段直接對應；跨區資料平面群（Meta TAO、Netflix EVCache、Meta mcrouter）的共同訊號是「cache 變成跨區資料層、需要路由治理跟一致性窗口」、詳細展開在 2.7 cache copy boundary 的跨區一致性窗口 跟 2.8 cache data shape。兩群讀法切入點不同、本章先處理前者的高併發 / 容量議題、後者跨章節讀。

小結

高併發服務處理 Redis 的核心原則：client 共用、操作要短、pipeline 要有節制、熱點 key 要設計、cache miss 要防 stampede、鎖要保守使用。

規模化補充：cache 角色變化（DB 補救 → 主要服務面 → 資料平面）主寫於 _index 規模化下 cache 的角色光譜、本章在角色已落「主要服務面」或「資料平面」時提供高併發判讀。Redis 規模化的單執行緒邊界有四個選項（cluster / I/O thread / KeyDB 等 fork / Memcached）、判讀順序是先確認瓶頸再選方案。

基本流程

cache aside 的讀路徑是「先讀 cache，miss 後回源，再回填 cache」；寫路徑是「先寫 source of truth，再做 cache invalidation 或版本更新」。這個流程讓正式狀態維持單一責任，同時讓熱門讀取獲得低延遲。

實務上要先定義 freshness window。每個資料類型可容忍的不新鮮時間不同：商品介紹可接受秒級延遲，價格、庫存、權限與配額則需要更短窗口或即時失效。

失效策略

失效策略的責任是控制 cache 和 source of truth 之間的偏差。常見做法有三類：

1. 事件驅動失效：寫入成功後推事件刪 key 或更新版本，適合正確性要求高的資料。
2. TTL 失效：以時間上限控制資料壽命，適合可短暫不新鮮的資料。
3. 混合策略：事件失效為主、TTL 為保底，適合多來源寫入或跨區快取。

stale data 是快取系統的常態成本，視為例外事件會導致設計盲區。設計時要先定義可接受的 stale 形式，再設計對應補償與回退路徑。

應用層 + 邊緣層 Invalidation Pipeline

當系統同時用應用層快取（Redis、本機 cache）跟邊緣層快取（CDN）時、失效策略要把兩層當「一條 pipeline」設計、不能各自獨立 purge。兩層失效的物理特性差異：

正確順序是「先應用層、再 CDN」：

1. 業務寫入完成、source of truth 更新
2. Purge 應用層 cache（毫秒級完成）
3. Purge CDN（秒級到分鐘級）
4. 等 CDN purge 完成的 ack（或設等待窗口）

順序顛倒會出事 — 若先 purge CDN、CDN 全球節點 miss 後到 origin 拉資料、若 origin 應用層還是舊 cache、CDN 會把舊資料回填到全球節點、stale 被「重新永久化」一個 TTL 週期。

實務上的權衡是「CDN purge ack 是否要等」。等了會讓 write API latency 升高到秒級、不等則必須接受短暫雙層不一致。價格 / 庫存類資料適合「短 TTL + 等 purge ack」、blog 文章類適合「長 TTL + 不等 ack」。詳見 5.9 邊緣分發與靜態資源 的 purge 操作模型。

Cache aside vs write-through 的選擇

選 cache 模式由 miss 成本 跟 寫入頻率 的取捨決定。Cache aside、write-through、write-behind 三種主流模式各自適合不同業務壓力。

Cache aside（read-through）：寫入只動 source-of-truth、讀取 miss 時才填 cache。適合寫入頻率低於讀取、cache 可以重建、寫入失敗時 cache 保持不污染的場景。常見於商品詳情、推薦列表、設定值這類 read-heavy 資料、業務代價是 cache miss 時用戶等待回源、可接受。

Write-through：寫入同時動 source-of-truth + cache、保證 cache 永遠最新。對應 2.C5 Shopify Write-through Cache — Shopify 在 Shop App 後端的 read-heavy 路徑用 write-through 降低 cache miss 風險、改善熱門資料讀取穩定性。適合場景：cache miss 成本很高（回源慢或會壓垮 origin）、寫入流量可控、資料更新時間可預測。典型應用包括熱門商品的庫存 / 價格、用戶 session、需要避免讀路徑抖動的場景。

Write-behind（async）：寫入只動 cache、async 同步到 source-of-truth。適合寫入頻率極高、source-of-truth 跟不上、可接受 cache crash 丟失少量資料的場景。常見於 counter、rate limit、metrics aggregation 這類 吞吐優先、可接受短暫不持久 的資料。代價是 cache crash 會丟最近 N 秒寫入、要確認業務代價可承受。

判讀順序：先看 read/write 比例（read-heavy 偏 cache aside / write-through、write-extreme 偏 write-behind）、再看 miss 成本（miss 貴選 write-through、miss 便宜選 cache aside）、最後看持久性需求（不可丟選 write-through、可丟選 write-behind）。

Cache 模式選擇的判讀順序

當「重算成本」「資料一致性」「持久性」三個維度互相衝突、選擇優先序：

1. 持久性必須（不可丟、無法重建）→ 必須選 write-through 或 persistent store + cache、不能選 write-behind 或純 cache aside
2. 持久性可接受失損 + 一致性嚴格（餘額、權限類）→ write-through 同步更新、確保 cache 不 stale
3. 持久性可接受失損 + 一致性可放寬 + 重算貴 → cache aside + 較長 TTL、減少回源
4. 持久性可接受失損 + 一致性可放寬 + 重算便宜 → cache aside + 短 TTL 或 write-behind

例如 ML feature store 場景（9.C25 Tubi）— 持久性可接受失損（feature 可重算）、一致性可放寬（推薦演算法）、重算便宜（feature engineering pipeline 跑得到）— 落在第 4 類、Tubi 把 feature store 從 ScyllaDB 遷到 ElastiCache 是合理取捨。p99 落在 ElastiCache 的 < 10ms 範圍（先前 ScyllaDB-based 架構為 ML inference 路徑的延遲瓶頸、案例未公開 ScyllaDB 端具體延遲數字）。

判讀重點：cache 的本質是用 miss 風險換取 latency；資料若無法重建、需採 persistent store 並接受 latency 成本；資料若可重建但一致性嚴格、可用 cache 但要 write-through 確保即時收斂。詳見 2.7 cache copy boundary 的「Cache vs Persistent Store 取捨」段。

判讀訊號與回源保護

cache 命中下降時，來源系統會承受瞬間回源壓力。回源保護需要和失效策略一起設計：

cache stampede 與 thundering herd 都是回源保護議題；重點是把來源系統視為有限資源，讓 miss 風險可控。

服務情境

商品詳情頁是典型 cache aside 場景。頁面讀取需要組合商品主檔、價格、庫存與行銷標籤。主檔可用較長 TTL 與背景更新，價格與庫存則用事件失效與較短 TTL，讓讀取延遲與正確性維持平衡。

當促銷開始時，大量熱門商品同時被讀取。這時 cache 策略的重點從命中率轉到來源保護與新鮮度控制：是否能限制回源尖峰、是否能快速修正錯誤資料、是否能在事故時降級。

常見誤區

把命中率當作唯一目標，會忽略資料語意與失敗代價。命中率高不代表結果正確，尤其在價格、權限、配額類資料。

把 cache 當成正式資料來源，會讓資料修復與稽核變複雜。快取系統適合承擔讀取加速，不適合承擔正式狀態的最終判定。

案例回寫

cache aside 的失效風險可用 2.C9 反例 做回寫。先看事件中的失效節奏：是大批 key 同時過期、失效順序錯置，還是熱點 key 回源放大，再對照本章的 freshness window、回源保護與容量策略。 這個案例主要支撐的是「失效節奏與回源壓力」判讀，不直接支撐分散式鎖租約或 queue replay；若是互斥控制或重播問題，應轉到 2.4 或 3.x。

命中率看似正常但業務錯誤上升時，先回到本章檢查值語意與 key 版本化，再把量測缺口接到 4.17 Telemetry Data Quality。

跨模組路由

cache aside 的設計會直接影響觀測、驗證與事故處理。

1. 與 01 的交接：source of truth 與查詢壓力回到 1.1 高併發讀寫邊界。
2. 與 04 的交接：hit ratio、origin QPS、stale read 與 eviction 進入 Telemetry Data Quality。
3. 與 06 的交接：回源保護與壓測邊界進入 Experiment Safety Boundary。
4. 與 08 的交接：失效策略誤配與 stampede 事故回寫 Incident Evidence Write-back。

下一步路由

規模成長路線下一站 → 5.9 邊緣分發與靜態資源：應用層快取上面還有 CDN 邊緣層、兩層失效時序要對齊（先 purge 應用層、再 purge 邊緣層、避免邊緣回填到應用層舊資料）。

其他延伸方向：

• 進一步處理 TTL、容量與淘汰策略 → 2.3 TTL 與 eviction
• 快取策略在真實事件中的失敗與修復 → 2.C9 反例

TTL 是新鮮度預算

TTL 是資料類型的新鮮度預算，用單一時間常數理解它會漏掉關鍵差異。商品描述、推薦列表、活動文案可容忍較長 TTL；價格、庫存、配額、權限則需要更短 TTL 或事件失效。

TTL 設計要連到業務代價。可容忍舊資料的欄位可用長 TTL 降回源壓力；不可容忍錯誤結果的欄位要搭配事件失效與版本控制，讓 TTL 只作為保底機制。

eviction 是容量分流策略

eviction 的責任是當記憶體不足時，優先保留最有價值資料。常見策略如 LRU、LFU、TTL-based eviction，各自偏好不同存取型態。

策略選擇重點在流量形狀，演算法名稱是次要的：高重複讀取場景偏向保留高頻資料；大量一次性讀取場景需要避免短期噪音擠掉核心 key。快取層若同時承載多種資料，應分 key space 或分叢集管理，避免策略互相干擾。

hot / cold data 的容量節奏

hot data 與 cold data 的差異不只在存取次數，也在回源成本與業務風險。熱資料 miss 會直接放大來源壓力，冷資料 miss 多半只影響單次延遲。容量規劃要先保護熱資料，再決定冷資料淘汰節奏。

在促銷或重大活動期間，流量分布常快速改變。TTL 與 eviction 需要具備活動模式：預熱核心 key、分散過期時間、限制單批失效，讓來源系統不被同時回源壓垮。

分層快取的容量跟成本曲線

當熱資料集合超過 DRAM 經濟範圍、單層快取會同時遇到成本跟命中率瓶頸、要把 cache 結構擴展到分層管理。

對應 2.C4 Meta CacheLib / Kangaroo — Meta 把快取結構從 DRAM-only 擴展到 DRAM + flash 分層、改善容量跟成本平衡。當「全部熱資料塞 DRAM」變太貴、把次熱資料推到 flash、保留 DRAM 給最熱的子集。

分層快取的相對特性（具體 size / latency / cost 視硬體配置跟業務 workload）：

• L1 (DRAM)：容量最小、延遲最低、單位成本最高、放最熱的子集 — Meta CacheLib 用這層保留熱度最高的 working set
• L2 (flash / NVMe)：容量比 L1 大、延遲比 L1 高、單位成本比 L1 低 — Meta Kangaroo 在這層處理次熱資料
• L3 (持久 KV)：容量最大、延遲最高、單位成本最低、放冷資料跟 fallback

落層策略要看 資料熱度分布。Zipfian 分布（80/20 法則）下、L1 放最熱 20% 就能命中大部分；如果分布更平、要把 L1 擴大或接受更低命中率。具體 L1 / L2 大小比例要實測 workload 才能定。

對應 2.C7 Cloudflare Cache Reserve — edge cache 跟 persistent reserve 的分層、長尾資料用 reserve 接住、降低 origin 回源。這是 同類設計思維 在 CDN 場景的應用、但分層語意不同（edge cache 是地理分散的、Meta 分層是垂直記憶體 / flash 層）— 兩者都用「冷熱分離降低總成本」、實作機制差異需依場景區分。

Eviction 跟回補延遲要納入共同指標：分層 cache 的訊號不只看 L1 命中率、要看 L1 evict 到 L2 的速率、L2 回補到 L1 的延遲、L3 回源到 L2 的尾巴延遲。混合 metric 才能判斷分層策略是否健康。

判讀重點：分層 cache 屬規模觸發的設計、要從 working set 大小判斷。Working set 在 DRAM 經濟範圍內、單層即可；working set 顯著超過 DRAM 容量、需分層讓 DRAM 集中放最熱子集、其餘走 flash 或更下層。

判讀訊號

常見誤區

把 TTL 統一設定成同一數值，會掩蓋資料語意差異。快取策略應反映資料的重要性與可容忍延遲，而不是單一預設。

把 eviction 視為平台預設值即可，也常導致壓力失真。策略與流量形狀不對齊時，命中率看似可接受，來源系統仍可能在尖峰被回源壓垮。

案例回寫

TTL/eviction 的容量節奏可用 2.C9 反例 回寫。先看事件中的過期同步與回源尖峰，再回到本章檢查 TTL 分布、淘汰策略與熱資料保護是否同時成立。 這個案例主要支撐的是「容量淘汰與過期波形」判讀，不直接支撐資料庫交易切分或部署切流策略；若事件核心在交易提交或 rollout 批次，應轉到 1.3 或 5.2。

當 eviction 上升但命中率未明顯下降時，先補 value size 與 key 分布監控，再把量測定義回寫到 4.17 Telemetry Data Quality。

跨模組路由

TTL 與 eviction 設計會直接影響觀測、驗證與事故處理。

1. 與 2.2 的交接：讀寫失效流程落在 cache aside。
2. 與 4.17 的交接：新鮮度與容量訊號進入 Telemetry Data Quality。
3. 與 6.20 的交接：尖峰演練與停損邊界進入 Experiment Safety Boundary。
4. 與 8.22 的交接：容量失配與快取事故教訓回寫 Incident Evidence Write-back。

下一步路由

要把 TTL/eviction 放進失效流程，接著讀 2.2 cache aside 與失效策略。要看容量與策略失配案例，接著讀 2.C9 反例。

鎖與租約

分散式鎖通常採租約語意：持鎖者在租約有效期內擁有操作權，租約到期後鎖自動釋放、需重新競爭。租約的存在是為了處理「持鎖者掛掉但沒釋放鎖」這個分散式系統無法避免的情況——沒有租約，一個 crash 的節點會讓鎖永遠卡住。代價是引入時鐘漂移、網路延遲與續租失敗這幾個新風險。

在 Redis 上，取鎖是一個原子命令：SET lock:order:42 <token> NX PX 30000。NX 保證只有 key 不存在時才寫入，這讓「檢查鎖是否被持有」與「取得鎖」變成單一原子操作，避免兩個節點同時判斷「沒人持鎖」後都寫入。PX 30000 設定 30 秒租約，持鎖者 crash 時鎖會在租約到期後自動消失。<token> 是每個持鎖者產生的唯一隨機值，它的作用在釋放階段才顯現。

釋放鎖不能用單純的 DEL lock:order:42，因為這會誤刪別人的鎖。考慮這個時序：節點 A 取得鎖、處理超過 30 秒、租約到期自動釋放、節點 B 取得同一把鎖；此時 A 終於處理完、執行 DEL，刪掉的是 B 的鎖。正確的釋放是「比對 token 相同才刪」，而這個 check-and-delete 必須原子，用 Lua script 達成：

1if redis.call("GET", KEYS[1]) == ARGV[1] then
2  return redis.call("DEL", KEYS[1])
3else
4  return 0
5end

ARGV[1] 帶入持鎖者自己的 token，只有 token 吻合才刪。這把「釋放鎖」從一個盲目的刪除，變成「確認我仍是持鎖者後才釋放」的條件操作。

租約長度要對著任務耗時分布校準，而非拍一個固定值：租約要明顯長於正常任務的 P99 耗時，避免工作還沒做完租約就過期、引發雙持鎖；但也不能長到讓 crash 的持鎖者把鎖卡住太久。兩個方向夾出一個區間，長尾工作再用 watchdog 補足。

續租策略要明確：何時續租、續租失敗如何降級。長時間工作會用 watchdog 在租約過半（約 T/2）時用 PEXPIRE 延長租約，讓鎖跟著工作存活；但 watchdog 也意味著鎖可能被無限延長，需要設一個絕對上限（例如業務超時的數倍）避免一個卡住的工作永久佔用鎖。若只依賴「拿到鎖就安全」的假設、不處理續租失敗，異常時容易產生重複副作用。

split brain 與 fencing

split brain 常見於網路分割或 process 暫停（GC stop-the-world、容器被搶占）後恢復。核心問題是租約：節點 A 取得鎖後發生一次長 GC 暫停，暫停期間租約到期、鎖被節點 B 取得，A 從暫停中醒來時仍「以為」自己持有鎖，於是 A 與 B 同時對下游寫入，互斥語意失效。這是基於租約的鎖在自身層無法消除的時序窗口，解法要往下游推——讓擁有正式狀態的那一層成為最終仲裁者，而非期望鎖本身堵住這個窗口。

fencing token 的責任是把這個問題推到下游解決：每次取鎖時發一個單調遞增的 token，持鎖者對下游的每個寫入都帶上這個 token，下游記住「見過的最大 token」並拒絕比它小的寫入。回到上面的時序，A 帶 token 33、B 帶 token 34，當 A 醒來用 token 33 寫入時，下游已經接受過 34，於是拒絕 33。token 的單調遞增可以用 Redis 原子計數器（INCR fence:order:42）或鎖服務自己維護的自增序號實作，關鍵是取鎖動作本身要保證拿到的序號嚴格遞增。fencing token 讓下游成為仲裁者，鎖只負責減少競爭、不再是唯一的正確性保證。

若下游無法驗證 fencing token（例如下游是不支援條件寫入的第三方 API），distributed lock 的保護能力會明顯下降——它只能降低衝突機率，無法消除雙寫。這時更穩定的做法是改成資料版本控制或條件更新（WATCH/MULTI 的樂觀鎖、資料庫的 UPDATE ... WHERE version = ?），把互斥下沉到擁有正式狀態的那一層。

Redlock 與單節點的取捨

單節點 Redis 鎖有一個可用性缺口：持鎖期間 Redis 主節點故障、failover 到還沒同步該鎖的副本時，新主節點上這把鎖不存在，另一個節點能立刻取得，造成雙持鎖。Redis 作者提出的 Redlock 演算法用多個獨立 master（通常 5 個）解這個問題：向所有節點取鎖，取得多數（3/5）且總耗時在租約內才算成功，藉冗餘避免單點 failover 造成的鎖遺失。

Redlock 是否真的更安全有公開爭論。Martin Kleppmann 的批評指出，Redlock 依賴各節點時鐘不發生大幅跳動，而 GC 暫停與時鐘校正這類事件仍會讓持鎖者醒來時鎖已失效；更進一步，若 NTP 時鐘跳躍發生在取鎖過程中，各節點對租約是否有效的判斷本身就可能出錯，Redlock 賴以成立的多數決計數因此無法可靠排除雙持鎖。也就是說，Redlock 提升了「鎖不會因單節點故障而遺失」的可用性，但沒有解決「持鎖者暫停導致的 split brain」，後者仍需 fencing token。判讀因此落在：鎖只是效率優化（偶爾雙跑代價可接受）時，單節點 Redis 鎖足夠且運維簡單；鎖牽涉正確性（雙跑會造成金錢或資料損壞）時，無論單節點還是 Redlock 都不足以單獨成立，必須有 fencing token 或下游條件寫入兜底。

何時使用、何時轉向

distributed lock 在「偶爾失效的代價可控」的場景是一個效率優化工具，降低重複工作的機率而非保證互斥。符合這個特徵的場景包括排程任務避免重複執行、單資源批次工作協調、短期臨界區互斥。以 cron job 為例，偶爾被兩個節點同時觸發時，若任務本身 idempotent，重複執行只是浪費資源而非產生錯誤結果，鎖把這類浪費的機率壓低就足夠。

讀取路徑上避免 cache miss 風暴的 single-flight 互斥也屬這一類，但租約特性不同：熱門 key 失效時用一把短鎖讓單一請求回源重建快取、其餘請求等結果，偶爾多跑一次回源的代價可控。它的鎖租約通常很短（一次回源的時間），競爭集中在少數熱門 key，與批次任務的長租約、低競爭剖面相反，校準時要分開看。

高價值交易資料更新則相反，優先使用資料庫交易與唯一約束，將鎖作為輔助而非核心一致性機制。扣款、出貨、配額扣減這類操作，正確性不能依賴「鎖沒失效」這個無法保證的前提，而要靠資料層的唯一約束或版本檢查讓重複操作在最後一刻被擋下。

當鎖競爭成為常態、租約續租頻繁失敗、鎖持有時間與業務耗時高度耦合時，代表模型需要轉向分片、隊列化或版本檢查。鎖競爭高通常是粒度設計問題：把單一全域鎖換成依資源分片的細粒度鎖（lock:order:42 而非 lock:orders），讓不相關的資源互不阻塞。若工作本身就是序列化處理一批項目，改用 message queue 的單一 consumer 語意，比用鎖模擬序列更穩定。

判讀訊號

常見誤區

把分散式鎖當作通用一致性解法，會讓錯誤責任落在錯誤層級。最常見的具體形狀是「用鎖保護寫入、但讀取路徑不過鎖」：寫入互斥成立了，讀取卻仍可能讀到未提交或 stale 的值，不一致沒有被鎖擋住。鎖負責互斥協調，資料正確性要由資料模型與交易邊界保護，讀寫兩端要納入同一套一致性設計、而非只鎖寫端。

用單純的 DEL 釋放鎖，是最容易在程式碼裡漏掉的一個錯誤。租約到期後鎖可能已被別人取得，盲目 DEL 會誤刪他人的鎖、讓互斥瓦解。釋放一律要走 token 比對的條件刪除。

把 Redlock 或多節點鎖當成正確性保證，是第二個誤區。多節點冗餘提升的是「鎖不會因單點故障遺失」的可用性，不是「持鎖者暫停不會造成雙寫」的正確性。需要正確性時，fencing token 或下游條件寫入才是真正的防線，鎖只是減少競爭。

把租約時間固定為常數，也會在流量波動下放大風險。租約太短會在正常工作未完成時就過期、引發雙持鎖；太長則讓 crash 的持鎖者長時間卡住鎖。租約策略需要和任務耗時分布與錯誤模型一起校準，長尾工作要靠 watchdog 續租而非把租約一律設大。

情境回寫

分散式鎖失效回寫到真實服務時，最常見的形狀是排程任務的重複執行。一個跨多節點部署的對帳 job 用 distributed lock 確保同一批次只有一個節點處理；當持鎖節點發生長暫停、租約到期被另一節點接手，而暫停節點醒來後仍繼續寫入時，同一批對帳被執行兩次。回寫時先判讀鎖失效來自時序漂移、網路分割還是續租策略，再決定防線往哪裡補。

這個形狀支撐的是「互斥語意在異常下失效」的判讀。若任務本身 idempotent，重複執行只是浪費資源；若會產生重複副作用（重複出帳、重複通知），正確性不能靠鎖，要靠下游的 fencing token 或唯一約束。高風險路徑可接到 6.20 Experiment Safety Boundary 做故障演練。

跨模組路由

1. 與 2.2 的交接：鎖搭配失效策略回到 cache aside 與失效策略。
2. 與 1.3 的交接：高價值資料一致性回到 transaction 與一致性邊界。
3. 與 6.20 的交接：鎖失效演練與停損條件回到 Experiment Safety Boundary。
4. 與 8.19 的交接：鎖衝突與回退判斷回到 Incident Decision Log。
5. 與 2.6 的交接：split brain 與鎖失效的弱點可從威脅建模角度重新盤點，回到 快取威脅建模。

下一步路由

要看快取層一致性與容量壓力，接著讀 2.3 TTL 與 eviction。要看鎖語意在事故裡的擴散方式，接著讀 2.C9 反例。

狀態模型

presence 模型通常包含 subject、node、last_seen_at、ttl。主體可能是使用者、裝置、連線或工作者。模型設計重點是查詢責任：需要查單一主體是否在線、查群組在線清單，還是查節點負載分布。

presence 資料具備高變動、短保留特性。設計時應避免把正式業務欄位混入 presence store，讓它保持可快速更新與快速過期。

heartbeat 與 expiration

heartbeat 的責任是維持活性訊號，expiration 的責任是清理失效狀態。heartbeat 間隔太長會放大誤判離線，太短會增加寫入壓力。expiration 視窗要和網路抖動容忍度一起設計。

穩定做法是定義「可接受延遲在線」窗口，而不是追求絕對即時。presence 判讀通常是近即時近似，不是強一致保證。

cross-node query

跨節點查詢要先明確一致性需求。聊天室在線名單可容忍短暫不一致；調度系統節點可用性則需要更保守窗口與校驗策略。查詢層應同時提供快取讀取與回源校正路徑，避免單一路徑失真。

在多區部署中，presence 常採區域內優先、跨區聚合延遲同步。這樣能降低廣域寫入成本，同時保留可接受的全域可見性。

cleanup 策略

cleanup 的責任是避免殭屍狀態堆積。定期掃描、lazy cleanup、事件驅動清理可混合使用。清理策略要與業務容忍度對齊：社交場景可容忍秒級延遲清除，調度場景則需更快收斂。

判讀訊號

常見誤區

把在線狀態儲存當正式狀態來源，會讓一致性與修復成本快速上升。presence 模型適合即時協調，最終業務判定仍由正式資料層承擔。

把 heartbeat 當固定頻率任務，也會造成高峰寫入抖動。頻率應該與線上人數與連線型態一起調整。

案例回寫

presence 模型可用 2.C2 Meta：mcrouter 跨區路由 回寫。先看跨區路由如何影響在線可見性，再回到本章檢查 heartbeat 視窗、跨節點聚合與清理節奏是否一致。 這個案例主要支撐的是「跨區可見性與狀態新鮮度」判讀，不直接支撐 lock 租約或 queue 語意；若問題是互斥衝突或重播邊界，應轉到 2.4 或 3.x。

若區域內在線正常、跨區可見性延遲偏大，先調整跨區同步策略與 fallback 壽命，再把影響評估接到 8.20 Customer Impact Assessment。

跨模組路由

1. 與 2.3 的交接：保留與清理策略回到 TTL 與 eviction。
2. 與 4.17 的交接：presence 資料品質與延遲偏差回到 Telemetry Data Quality。
3. 與 6.22 的交接：穩態定義與高峰演練回到 Steady State Definition。
4. 與 8.20 的交接：即時狀態誤判造成客戶影響回到 Customer Impact Assessment。
5. 與 2.10 的交接：presence 狀態變更如何即時廣播給其他節點回到 Pub/Sub 與即時 fan-out。

下一步路由

要看快取層一致性與失效策略，接著讀 2.2 cache aside 與失效策略。要看 presence 狀態變更如何即時扇出給其他節點，接著讀 2.10 Pub/Sub 與即時 fan-out。要看跨規模 presence 路由案例，接著讀 2.C2 Meta：mcrouter 跨區路由。

哪些快取場景要先做弱點盤點

快取弱點會在特定條件下快速放大，這些條件出現時值得在設計階段就做一次盤點，而不是等流量打上來才發現。

熱門資料高度集中是第一個訊號。當少數 key 承載大部分讀取，形成 hot key 時，這些 key 的失效或污染影響面被流量放大：一個被污染的熱門商品價格，會在 TTL 週期內被數百萬次請求讀到。攻擊者只要能影響一個熱門 key，就能用快取的扇出能力把單點錯誤放大成大規模事故。

同一份資料被多個系統共用是第二個訊號。當一份快取資料同時被 API、搜尋與報表讀取，污染這份資料的後果會跨系統擴散，而各系統對資料正確性的假設不同——API 可能容忍短暫陳舊，計費報表不能。共用快取讓「誰負責驗證這份資料」變得模糊。

失效策略依賴多服務協作是第三個訊號。當快取失效需要多個服務按順序執行才成立時，任何一個環節被延遲或繞過，都會留下一個 stale 窗口。攻擊者可以針對這個協作鏈的最弱環節，製造可預測的不一致窗口。

匯出、權限摘要或價格資料大量走快取是第四個訊號。這幾類資料的錯誤直接對應到金錢、越權或合規後果，一旦快取成為它們的讀取路徑，快取的一致性強度就決定了這些高風險判斷的正確性。

快取弱點的檢查順序

弱點盤點依「資料責任 → 失效面 → 放大面 → 污染面」的順序展開，每一層對應一個攻擊者會利用的弱點。

第一層看資料責任，先區分 source of truth 與快取副本。攻擊者最想找的是「被當成正式狀態的快取副本」——如果某個權限判斷直接信任快取值而不回源驗證，污染這個快取值就等於提權。檢查的方法是追每個快取讀取點，確認它讀到的是可重建的副本，還是被誤用成不該被快取的正式判斷依據。

第二層看失效面，檢查 cache invalidation、ttl 與 eviction 規則是否一致。失效面的弱點是「stale 窗口可被預測或延長」：若失效只靠廣播通知而沒有 TTL 兜底，攻擊者讓廣播漏送就能讓某節點長期持有舊值；若 TTL 設得過長，污染或過期資料的影響期就被拉長。

第三層看放大面，檢查 cache stampede、thundering herd 與回源壓力保護。放大面的攻擊是 cache penetration：攻擊者枚舉大量必定不存在的 key（不連續的 id、構造的非法 slug），這些查詢全部 miss 並穿透到資料庫，把快取的保護作用繞過、直接打垮 origin。防線是對不存在的 key 也做短期 negative cache（把「查無此 key」這個結果也快取一小段時間，擋掉重複穿透），以及對回源路徑加 rate limit 與單飛（single-flight，讓同一 key 的並發回源只有一個真正打到資料庫、其餘等結果）保護。negative cache 自身有代價：真實資料建立後要等 negative 項過期才會被命中，TTL 要夠短，避免新上架資料被「查無」結果短暫遮擋。

第四層看污染面，檢查 key 設計、租戶隔離與欄位遮罩是否防止快取污染與越權讀取。污染面最常見的弱點是 key 命名沒有把租戶或權限維度編進去：若兩個租戶的資料共用同一個快取 key，一個租戶就能讀到另一個租戶的快取值。key 設計要讓隔離維度成為 key 的一部分，而非依賴應用層在讀取後才過濾。

第五層看推斷面，檢查 cache 命中與否是否會透過回應時間洩漏資訊。cache hit 與 miss 的延遲差異本身是一個 side-channel：攻擊者用一批查詢的回應時間分布，可以推斷某個帳號、商品或 slug 是否存在，即使回應內容本身有做存在性遮罩。對帳號存在性、未上架商品這類敏感判斷，要讓 hit 與 miss 的可觀察延遲一致（例如 miss 也走一段固定延遲），或把存在性判斷的快取與對外查詢路徑分離。這層在敏感資料才需要盤點，一般可重建副本不受此威脅。

快取弱點先表現為資料錯誤而非停機

快取事故的判讀重點是它的早期症狀先表現為資料錯誤，而停機往往是後續才浮現的次級症狀。價格、庫存、權限摘要若短時間錯誤，系統照常回應請求、監控的可用性指標一切正常，但回應的內容是錯的，直接造成客訴與營運損失。這種「服務還活著但說錯話」的故障比停機更難被即時發現，因為它不觸發可用性告警。

回源壓力缺少保護時，快取問題還會反向擴散。原本快取是用來保護資料庫的，但當 stampede 或 penetration 讓大量請求同時穿透，快取從保護層變成放大層，把一個快取層的問題擴散成資料庫與下游服務的連鎖過載。弱點盤點因此要把「快取失效時，壓力會打到哪裡」當成必答問題。

低延遲與一致性強度的取捨

快取命中率越高，延遲與成本越好，同時一致性風險也越高。按資料重要性分層是平衡這個張力最穩定的做法，比對所有資料套同一套快取策略更能讓高風險資料拿到該有的一致性強度。

高風險資料採較短生命週期與強驗證。價格、權限、餘額這類錯誤代價高的資料，用較短 TTL（典型在數秒到數分鐘量級）縮小污染與陳舊的影響窗口，並在關鍵判斷點保留回源驗證，讓快取只承擔加速、不承擔最終正確性。低風險資料採較寬鬆策略以保留效能收益。商品描述、頭像、靜態文案這類偶爾陳舊無實質後果的資料，用較長 TTL（數十分鐘到數小時）換取更高命中率。具體秒數沒有通用值，依該資料的陳舊容忍度決定；分層的判準是「這份資料錯誤幾分鐘的代價是什麼」，代價高的往一致性傾斜，代價低的往效能傾斜。

進入實作前要先定義的最低控制面

弱點盤點的產出是一組進入實作前必須先定義清楚的控制面，缺少其中任何一項，後續的快取設計都是在未定義的安全假設上往前蓋。每一項控制面同時是一個診斷工具：可以用「若沒有它會看到什麼現象」反過來判斷現有系統是否缺這道防線。

快取資料分級與可接受陳舊窗口要先定義，這決定每類資料的 TTL 與是否需要回源驗證。沒有分級，所有資料會被同一套策略對待，高風險資料的陳舊窗口被低風險策略放寬。未定義的早期訊號是「所有 key 用同一個預設 TTL」「說不清哪些資料錯了會出事」。

失效策略與回源保護規則要先定義，這決定 stale 窗口的上界與回源洪水的防線。失效要明確是廣播、TTL 還是事件驅動，並確認廣播類失效一定有 TTL 兜底；回源要明確 negative cache、single-flight 與 rate limit 的配置。未定義的早期訊號是「失效靠廣播但沒有 TTL 兜底」「miss 尖峰會直接打到資料庫」。

key 命名、租戶隔離與敏感欄位限制要先定義，這決定污染與越權讀取的防線。隔離維度要編進 key、敏感欄位要在寫入快取前就遮罩，而非依賴讀取後過濾。未定義的早期訊號是「快取 key 不含租戶 id」「敏感欄位整包序列化進 cache」。

快取異常時的降級與回復流程要先定義，這決定事故發生時系統往哪個方向退。降級要明確是「快取失效時回源並接受延遲上升」還是「直接拒絕並保護資料庫」，並預先演練回復路徑，避免事故當下才設計。未定義的早期訊號是「沒人能回答快取掛掉時系統會怎樣」。

判讀訊號

可用性正常但資料錯誤之所以難察覺，是因為可用性監控設計上只看系統有沒有正常回應，不掃回應內容對不對，污染或陳舊因此可以在告警全程靜默的情況下持續數小時。這類問題要靠資料正確性監控而非可用性監控才能發現，弱點盤點要確認高風險資料有對應的正確性檢查，而不是只看 latency 與 error rate。

常見誤區

把快取副本當成正式狀態信任，是最危險的誤區。權限、餘額、配額這類判斷若直接信任快取值而不回源驗證，污染快取就等於繞過業務規則。快取承擔加速，正式判斷的正確性要由 source of truth 保證。

只用廣播做失效而不設 TTL 兜底，是第二個誤區。廣播是 at-most-once，總有漏送可能，缺 TTL 時一次漏送就讓某節點長期持有污染或陳舊資料。TTL 是讓失效失敗的影響有上界的保險。

把租戶隔離放在讀取後過濾，是第三個誤區。若快取 key 不含租戶維度、靠應用層讀出後再過濾，任何一個漏掉過濾的讀取路徑都會洩漏跨租戶資料。隔離要編進 key，讓不同租戶在儲存層就不共用快取項。

案例回寫

快取放大面的弱點盤點可用 2.C9 反例：stampede rollout regression 回寫。該案例的回源洪水來自部署回歸而非惡意攻擊，放大後果相似——大量請求同時 miss、穿透到 origin、把快取從保護層變成放大層——但觸發源不同：2.C9 是意外的部署回歸，攻擊場景則是刻意查詢大量不存在的 key。後果相似讓防護有共通部分（single-flight、回源 rate limit），觸發源不同則讓防線各有重點：部署回歸重在發布保護與 warmup，惡意穿透重在 negative cache 與請求來源限制。回寫時要保留「失效時壓力打到哪裡、單飛與 rate limit 是否就位」的判讀，把它從事後復盤前移到設計階段的弱點盤點。

這個案例主要支撐放大面與回源保護的判讀，不直接支撐污染面或租戶隔離；若根因是跨租戶資料洩漏或快取被當正式狀態，應回到 key 設計與 source of truth 邊界，而非回源保護。

跨模組路由

1. 與 2.2 的交接：失效面的策略與 TTL 兜底回到 cache aside 與失效策略。
2. 與 2.7 的交接：快取副本與正式狀態的邊界回到 Cache Copy Boundary 與 Freshness。
3. 與 2.1 的交接：hot key 與 stampede 的放大面保護回到 高併發下的 Redis 讀寫邊界。
4. 與 6.20 的交接：弱點盤點後的故障演練與停損條件回到 Experiment Safety Boundary。

下一步路由

要看快取副本與正式狀態的界線如何劃分，接著讀 2.7 Cache Copy Boundary 與 Freshness。要看放大面的回源保護如何在實作中成立，接著讀 2.9 Cache Migration 與 Stampede Rollback 實作示範。

Cache Copy Boundary

Cache copy boundary 的責任是把可重建副本和正式狀態分開。source of truth 承擔最終判斷，cache 承擔低延遲讀取與來源保護。

商品描述、公開設定、推薦摘要通常是可重建副本。價格、庫存、權限、配額與付款狀態雖然可以被快取，但它們的錯誤會直接影響交易或安全判斷，因此 freshness 與 invalidation 要更嚴格。

Freshness

Freshness 的責任是定義資料可接受的 stale window。不同欄位需要不同 window，TTL 策略要跟欄位風險分層對齊。

stale data 本身是快取常態成本，定義 stale 代價能讓團隊選擇對應保護。可接受 stale 的資料可用 TTL 管理，高代價 stale 的資料需要事件失效、版本化 key 或回源確認。

商品描述與推薦清單偏向體驗資料，短暫 stale 的主要代價是使用者看到較舊內容。價格與庫存偏向交易資料，stale 會改變付款、履約或客服判斷。權限與配額偏向控制資料，stale 會放大越權、濫用或計費風險。這些差異決定快取策略要分欄位設計，並以服務層邊界統一交接。

Invalidation

Invalidation 的責任是讓快取副本在正式狀態變更後收斂。常見模型包含刪除 key、更新 key、版本化 key、事件驅動失效與 TTL 保底。

cache invalidation 要和資料責任對齊。價格類資料適合事件驅動失效加短 TTL；商品描述可以長 TTL 加背景刷新；權限類資料要能在撤權後快速失效。

Cache 不一致的主要來源點

規模化 cache 的不一致主要由 topology 變動事件 觸發、不是 TTL 設定。對應 2.C1 Meta Cache Consistency Upgrade — 案例指出 promotion、shard move、故障恢復是三類主要事件來源、傳統 invalidation 在大規模系統難以維持穩定。

三類事件的典型機制（具體實作依 cluster 設計而異）：

• Promotion / failover：primary 切到 replica 過程中、寫入順序可能跨節點不一致、replica 變 primary 後可能讀到舊資料
• Shard move / rebalance：cluster topology 變更時、部分 key 在搬遷窗口內可能讀到舊 shard 的副本
• 故障恢復：節點重啟後、cache 從 backing store 重建、跟 application 寫入的新值可能交錯

在這些事件中、cache 拓樸隨著事件改變、需要追蹤 mutation 收斂、不只清 key。Meta 的解法是把 mutation tracing 制度化、追蹤每次資料變動是否在所有 cache 副本都收斂。

Mutation tracing 跟一致性指標

Mutation tracing 是 資料變動到所有 cache 副本收斂的時間軸 追蹤、跟一般 cache hit rate 屬不同維度。常見的工程實踐指標（屬 case-derived 推論、非 Meta case 直接揭露具體 SLO）：

• Inconsistency window：從 source-of-truth 寫入到所有 cache 副本反映的耗時（平均 / p99）
• Inconsistency rate：query 取到 stale 副本的比例
• Inconsistency duration distribution：stale 持續時間的分布（看長尾才能識別事故風險、平均值會掩蓋）

這些指標要接到告警跟回退條件、用法接近一般 SLO（例：inconsistency window p99 超過 服務可接受 stale window 觸發保護動作）。具體門檻依業務型態定 — 付款 / 庫存 / 權限類資料的容忍可能在秒級、商品描述可能在分鐘級。

當 inconsistency window 突然拉長、可能是 invalidation pipeline 卡住或 cache topology 變更中、應觸發保護動作（停止寫入、降級到回源、或回退近期變更）。

對應 4.17 telemetry data quality — cache 一致性指標屬於 資料品質指標、要進 evidence chain、跟效能指標分開追蹤。

Origin Protection

Origin protection 的責任是避免 cache miss 把壓力集中打回資料庫或下游服務。快取越接近高流量路徑，越要把 miss 視為需要治理的事件。

保護策略包含：

1. cache warmup 先建立熱門資料覆蓋。
2. singleflight 或 request coalescing 合併同 key 回源。
3. 對回源設 rate limit、timeout 與 fallback。
4. 對短暫找不到的結果使用短 TTL negative cache。

這些策略的共同目標是優先保護正式狀態來源，再提升命中率與延遲表現。

跨區一致性窗口

當 cache 跨多 region 部署、一致性問題從「副本 vs source-of-truth」變成「副本 vs 副本」。同一個用戶在不同 region 看到 cache 內容差異、可能影響業務邏輯（庫存超賣、配額超用、權限延遲）。規模化的 cache 把跨區一致性窗口跟區域容錯設計納入同一模型、不是分開治理（對應 2.C6 Netflix EVCache 跟 2.C2 Meta mcrouter）。

Strong sync 採每次寫入同步到所有 region、延遲高、可靠性高。適合付款 / 庫存 / 權限類資料 — 庫存超賣的代價是業務直接損失（賣出實際沒有的商品）、權限不一致的代價是越權或拒服務、付款延遲一致的代價是重複扣款。這些代價高到值得付跨 region quorum 的 latency 成本。失敗代價路徑：跨 region quorum 不可達時 → 寫入失敗 → 用戶看到操作失敗、業務不繼續寫錯資料。

Async with bounded staleness 寫入主 region、其他 region 在 N 秒內收斂、多數場景夠用、要明確 stale window。適合 B2B SaaS、社群動態、推薦資料 — 用戶可以接受短暫看到舊版內容、但長時間 stale 會影響體驗。失敗代價路徑：跨 region 同步 lag 增長 → 用戶看到不同版本內容 → 累積到 stale window 上限時觸發 alert 跟保護。

Per-region cache 每 region 各自獨立、不跨區同步、靠 backing store 收斂。適合本地用戶為主的資料（區域電商、本地內容平台） — 同一用戶極少跨 region、跨區一致性需求低、為了少數情境付跨區同步成本不划算。失敗代價路徑：跨 region 操作的用戶看到 region 之間不一致 → 業務側手動補償或要求用戶重試。

判讀重點：選哪種跨區一致性跟「同一用戶會不會跨 region 操作」直接相關。全球漫遊用戶（旅遊、跨國商務）要更強的同步；本地用戶為主的服務可以 per-region。

跨 cloud 部署的資料引力

當 application 跟 cache 不在同一 cloud / region、每次 cache lookup 吃跨網路 latency（視 region pair 而定、9.C35 觀察值為 5-30ms）。對「每次互動查多個 cache」的服務、5ms × 10 lookup = 50ms 額外延遲、用戶感受明顯。

對應 9.C35 Snap KeyDB cross-cloud — Snap 把 KeyDB cache 放在 GCP 上、減少跨 cloud cache lookup latency。資料引力原則：data 在哪、cache 跟著去、跨 cloud 走 batch sync 降頻、應用與 cache 共置主資料 cloud。

Multi-cloud cache 部署原則：

• 同 cloud 內：cache + application + DB 都在同一 cloud、cache lookup 在 ms 級內
• 跨 cloud 採 batch sync 降頻：低頻、高延遲容忍的資料同步（每小時 / 每天）、應用本地讀 cache
• 應用與 cache 共置主資料 cloud：高頻、低延遲容忍的路徑跟主資料同 cloud、避免跨 cloud RTT

判讀重點：multi-cloud 架構的 cache 設計要先確定 data 主要在哪個 cloud、其他 cloud 的 application 要靠 batch sync 拿資料。Snap 從 zero-day 就在 GCP、近年走 multi-cloud 時、把 KeyDB 留在 GCP（data 一直在的地方）、避免反向部署引發的隱性 latency。違反這原則會踩到用戶層難以 debug 的延遲瓶頸。

選型前判準

快取服務選型前要先回答四個問題：

1. 快取值是可重建副本，還是被拿來做正式判斷。
2. 每種值的 freshness window 是多久。
3. miss 時來源系統能承受多少回源 QPS。
4. 錯誤資料要如何失效、降級與回寫事故證據。

這些問題先回答後，才進入 Redis data structure、Memcached 設計、Valkey 相容性或 managed cache 的討論。

實體服務討論承接點

實體快取服務文章要承接本篇的 copy boundary 與 freshness。Redis、Valkey、Memcached、DragonflyDB 或 managed cache 的比較，應先問它們如何支援 key 失效、TTL、eviction、warmup、回源保護與觀測訊號，再進入 command 或部署細節。

若服務需要嚴格 freshness，後續文章要比較事件失效、版本化 key、原子更新與 fallback 能力。若服務主要面對高讀取壓力，後續文章要比較連線模型、hot key 保護、memory policy 與 cluster/sharding 行為。若服務需要事故回退，後續文章要比較 key migration、dual read、metrics 與 rollback window。

下一步路由

要進一步處理讀寫流程，接著讀 2.2 cache aside 與失效策略。要把 freshness 放進 rollout 與停損，接著讀 2.9 Cache Migration 與 Stampede Rollback。

Key Space

Key space 的責任是定義快取資料如何被定位、分組、失效與遷移。key 命名要包含資料責任、版本、租戶或區域等必要維度，讓失效與回退可控。

常見 key 維度包含：

1. 資料類型，例如 product、user-permission、quota。
2. 版本，例如 v1、v2。
3. 租戶或區域，例如 tenant、region、locale。
4. 實體識別，例如 product id、user id。

key 缺少版本時，cache migration 會變成破壞性替換。key 缺少租戶或區域時，失效範圍會被放大。

Value Shape

Value shape 的責任是定義快取值的語意與演進方式。完整 JSON blob 適合一次讀取完整資料，但欄位更新與版本相容成本高；hash 適合欄位局部更新，但需要明確欄位責任；set 與 sorted set 適合集合與排名；counter 適合限流或計數。

資料形狀的本質是服務責任選擇，Redis 語法是落地方式。

string / blob 的判讀重點是整包資料是否需要一起讀取與一起失效。hash 的判讀重點是欄位是否真的能獨立更新。set 與 sorted set 的判讀重點是 membership 或排序錯誤會造成什麼後果。counter 的判讀重點是原子性與過期窗口。stream 的判讀重點是這條路徑是否已經接近 message queue 責任。

Access Pattern

Access pattern 的責任是定義快取面對的讀寫節奏。高讀低寫、熱點讀取、短期活動尖峰、租戶隔離與跨區讀取，都會影響 key 設計與容量策略。

高讀低寫適合長 TTL 與背景刷新；熱點讀取需要 hot key 保護；短期尖峰需要 warmup 與分散過期；多租戶場景需要避免單租戶 key 壓垮共享 cache。

Multi-layer Cache

多層快取的責任是分散延遲與來源壓力。常見層次包含 process local cache、distributed cache、CDN 或 search/read model。每一層都需要定義 freshness、失效來源與 fallback。

多層 cache 的主要風險是 stale 疊加。local cache stale、distributed cache stale 與 CDN stale 缺少共同失效策略時，讀者看到的錯誤會很難追。

ML feature store 的多層 cache 設計模式

ML inference 場景的 feature lookup 是多層 cache 的典型應用。9.C25 Tubi feature store 的策略段提出 可重用做法：用 L1 in-process cache + L2 distributed cache + L3 持久 store 三層。Tubi 實做的是把 feature store 從 ScyllaDB 遷到 ElastiCache（屬於 L2 層的選擇）、p99 < 10ms；三層架構是策略段推導出的通用設計、不一定 Tubi 完整實做。

通用三層模式（推導自 9.C25 策略段、實際分層深度視 workload）：

• L1：in-process cache：跟 application 同一 process、避免 network hop、適合最熱的少量 features
• L2：distributed cache（ElastiCache / Memcached）：跨 application instance 共享、能擴容、Tubi 在這層用 ElastiCache 達 p99 < 10ms
• L3：持久 store（ScyllaDB / DynamoDB / S3 + Parquet）：全量資料、cache miss 時的 fallback

判讀重點：每層的 latency budget 跟 stale window 都應依 workload 跟業務容忍度設定。相對序列是 L1 stale window 最嚴、L2 中等、L3 為 source-of-truth 或可重算來源。三層 stale 若無共同失效策略、業務代價會落到 推薦結果不穩定、用戶看到不同 session 推不同內容。

跨 cloud 部署的資料引力（路由：見 2.7）

跨 cloud cache 部署的 資料引力 原則跟 跨區一致性 議題密切相關、主寫場域是 2.7 cache copy boundary 的跨區一致性窗口。本章從 data shape / access pattern 角度補充：當 cache value 包含跨 region 共享的業務資料時、access pattern 自然偏向 同 cloud read + 跨 cloud batch sync、不適合即時跨 cloud lookup。詳見 9.C35 Snap KeyDB 案例。

選型前判準

快取資料形狀選型前要先回答：

1. 讀取是單 key、批次 key、集合、排序還是計數。
2. 寫入是整體替換、局部更新、追加還是原子遞增。
3. 失效是單 key、群組、版本、租戶還是全域。
4. 資料結構是否會讓快取承擔正式狀態責任。

這些問題決定後續要比較 Redis data type、Memcached blob、CDN cache 或應用端 local cache。

實體服務討論承接點

實體快取服務文章要承接本篇的 data shape 與 access pattern。Redis/Valkey 的 hash、set、sorted set、stream 能表達多種資料形狀；Memcached 偏向簡單 key/value blob；CDN 與 local cache 則承擔不同層次的讀取加速。比較服務時要先問 access pattern，再問語法。

若讀取是單 key 或 blob，後續文章要比較 serialization、value size、TTL 與 eviction。若讀取是集合、排名或計數，後續文章要比較資料結構、原子性與容量行為。若讀取跨多層 cache，後續文章要比較失效傳播、stale 疊加與 observability。

下一步路由

要處理 TTL 與容量策略，接著讀 2.3 TTL 與 eviction。要看選定形狀後各型別的操作語意、原子性與記憶體曲線，接著讀 2.11 Redis data types 實作。要處理 presence 類即時狀態，接著讀 2.5 presence store 與即時狀態。

服務路徑與失敗代價

這條路徑是 product-page -> cache -> product-db/pricing-service。商品頁會同時讀取描述、價格、庫存與促銷標籤，快取需要在低延遲與正確性間平衡。

這篇示範的變更是把舊 key product:{id} 演進到版本化 key product:v2:{region}:{id}。演進動機是支援區域價格與促銷欄位拆分，避免舊序列化格式在多區域路徑下持續膨脹。

失敗代價分三層：描述欄位 stale 主要影響體驗，價格 stale 直接影響交易正確性，回源尖峰會擠壓正式狀態查詢容量。這三層要分別設 freshness、gate 與 rollback 條件。

Key Schema 與相容窗口

Key schema 的責任是讓新舊值可共存，不讓切換變成一次性替換。這條路徑採 dual-read 再 dual-write 再 single-read-v2：

1. 讀取先查 v2，miss 再查舊 key，最後才回源。
2. 回填期間新舊 key 同時寫入，保留可回退窗口。
3. v2 命中穩定後，關閉舊 key 寫入，保留舊 key 讀 fallback 一段時間。

相容窗口的重點是讀語意一致。舊 key 與新 key 的值結構不同時，要先有轉換層，避免同一商品在不同 API path 回傳不同語意。

Freshness Window 與資料分級

Freshness window 的責任是把 stale 代價寫成可執行規則，而不是只寫全域 TTL。

TTL 與事件失效要同時存在。TTL 控上限，事件失效控即時性；只用其一都會造成隱性風險。

Warmup 與回源保護

Warmup 的責任是先建立新 key 的可服務覆蓋率，再擴大流量。這條路徑採分批 warmup：region -> category -> hot key list -> 全量。

Warmup completion 的判讀訊號：

1. v2 命中率在目標區間連續穩定。
2. origin QPS 未突破上限。
3. 熱門 key 的 miss 尖峰已被抹平。

回源保護策略：

1. 以 singleflight 合併同 key 同時 miss。
2. 對回源查詢設 rate limit 與超時。
3. 回源失敗時寫入短 TTL 降級值，避免瞬時重試風暴。
4. 針對熱門 key 在切換前做預熱與分散過期。

Cache 切換引發 stampede 的真實事故結構

對應 2.C9 反例：Cache Stampede Rollout Regression — 看似低風險的 cache key 或 TTL 切換、若回源保護不足、會讓熱門資料同時 miss。事故結構屬「讀取路徑同時失去緩衝」的系統性失敗、不只是單一 key 問題。

切換引發 stampede 的三個放大機制會 疊加、不是獨立失效。在 read-heavy 規模化服務（如 Tinder 47M MAU、Tubi feature store）這類場景、典型疊加順序：重試放大先觸發 → 下游放大跟進 → 應用層放大終結：

• 重試放大：用戶請求 miss、應用層或 client SDK 內建重試、每次重試又 miss、單一用戶請求變多次 origin QPS
• 下游放大：cache miss 同時打到 DB、DB 變慢、應用對 cache 設的 timeout 又觸發新 miss、回到 DB 更慢、形成正向循環
• 應用層放大：等待 cache 的 request 堆積、application thread / connection pool 滿、新請求被拒、被拒的請求觸發更多重試

判讀重點：stampede 的早期訊號通常出現在下游 origin（DB QPS 突然超 baseline 數倍）跟 application（latency p99 拉高、request queue length 增加）、不一定先在 cache 層看到。cache hit rate 顯示異常時、事故通常已在中後段。

切換順序決定 stampede 風險

對應 2.C10 對照：規模差異下的快取策略 — 切換順序（先改 key 結構 vs 先改 TTL）會決定是否出現 stampede 連鎖反應、特別在中型服務同時承受活動流量跟版本切換時。

安全切換順序（dual-read 模式、每步停損點不同）：

1. 新 key 寫入啟用：應用層同時寫舊 key + 新 key、讀路徑不變。停損點是「寫入失敗率」、若雙寫失敗率超基線、回退停止啟用。
2. 新 key 命中觀察：讀路徑加入 v2 first / fallback to v1 邏輯、v2 命中率隨自然回填爬升。停損點是「v2 hit rate 爬升曲線」、若曲線停滯、表示 warmup 沒擴散到熱資料、要先 manual warmup。
3. 舊 key 命中率穩定下降：表示新 key 自然 warmup 完成、可進入下一階段。停損點是「舊 key hit rate 是否真的降到目標」、不能只看 v2 hit rate。
4. 舊 key 寫入停止：只寫 v2、舊 key 自然 TTL 過期。停損點是「v2 唯一寫入是否穩定」、若出現 v2 寫入失敗、回退到雙寫。
5. 舊 key 讀 fallback 移除：完全切到 v2 only。停損點是「v2 hit rate 是否已達切換前舊 key 水位」、否則 fallback 移除後直接回源。

應該注意的反模式（會引發 stampede）：

• 應先 warmup 新 key 再刪除舊 key、避免所有讀立即 miss
• 應拆維度切換（key OR TTL OR 序列化各自獨立）、避免多變化疊加讓 debug 困難
• 應先在低流量 region 試跑、再擴大到全量、避免事故時無回退時間

判讀順序：每次切換只動 一個維度（key OR TTL OR 序列化）、先在低流量 region / tenant 試跑、命中率穩定後再擴大。在 Shopify 序列化遷移（2.C3）類場景、停損 KPI 是「新格式編碼成功率」+「舊格式 fallback 觸發率」；在 Tinder 類 schema 變化頻繁場景、停損 KPI 是「v2 cache hit rate 是否在預估 warmup 時間內達標」。對應 9.C20 Zomato 跟 1.7 Schema Migration Rollout Evidence 的同類 expand-contract 思維。

Schema 變更引發的隱性 cache invalidation（路由：見 2.7）

Cache invalidation 模型 主寫於 2.7 cache copy boundary 的 Invalidation 段；本章從 migration 實作步驟 角度補充：schema migration 是 cache stampede 的隱藏觸發點。9.C6 Tinder 案例的警惕段提出 風險推測：「configurable matching」業務邏輯複雜、快取資料的 schema 變化頻繁、一個 schema 變更可能引發 cache invalidation 風險。

Schema 變化讓 cache 失效的三種模式（屬工程實踐推導、非案例直接揭露）：

• 欄位重命名 / 刪除：舊 cache value 反序列化失敗、application 視為 miss、全部回源
• type 變更（int → string、enum 增 case）：反序列化可能成功但語意錯、業務邏輯踩錯
• 序列化格式換（Marshal → MessagePack）：舊格式無法用新 decoder 讀、對應 2.C3 Shopify 的雙軌策略

Migration 實作步驟（按優先序）：

1. Schema migration 前盤點 cache key（最先）：哪些 cache 包含這個 schema 的資料、估算 invalid 範圍。沒這步無法估算 warmup 計畫規模。
2. 大規模 schema migration 配 cache warmup 計畫：預先 warmup、避免用戶觸發 cache miss。warmup 計畫主寫於本章的「Warmup 與回源保護」段。
3. 新欄位用 versioned key（同步進行）：product:v2:{id} 跟 product:v1:{id} 並存、避免雙寫干擾。對應 2.C3 Shopify 雙軌策略。
4. 降級 fallback（最後保險）：cache miss 後 origin 也準備好被打、避免假設「cache hit rate 永遠維持高水位」。對應本章「回源保護策略」段。

判讀重點：四步應同步落地、缺一個就會在 migration 期間踩 stampede。一致性 invalidation 模型回到 2.7。

Rollout / Cutover / Rollback

Rollout 的責任是把快取切換拆成可停損批次，不把風險一次放大。

Rollback 不是只「切回舊 key」。若新格式已經被下游依賴，回退時要同時保留新舊讀寫相容，避免第二次不一致。

Evidence Package

快取 migration evidence 的責任是證明「效能提升」沒有交換成「來源壓力失控」或「交易資料錯誤」。

這份 evidence 要對齊 4.20 Observability Evidence Package。

Release Gate

Release gate 的責任是決定是否放行下一批切換，而不是只報告觀測結果。

這組欄位要對齊 6.8 Release Gate 與 6.20 Experiment Safety Boundary。

Incident Decision Log

切換過程中的停用新 key、延長 TTL、凍結 invalidation、回退讀路徑都屬於事故決策。每筆決策都要留在 8.19 Incident Decision Log。

 1incident_decision:
 2  timestamp: 2026-05-11T11:42:00Z
 3  decision: "rollback to dual-read and freeze v2-only rollout"
 4  context: "origin QPS exceeded ceiling and stale price ratio increased in TW region"
 5  evidence:
 6    - query: cache_v2_origin_qps_region_tw
 7    - query: stale_price_ratio_by_region
 8  owner: cache-incident-commander
 9  expected_effect: "reduce origin pressure and restore price freshness baseline"
10  rollback_condition: "origin qps or stale ratio does not recover within 15 minutes"

Case Write-back 與邊界

這篇回寫重點對齊 2.C3 Shopify：Cache Serialization Migration 與 2.C9 反例：前者看格式演進與相容窗口，後者看回源尖峰與停損節奏。

這篇不處理分散式鎖正確性、queue replay 或資料庫正式狀態切換。若核心風險在互斥語意、事件重播或資料 schema，路由到 2.4 distributed lock、3.4 consumer 設計與去重 或 1.7 Schema Migration Rollout 證據。

at-most-once：訊息只送給此刻在線的訂閱者

訊息投遞語意有三種：at-most-once（最多送一次、可能漏）、at-least-once（至少送一次、可能重複）、exactly-once（剛好一次、最難實作）。Pub/Sub 採 at-most-once，用「可能漏」換取低延遲與無狀態，後兩種語意由 Streams 或 message queue 承擔。具體來說：PUBLISH 把訊息送給發布當下已經 SUBSCRIBE 該 channel 的連線，沒有訂閱者就直接丟棄，訊息不寫入任何持久結構。訂閱者離線、重連、或處理速度跟不上時，那段時間的訊息不會補送。

這個語意決定了 Pub/Sub 適合承擔什麼。可以接受「偶爾漏一則、下一則狀態會蓋過來」的場景，Pub/Sub 的低延遲與簡單模型是優勢；要求「每一則都不能掉」的場景，例如訂單事件、扣款通知、稽核軌跡，這些責任屬於 durable queue，不該放在 Pub/Sub。

判讀的關鍵問題是：漏掉一則訊息的代價是什麼。presence 狀態廣播漏一則，下次 heartbeat 會修正；cache invalidation 廣播漏一則，該節點會保留 stale 副本直到 TTL 到期，代價是短暫不一致；扣款事件漏一則，代價是金額錯誤且無法自動修復。前兩者落在 Pub/Sub 的能力範圍，第三者越界。

適用場景：狀態變更的即時扇出

Pub/Sub 的典型用途是把一個節點上發生的狀態變更，即時扇出給其他節點。這類場景的共同特徵是「最終狀態會自我修正」，所以單則訊息可丟。

fan-out 有兩種語意要先分清，因為它們決定能不能用 Pub/Sub。一種是全量 fan-out：每個訂閱者都收到同一則訊息的完整副本，適合「所有節點都要知道這件事」的廣播（presence、cache invalidation、config reload）。另一種是分攤 fan-out：同一則訊息只交給一個 consumer 處理、多個 consumer 之間分攤負載，適合「這件工作只要有一個人做」的任務分派。Pub/Sub 只提供全量 fan-out——PUBLISH 把訊息送給所有訂閱者，沒有「只給其中一個」的語意。需要分攤 fan-out 時要轉 Redis Streams 的 consumer group（XREADGROUP 讓一則訊息只有一個 consumer 拿到），這條邊界在本章末的升級段展開。

presence 變更廣播是最直接的應用。2.5 presence store 的 cross-node query 回答「現在誰在線」，但當某個使用者上線或離線時，其他節點需要被即時通知才能推播給好友列表。presence key 寫入時同步 PUBLISH 一則 user:online 訊息，訂閱該 channel 的節點立刻更新本地視圖。漏一則的代價是某個好友的線上狀態延遲幾秒，下次狀態同步會補正，落在可接受範圍。

cache invalidation 扇出是第二類應用。當一個節點更新了 source of truth 並失效了自己的本地 cache，其他持有同一份 process-local cache 的節點需要被通知一起失效。PUBLISH cache:invalidate product:123 讓所有節點丟棄該 key 的本地副本。這條路徑要跟 2.2 cache aside 的失效策略對齊：Pub/Sub 負責「通知」，實際失效仍由各節點執行，且因為 at-most-once，必須有 TTL 作為兜底，避免廣播漏送讓某節點永久持有 stale 副本。

即時配置熱刷新是第三類。feature flag、限流閾值、路由表這類低頻變更的配置，更新時 PUBLISH config:reload，各節點收到後重新拉取最新配置。低頻特性讓 at-most-once 風險很低，而即時性比輪詢配置中心更省資源。

SUBSCRIBE 的連線模型

訂閱會把連線切換進專用模式：一旦 SUBSCRIBE，該連線只能再執行 SUBSCRIBE、UNSUBSCRIBE、PING 與訂閱相關命令，不能在同一條連線上跑 GET、SET 等一般命令。原因是訂閱連線進入了等待推送的狀態，伺服器隨時可能把訊息推過來，與請求應答式命令的時序會衝突。

這個模型的工程含義是：訂閱要用獨立的連線，不能跟一般讀寫共用同一個 client。共用連線池的應用要為 Pub/Sub 保留專門的訂閱連線，避免訂閱模式污染了拿來做 cache 讀寫的連線。這條限制跟 2.1 高併發讀寫邊界 的連線管理直接相關：訂閱連線是長連線、數量應該受控，與短命的請求應答連線分開計量。

訂閱連線斷線重連時，要重新 SUBSCRIBE 所有 channel，且要意識到斷線期間的訊息已經永久丟失。可靠性敏感的設計會在重連後主動拉一次全量狀態，用一次 reconciliation 補上廣播漏掉的窗口。

cluster 下的 fan-out 與 sharded Pub/Sub

在單節點與傳統 cluster 中，PUBLISH 的訊息會傳播到 cluster 內所有節點，確保任何節點上的訂閱者都能收到。這個全傳播模型保證了廣播的完整性，但代價是每則訊息都要在節點間擴散，高頻發布時會佔用 cluster 內部頻寬。

sharded Pub/Sub（SPUBLISH / SSUBSCRIBE）把這個成本收斂：sharded channel 的訊息只在負責該 channel slot 的分片內傳播，不擴散到整個 cluster。代價是訂閱者必須連到正確的分片才能收到。判讀條件是發布頻率與 cluster 規模：低頻廣播用一般 Pub/Sub 換取部署簡單；高頻發布且 cluster 節點多時，sharded Pub/Sub 避免內部頻寬被廣播流量吃掉。PUBSUB SHARDNUMSUB 可以查某 shard channel 的訂閱者數，用來判讀扇出是否落在預期分片。

keyspace notifications：把 key 事件變成廣播源

keyspace notifications 讓 Redis 在 key 發生變更（寫入、刪除、過期）時自動 PUBLISH 一則事件，訂閱者不必輪詢就能知道某個 key 變了。開啟後，SET、DEL、TTL 過期都會發出對應 channel 的訊息。

這個能力把 presence cleanup 變得更即時。2.5 presence store 的 cleanup 策略依賴 TTL 過期讓離線狀態消失，但「過期了」這件事本身可以透過 __keyevent@0__:expired 事件廣播出去，讓其他節點即時得知某連線下線，而不必等到下次查詢才發現。

keyspace notifications 同樣採 at-most-once 語意，且過期事件的觸發時機與 Redis 的惰性過期機制有關：key 在被存取或背景掃描到時才真正過期並發出事件。延遲量級取決於 key 下次被存取的時機與背景掃描週期（active expiry 預設每秒約執行 10 輪、每輪抽樣部分過期 key），最差情況下事件可能延遲數秒到數分鐘。需要精確過期時序的設計，仍要保留主動查詢路徑作為依據。

何時從 Pub/Sub 升級

Pub/Sub 的邊界訊號出現時，責任應該往 Redis Streams 或正式 message queue 移動。判準是 durable 與 replayable 這兩個 Pub/Sub 不提供的能力。

Redis Streams 是介於 Pub/Sub 與重量級 broker 之間的選項：它持久化訊息、支援 consumer group 與 ack，又仍在 Redis 內，遷移成本低於引入 Kafka 或 RabbitMQ。Streams 與正式 message queue 的選型、consumer 設計、replay 邊界屬於 模組三 message queue 的責任，本章只負責標出「何時該離開 Pub/Sub」這條邊界。

判讀訊號

訂閱者抱怨漏訊息時，先確認這是不是 at-most-once 的預期行為而非 bug。Pub/Sub 在訂閱者重連窗口丟訊息是設計而非故障，正確的修法是判斷這個場景能不能接受丟；能接受就保留 Pub/Sub 並補 reconciliation，不能接受就轉向 durable 方案。

廣播漏送導致長期 stale 之所以難防，是因為 cache invalidation 廣播在多數時候成功，讓人把失效當成可靠，直到某次漏送讓一個節點持有錯誤價格或權限數小時而沒有任何報錯。TTL 兜底的意義就是把「廣播失敗」的最壞影響限制在一個 TTL 週期內，把 Pub/Sub 定位成「加速失效」而非「保證失效」。

常見誤區

把 Pub/Sub 當成可靠訊息系統，是最常見也代價最大的誤區。Pub/Sub 沒有持久化、沒有 ack、沒有重播，這些是它換取低延遲與簡單模型的設計取捨。需要這些能力時，正確做法是換工具，而不是在 Pub/Sub 外圍補一層補丁去模擬可靠投遞。

把訂閱連線跟一般讀寫連線共用，是第二個誤區。訂閱會讓連線進入專用模式，混用會讓 cache 讀寫命令在該連線上失敗或行為異常。訂閱連線要獨立管理。

只靠 Pub/Sub 廣播做 cache invalidation 而沒有 TTL 兜底，是第三個誤區。廣播的 at-most-once 特性意味著總有漏送的可能，TTL 是讓漏送影響有上界的保險。

情境回寫

Pub/Sub 的即時扇出語意，回寫到真實服務時最常見的形狀是多節點即時狀態同步。一個多區域部署的即時通訊服務，使用者上線狀態由所在區域的節點寫入，其他區域的節點需要即時得知才能更新好友列表的線上指示。這條路徑用 Pub/Sub 廣播狀態變更，回寫時要保留「跨區傳播有延遲窗口、單則訊息可丟、靠後續 heartbeat 收斂」的判讀，而非把它當成可靠投遞。

這個形狀支撐的是「即時廣播 + 最終狀態收斂」的判讀。若根因是訊息不能丟（狀態變更會觸發扣款、稽核或計費），應回到 模組三 message queue 的 durable 方案；模組三的 fan-out 案例（如 Twitch EventSub 用 SNS + SQS 扇出給第三方）記錄了 durable 扇出的設計，可在需要持久化與重播時對照。

跨模組路由

1. 與 2.5 的交接：presence 狀態變更的廣播回到 presence store 與即時狀態。
2. 與 2.2 的交接：cache invalidation 扇出與 TTL 兜底回到 cache aside 與失效策略。
3. 與 2.1 的交接：訂閱連線管理與一般讀寫連線分離回到 高併發下的 Redis 讀寫邊界。
4. 與模組三的交接：需要持久化、ack 與重播時轉向 message queue 與 Redis Streams。

下一步路由

要看即時狀態本身如何建模與清理，回到 2.5 presence store 與即時狀態。要看廣播訊息升級成 durable 投遞後的 consumer 設計與重播邊界，接著讀 模組三 message queue。

與 2.8 的分工

2.8 回答「這份資料是單 key、集合、排序還是計數」這層形狀選型，本章回答「選定形狀後，這個型別的操作語意、原子性與記憶體曲線是什麼」。形狀選型決定方向，型別實作決定它在真實流量下的成本與正確性邊界。兩章分工互補：2.8 判斷形狀，本章確認該型別能不能撐住預期的存取節奏。本章涵蓋 sorted set、bitmap、HyperLogLog、counter 與 hash 這五個快取場景最常用的型別；list 與 stream 的責任偏向佇列與事件流，由 模組三 message queue 涵蓋，geo 這類空間型別不在本章範圍。

sorted set：排行榜與時間線

sorted set 的責任是維護一組帶 score 的成員，並讓「依 score 排序取範圍」成為一次操作。它適合排行榜、時間線、優先佇列這類「要排序、要取 top-N、要查排名」的場景。

排行榜是最直接的應用。ZADD leaderboard 5000 player:42 寫入或更新分數，ZREVRANGE leaderboard 0 9 WITHSCORES 取前十名，ZREVRANK leaderboard player:42 查某玩家的排名。每個操作都是 O(log N)，不需要把整個排行榜拉到應用端排序。分數變動用 ZINCRBY 原子遞增，避免「讀分數、加分、寫回」的競態。

時間線是第二類應用。把訊息或事件的時間戳當 score，ZADD timeline <timestamp> <event-id>，就能用 ZRANGEBYSCORE 取某個時間窗口的事件，或用 ZREVRANGE 取最新 N 則。這個用法要注意容量：時間線會持續增長，需要搭配 ZREMRANGEBYRANK 或 ZREMRANGEBYSCORE 定期裁剪舊資料，否則 key 會無限膨脹。

sorted set 的判讀重點是 score 語意的正確性。score 是排序的唯一依據，score 設計錯誤會造成排序漂移：用浮點數當 score 時要注意精度，相同 score 的成員按字典序排列，需要穩定排序時要把 tie-break 維度編進 score 或成員名。容量上，sorted set 內部同時維護一個支援 O(1) 查找的 hash 與一個支援 O(log N) 排序的跳躍表（skiplist），兩份索引讓查找與排序都快，但每個成員要在兩個結構各存一份，記憶體成本高於單純的 set，成員數很大的排行榜要評估記憶體佔用。

bitmap：布林狀態的省記憶體表示

bitmap 的責任是用單一 bit 表示每個實體的布林狀態，讓「大量實體的是否」用極小記憶體承載。它建構在 string 上、以 bit 操作存取，適合日活躍標記、功能開關位、簽到記錄這類「每個 id 對應一個是否」的場景。

日活躍使用者追蹤是典型應用。用日期當 key、使用者 id 當 offset，SETBIT active:20260616 <user-id> 1 標記某使用者當天活躍，BITCOUNT active:20260616 算當天活躍總數。一千萬個使用者只需要約 1.2 MB（一千萬 bit），相比為每個使用者存一筆記錄，記憶體成本低一到兩個數量級。多天的留存分析用 BITOP AND 把多天的 bitmap 做交集，算出連續活躍的使用者。

bitmap 的判讀重點是 offset 的密度。bitmap 的記憶體取決於最大 offset 而非實際設置的 bit 數：如果 user id 是稀疏的大整數（例如雪花 id），直接當 offset 會撐爆記憶體，需要先把 id 映射成稠密的連續整數。offset 稠密時 bitmap 極省空間，稀疏時反而浪費，這條判讀決定 bitmap 能不能用。

HyperLogLog：基數估計

HyperLogLog 的責任是用固定的小記憶體估算一個集合的不重複元素數量，代價是放棄精確值換取近乎常數的空間。它適合 UV 統計、不重複事件計數這類「只要不重複的數量、不需要知道具體是誰」的場景。

獨立訪客（UV）統計是典型應用。PFADD uv:20260616 <user-id> 把訪客加入估計，PFCOUNT uv:20260616 取得不重複訪客數的估計值。HyperLogLog 每個 key 的記憶體在 dense 表示下固定在約 12 KB，無論加入一千還是一億個元素都不增長，標準誤差約 0.81%；元素數少時 Redis 用 sparse 編碼、記憶體遠低於 12 KB，超過可配置的閾值（hll-sparse-max-bytes，預設 3000 bytes）後才切換成 dense 表示。多天 UV 合併用 PFMERGE 把多個 HLL 合成一個再 count，算出跨天的不重複訪客。

HyperLogLog 的判讀重點是「估計值能不能接受」。它回答的是「大約多少不重複」，不能回答「某個特定元素在不在集合裡」，也不能取出集合成員。需要精確去重、或需要判斷成員存在性時，用 set 或 bitmap；只要量級且能容忍百分之一以內的誤差時，HyperLogLog 用固定小記憶體換取巨大的空間節省。把 HLL 的估計值當精確值報給財務或計費，是越界用法。

原子計數器：counter

counter 的責任是提供一個原子遞增的整數，讓並發場景下的計數不需要鎖。它建構在 string 上，INCR、INCRBY、DECR 都是原子操作，適合限流、配額、瀏覽計數這類高並發累加。

限流計數是典型應用，也跟 rate limit 卡片直接相關。固定窗口限流用 INCR rate:<user>:<minute> 累加當前窗口的請求數，第一次寫入時 EXPIRE 設定窗口長度，超過閾值就拒絕。原子性讓多個並發請求的計數不會互相覆蓋，這是用一般 GET/SET 做計數會踩到的競態。

counter 的判讀重點是原子性與過期窗口的對齊。INCR 本身原子，但「INCR 後再 EXPIRE」是兩個操作，若第一次 INCR 成功、EXPIRE 失敗，這個 key 會永不過期變成髒計數。最穩健的做法是用 Lua script 把 INCR 與 EXPIRE 包成一個原子單元；SET key 1 EX <ttl> NX 配合後續 INCR 能減少 EXPIRE 漏掉的機率（窗口第一次寫入時就帶上過期），但這個組合的兩步之間仍非原子，不視為與 Lua script 等效。這條對齊跟 2.8 counter 形狀 提到的「原子性與過期窗口要對齊」是同一件事，本章補上具體實作。

hash：結構化欄位的局部更新

hash 的責任是把一個實體的多個欄位存在同一個 key 下，並讓單一欄位可以獨立讀寫。它適合使用者摘要、商品局部欄位這類「整體是一個實體、但欄位會分別更新」的場景。

相比把整個實體序列化成一個 JSON blob，hash 的優勢是局部更新：HSET user:42 last_seen <ts> 只改一個欄位，不需要讀出整包、改一個值、再寫回。這在欄位更新頻繁的場景省下大量序列化成本與競態風險。HGET 取單一欄位、HGETALL 取全部、HINCRBY 對數值欄位原子遞增。

hash 的判讀重點是欄位責任要清楚。hash 讓欄位能獨立更新，但這也讓它容易滑向「半正式狀態」：當不同欄位由不同來源在不同時間更新，整個 hash 的一致性就變得模糊，某些欄位新、某些欄位舊。判讀條件是這些欄位是否真的能獨立成立；如果它們必須一起更新才有意義，blob 的整體替換反而比 hash 的局部更新更安全。

容量上 hash 有一個要注意的轉折：欄位數與欄位值在閾值內時（hash-max-listpack-entries 預設 128 個欄位、hash-max-listpack-value 預設 64 bytes）用緊湊的 listpack 編碼、記憶體很省，超過任一閾值就轉成 hashtable 編碼，記憶體成本明顯上升。設計大 hash 時要確認欄位數落在閾值內，否則會在某個規模點遇到非線性的記憶體增長。

型別選型的容量與原子性判讀

選型前要把存取語意、原子性需求與記憶體曲線一起考慮，而不是只看「能不能存」。

sorted set 與 bitmap 都能做「統計」，但語意不同：sorted set 保留每個成員與其分數、可取明細，bitmap 只保留是否、取不出成員但極省空間。需要明細與排名用 sorted set，只需要聚合數量用 bitmap 或 HLL。

HyperLogLog 與 set 的分界是「要不要精確、要不要成員」。set 精確且可列舉，記憶體隨成員數增長；HLL 估計且不可列舉，記憶體固定。同一個 UV 需求，用 set 在大流量下記憶體會失控，用 HLL 換取固定成本但放棄精確值，選擇取決於誤差容忍度。

常見誤區

把 sorted set 當成「能排序的 set」而忽略 score 設計，會造成排序漂移。score 是排序的唯一依據，相同 score 按字典序，需要穩定且可預測的排序時要把 tie-break 維度設計進 score。

把 bitmap 用在稀疏 id 上，會讓記憶體被最大 offset 撐爆。bitmap 省記憶體的前提是 offset 稠密，稀疏 id 要先映射成連續整數，或改用其他結構。

把 HyperLogLog 的估計值當精確計數，會在計費、財務這類要求精確的場景出錯。HLL 是有誤差的估計，它的價值在用固定小記憶體換量級判斷，不是替代精確計數。

把多步操作當成原子，會在並發下產生競態。INCR 加 EXPIRE、ZADD 加裁剪都是多個命令，需要原子保證時用 Lua script 或 MULTI/EXEC 包起來。

判讀訊號

排行榜在應用端拉全量排序是最常見的浪費：明明 sorted set 能 O(log N) 取 top-N，卻把整個集合讀回應用端用程式排序，在成員數大時造成不必要的網路與 CPU 成本。判讀方法是看排序邏輯在哪裡發生，把它推回 Redis 的範圍操作。

limit 計數的髒 key 不產生任何錯誤訊息，因此特別容易被忽略：INCR 成功但 EXPIRE 漏掉，這個 key 不會報錯，只是悄悄永不過期，問題要等到記憶體監控異常或限流誤判時才間接浮現。把 INCR 與 EXPIRE 原子化是最可靠的修法。

下一步路由

要回到資料形狀的選型判斷，回到 2.8 cache data shape 與 access pattern。要看這些型別在高並發下的讀寫邊界與連線管理，接著讀 2.1 高併發下的 Redis 讀寫邊界。要看 stream 型別承擔的事件流責任，接著讀 2.10 Pub/Sub 與即時 fan-out 與 模組三 message queue。