觀察

Meta 指出快取在 promotion、shard move、故障恢復時容易引入不一致，單靠傳統 invalidation 很難在大規模系統維持穩定。

判讀

當快取已是核心路徑，資料新鮮度問題會直接變成服務正確性問題。這時候轉換重點是把一致性追蹤與異常定位制度化，改一個 TTL 解決不了結構問題。

策略

1. 先定義 inconsistency 來源點與觀測點。
2. 將 mutation tracing 納入治理，而不是只看命中率。
3. 把一致性指標接到告警與回退條件。

下一步路由

先回 2.2 cache aside 與 2.3 TTL/eviction，再接 4.17 telemetry data quality。

引用源

• Cache made consistent

對「通用快取、session store、rate limit counter、leaderboard、distributed lock」這條路徑、Redis 是事實標準。本頁先給最短路徑、再展開日常 CLI / API 與 key 設計、最後進階治理（cluster / persistence / modules）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 docker 跑起 Redis、用 redis-cli 驗證
2. 用 SET / GET / EXPIRE / DEL / KEYS 操作、區分 6 大 data types 適用場景
3. 設計 key naming + TTL + eviction policy 對齊 cache miss 行為
4. 看懂 hit rate / memory pressure / eviction / replication lag 訊號
5. 評估 Cluster vs Sentinel、AOF/RDB、modules、授權變動下的選擇

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

1# 1. 啟動 Redis
2# TODO: docker run -d --name redis -p 6379:6379 redis:7
3
4# 2. 連線
5# TODO: docker exec -it redis redis-cli
6
7# 3. 驗證 SET / GET / EXPIRE
8# TODO: SET foo bar / GET foo / EXPIRE foo 60 / TTL foo

最短路徑驗證「Redis 起來、能讀寫 + TTL」。實際應用見日常操作。

日常操作與決策形狀

CLI 與 client API

子議題：

• redis-cli 指令對照表（SET / GET / DEL / EXPIRE / TTL / KEYS / SCAN / MGET / MSET）
• Client library 配置：connection pool / timeout / pipeline / cluster mode
• Pub/Sub vs Streams 的選用判讀
• 對應指令範例：INFO replication、CLIENT LIST、SLOWLOG GET

Key design 與 data types

不同 data type 對應不同資料形狀。子議題：

• String：cache / counter / config flag
• Hash：object cache（避免反覆 serialize）
• List：queue / activity feed（小規模）
• Set：membership / tag
• Sorted set：leaderboard / time-series sliding window
• Stream：log-style queue / event stream
• HyperLogLog / Geo：approximate count / 地理座標

Key naming 規範：<service>:<entity>:<id>:<field>、用 : 分層、避免大 key（單 key > 10KB / list 長度 > 10K）。

TTL 與 eviction 策略

TTL 跟 eviction 是 cache 行為的核心旋鈕。子議題：

• 顯式 EXPIRE vs SET EX 設 TTL
• maxmemory + maxmemory-policy（allkeys-lru / allkeys-lfu / volatile-lru / volatile-ttl / noeviction）
• TTL 設計：固定 TTL vs 動態 TTL vs 不設 TTL
• 對應指令：CONFIG SET maxmemory 2gb、CONFIG SET maxmemory-policy allkeys-lfu

進階主題（按需閱讀）

Cluster vs Sentinel

子議題：

• Sentinel：HA 模式、無 sharding、適合單 master 容量足夠
• Cluster：sharding 模式、16384 hash slot、橫向擴展容量
• Hash tag {...} 強制 multi-key 同 shard
• Cluster failover 對 PEL（Streams）跟 distributed lock 的影響

AOF / RDB 持久化策略

子議題：

• AOF（append-only file）：fsync 策略（always / everysec / no）、rewrite
• RDB（snapshot）：save 策略、backup 還原
• 混合模式：AOF + RDB
• 持久化在 cache 場景的取捨（持久化是回填還是 source-of-truth）

Eviction policy 詳細

子議題：

• LRU vs LFU：access pattern 對選擇的影響
• volatile-* vs allkeys-*：只淘汰有 TTL 的 vs 全 key
• approximate LRU 的 sampling 影響
• 對應 2.3 TTL eviction

Distributed lock

子議題：

• SETNX + EXPIRE 模式
• Redlock 算法（多 master quorum）+ 取捨爭議
• Redlock 何時不夠：fence token / lease renewal
• 對應 2.5 distributed lock

Pub/Sub vs Streams

子議題：

• Pub/Sub：fire-and-forget、訂閱者離線會錯過
• Streams：append-only log、consumer group + PEL
• 何時用 Streams 取代 Pub/Sub
• Redis Streams 細節見 03 messaging 模組 Redis Streams vendor

Redis Modules

子議題：

• RedisJSON / RedisSearch / RedisTimeSeries / RedisBloom / RedisGraph
• Module 隨授權變動受影響、Valkey 部分 fork
• Module 在 ElastiCache 的支援限制

授權變動與選型影響

子議題：

• 2024 RSALv2 / SSPL 變動的影響範圍
• 對 managed service（ElastiCache 改 default 為 Valkey）的衝擊
• 從 Redis 遷 Valkey 的相容性路徑
• 商業 vs OSS 邊界

Hot key 處理

子議題：

• Hot key 偵測（redis-cli –hotkeys、MONITOR 慎用）
• Hot key 解法：local cache + Redis 兩層、key 拆分（讀多寫少場景）
• 對應 2.6 high concurrency

排錯快速判讀

Hit rate 下降

操作原則：先看 cache pattern 是否變（新功能 / TTL 變短）、再看 origin 壓力是否擴大。

1# TODO: INFO stats（看 keyspace_hits / keyspace_misses 比例）

判讀路徑：TTL 太短 → eviction 太積極 → key 命名變動造成 cache miss → origin 失敗 retry storm。

Memory pressure / eviction 異常

操作原則：先看 maxmemory + maxmemory-policy 設定、再看 key size 分布。

1# TODO: INFO memory / MEMORY USAGE <key> / --bigkeys

Hot key

對應案例 2.C5 Shopify Write-Through。判讀路徑：某 key 的 QPS 遠高於其他、單 shard CPU 接近 100%、其他 shard 閒置。

Replication lag

操作原則：replica 跟 master 差距、看 INFO replication 的 master_repl_offset vs slave_repl_offset。對 2.C1 Meta Cache Consistency 的對照。

Cache stampede（雷霆崩潰）

對應反例 2.C9 Cache Stampede Rollout。判讀路徑：TTL 同時過期 → 大量 cache miss → origin 被打爆 → 連鎖失敗。修法：jitter TTL、early refresh、singleflight 模式。

何時改走其他服務

不在本頁內的主題

• 各語言 Redis client 完整 API
• Redis command 百科（詳查 redis.io/commands）
• Redis Stack 商業 modules 細節
• AOF / RDB 內部 binary format

案例回寫

直接相關案例

跨 vendor 對照

下一步路由

• 上游概念：2.2 Cache Aside、2.3 TTL eviction
• 平行 vendor：Valkey、Memcached
• 下游能力：2.5 distributed lock、2.6 high concurrency

本章目標

學完本章後，你將能夠：

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）、判讀順序是先確認瓶頸再選方案。

觀察

mcrouter 被用來統一處理大量 memcached 流量與跨叢集路由，代表快取已從局部優化變成平台層能力。

判讀

當快取服務跨區、跨叢集且請求量極高時，應把路由策略、故障切換與運維一致性視為主議題。

策略

1. 把 client 端散落邏輯收斂到路由層。
2. 把跨區路由與故障策略標準化。
3. 用可觀測訊號監控路由品質與新鮮度。

下一步路由

回 2.1 高併發 Redis 邊界 與 5.4 service discovery。

引用源

• Introducing mcrouter

對「既有 Redis 部署、需要 OSI 認可授權、多雲避免 vendor lock-in、合規敏感」這條路徑、Valkey 是 Redis 的替代首選。AWS / Google / Oracle / Ericsson 等共同支援、AWS ElastiCache 已把 Valkey 設為 default engine。

本章目標

讀完本章後、你應該能：

1. 跑起 Valkey、用 redis-cli 驗證 API 相容性
2. 評估從 Redis 遷移到 Valkey 的相容性風險（module / Stack 功能）
3. 看懂 Valkey vs Redis Inc 的版本對應跟功能差距
4. 評估管雲端 managed Valkey（ElastiCache）的選用判斷
5. 區分 Valkey 跟 Redis 商業版本對你的合規 / 採購 / SLA 影響

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

 1# 1. 啟動 Valkey（Redis API 相容、可直接用 redis-cli）
 2docker run -d --name valkey -p 6379:6379 valkey/valkey:8
 3
 4# 2. 驗證讀寫（valkey-cli 與 redis-cli 命令一致）
 5docker exec valkey valkey-cli SET foo bar   # → OK
 6docker exec valkey valkey-cli GET foo       # → bar
 7
 8# 3. 確認版本：Valkey 同時回報相容的 redis_version 與自身 valkey_version
 9docker exec valkey valkey-cli INFO server | grep -E "redis_version|valkey_version|server_name"
10# redis_version:7.2.4    ← client library 以此判斷相容性（fork 自 Redis 7.2.4）
11# server_name:valkey
12# valkey_version:8.1.8   ← Valkey 自身版本

第三步是相容性的關鍵證據：既有 Redis client library 看到 redis_version:7.2.4 就以 Redis 7.2.4 的行為運作、無需改 code；valkey_version 才是 Valkey 自身的演進線。實機驗證於 valkey/valkey:8 image、最後檢查日 2026-06-16。實際遷移路徑見進階主題：從 Redis 遷移。

日常操作與決策形狀

CLI 與 client API

子議題：

• valkey-cli vs redis-cli：兩個 binary 都可連 Valkey、命令一致
• Client library 配置：所有 Redis client 自動相容（無需 Valkey-specific client）
• 對應指令範例：INFO server 顯示 valkey_version 而非 redis_version

跟 Redis 的相容邊界

子議題：

• Core data types / commands：100% 相容（fork 自 Redis 7.2.4）
• Eviction / persistence / cluster：相容
• Pub/Sub / Streams：相容
• 不相容：Redis 7.4+ 引入的功能、Redis Stack 商業 modules

遷移評估

子議題：

• AOF / RDB 文件格式相容、可直接拷貝資料目錄
• Client library 完全相容、無需改 code
• 監控工具相容（RedisInsight 雖偏 Redis Inc、但基本命令通用）
• 需確認 modules 使用狀況（Stack modules 未必有 Valkey fork）

進階主題（按需閱讀）

從 Redis 遷移

子議題：

• 評估 module 使用：列出當前使用的 Redis modules、確認 Valkey 對應替代
• 評估 Redis 7.4+ 功能使用（Functions、CLIENT NO-TOUCH 等）
• 遷移路徑：rolling restart with replica swap / 雙寫 / 直接 cutover
• 對應雲端 managed：AWS ElastiCache for Valkey 自動遷移工具

授權合規評估

子議題：

• 為何 Redis 改 RSALv2 / SSPL — OSI 認知（不算 OSI 認可開源）
• Valkey BSD 3-clause — 商業使用無限制
• 對 SaaS 供應商：Redis 限制把 Redis 當成 service 對外提供、Valkey 無此限制
• 對企業 / 公部門：開源合規政策可能要求 OSI 認可、Valkey 通過、Redis 不過

Module 生態相容性

子議題：

• Valkey 計畫自有 modules（valkey-search / valkey-bloom 等）
• Redis Stack modules（RedisJSON / RedisSearch）部分有 fork
• 評估你用的 modules 是否有 Valkey 替代、否則考慮遷 module-free 設計

雲端 managed Valkey

子議題：

• AWS ElastiCache for Valkey（成本比 Redis 低 ~20%、AWS 推）
• GCP Memorystore（規劃 Valkey 支援）
• Azure Cache（規劃中）
• managed 邊界跟 ElastiCache for Redis 一致

跟 Redis 8 的功能差距

子議題：

• Redis 8 新功能對 Valkey 的影響（功能落後幾個月）
• Valkey 自有 roadmap（valkey.io/blog 追蹤）
• 何時 Redis 新功能值得遷回（罕見、通常 Valkey 跟上）

排錯快速判讀

Client 連不上（API 相容問題）

操作原則：先確認 Valkey 回報的相容版本、再對照 client library 支援到 Redis 哪個版本。

1valkey-cli INFO server | grep -E "redis_version|valkey_version"
2# redis_version:7.2.4    ← client library 用這個判斷相容性
3# valkey_version:8.1.8

絕大多數情況直接相容、若失敗多是 client library 太舊（不支援 Redis 7.2 對應版本）。

Module 不可用

操作原則：Valkey 對 Redis Stack modules 不一定有 fork、看 Valkey modules 清單。

監控工具相容性

操作原則：RedisInsight 連 Valkey 可能 partial 工作（部分 vendor-specific 命令缺）、用通用工具（valkey-cli、Prometheus + redis_exporter）較穩。

Performance regression（vs Redis）

操作原則：Valkey 跟 Redis 7.2.4 為 baseline、效能應接近、差距 < 5% 屬於正常。明顯回歸要看 Valkey roadmap 是否有 known issue。

何時改走其他服務

不在本頁內的主題

• 完整 Valkey command reference（valkey.io/commands）
• Linux Foundation governance 細節
• 各語言 client compatibility matrix
• Redis Stack module 對應替代清單

案例回寫

直接相關案例（沿用 Redis 同源案例 + 待補 Valkey-specific case）

Valkey 從 Redis 7.2.4 fork、API 與行為 100% 相容、Redis-on-Valkey 同源案例可直接套用。截至本文時 Valkey-specific production case 仍累積中。

待補 Valkey-specific 案例：Linux Foundation Valkey customer adoption stories、AWS ElastiCache for Valkey 客戶遷移個案、re:Invent 2025+ talks、企業 OSI 合規驅動的遷移路徑公開分享。

跨 vendor 對照

下一步路由

• 上游概念：2.2 Cache Aside
• 平行 vendor：Redis（fork 源頭）、ElastiCache
• 下游能力：跟 Redis 完全一致、見 Redis vendor 頁的下游連結

基本流程

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 反例

Vendor / Platform 清單

實作時的常用選擇見 vendors — T1 收錄 Redis / Valkey / Memcached / DragonflyDB / AWS ElastiCache，每個 vendor 有定位、適用場景、取捨與預計實作話題的骨架。

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

暫定分類

快取分層與邊緣層

本模組討論的是「應用層快取」（Redis、in-memory cache），跟 CDN / edge cache 是不同責任：CDN 解決「請求是否需要進到應用程式」（網路入口層），本模組討論的快取解決「應用程式如何降低資料層讀寫成本」（應用層）。完整三層快取分工（邊緣層 → 應用層 → DB buffer pool）跟 origin protection 設計見 5.9 邊緣分發與靜態資源。

兩層快取的失效路徑要協調設計：應用層 purge 在自家 cluster 內可控、CDN purge 要等全球節點同步。寫入路徑變更時，要先 purge 應用層、再 purge 邊緣層，避免短時間內邊緣回填到應用層舊資料。

選型入口

快取選型的核心判斷是資料是否可以重建，以及讀取壓力是否集中。當正式狀態已經存在於資料庫或下游服務，但熱門讀取造成延遲、成本或容量壓力時，快取與 Redis 值得優先評估。

Cache aside 適合商品詳情、權限摘要、feature flag 這類可重建讀取資料；TTL 與 eviction 用來控制資料新鮮度與容量；Redis data types 用來表達 set、sorted set、hash、stream 等不同資料形狀；presence store 適合即時連線狀態；distributed lock 適合需要短時間互斥的協調流程；pub/sub 適合即時 fan-out。

接近真實網路服務的例子包括熱門商品頁、會員 session、WebSocket presence、rate limit counter 與跨節點通知。這些場景的共同問題是讀取節奏、過期策略與資料一致性，因此本模組會先處理資料形狀、hot key、cache stampede、thundering herd 與失效邊界。

與語言教材的分工

語言教材處理 interface / protocol、並發或非同步保護、timeout 與 cache 呼叫邊界。Backend cache 模組處理 Redis command、資料結構、失效策略、跨節點一致性與操作風險。

案例驅動讀法

快取案例的核心讀法是先看「一致性問題長什麼樣」，再決定要調策略還是調架構。

章節列表

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

回退判讀寫法見 0.C4 回退判讀寫法，快取案例要優先保留回源壓力、資料新鮮度與熱門 key 行為。

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

觀念網路補完方向

快取章節下一輪的核心責任是把「暫存副本」和「正式狀態」的界線寫清楚。現有章節已經有 cache aside、TTL、distributed lock、presence store，並補上了 Pub/Sub 即時 fan-out（2.10）與 data types 型別實作（2.11）兩個向度；仍可深化的是資料新鮮度、失效語意、回源保護與快取遷移之間的引用關係，讓讀者知道快取策略何時只是加速，何時已經變成服務正確性風險。

這些方向要用快取自己的服務壓力展開。商品詳情、價格、權限摘要、presence 與 rate limit 的失敗代價不同，寫作時要分別處理它們的新鮮度與回源壓力。

知識卡補強方向

快取模組的 knowledge card 缺口集中在「新鮮度」與「回源保護」。已有 cache hit rate、cache warmup、cache prefetching 與 stale data 可以先引用。

下一批候選卡片包括 freshness window、origin protection、request coalescing（single-flight）、negative cache、cache key versioning 與 cache serialization migration。這些卡片要讓讀者能分辨「可短暫不新鮮」和「錯誤會直接影響交易或權限」的差異。2.4 帶入的 fencing token 是跨模組的分散式術語、且是「鎖不是正確性保證」這個核心論點的依據，值得獨立建卡（候選）。

實作探討入口

快取的第一條實作路徑是 2.9 Cache Migration 與 Stampede Rollback（實作示範）。這篇以商品詳情或價格快取為例，說明 cache evidence package、origin protection gate、warmup plan 與 rollback trigger 如何一起成立。型別實作層面的具體入口是 2.11 Redis data types 實作，聚焦 sorted set、bitmap、HLL、counter、hash 各自的操作語意、原子性與容量行為。

這條路徑的前置引用應該是 2.2 cache aside、2.3 TTL / eviction、2.C9 反例、4.17 Telemetry Data Quality 與 6.20 Experiment Safety Boundary。完成後可依 Backend 學習路線 進入下一條服務路徑。

快取路徑的 artifact 對齊重點是「先證明回源壓力受控，再擴大快取覆蓋率」。對 4.17 / 4.20 要交 Source/Time range/Query link/Owner/Data quality，並覆蓋 hit/miss、origin QPS、stale read 與 hot key 分布；對 6.20 / 6.8 要交 Gate decision/Checks/Stop condition/Rollback window/Owner，呈現 warmup 演練與 stampede 停損門檻；對 8.22 / 8.19 要交 Timestamp/Decision/Context/Evidence/Owner/Expected effect/Rollback condition，記錄 key pattern、影響範圍與修復後追蹤信號。

跨語言適配評估

快取與 Redis 的使用方式會受語言的資料複製模型、client lifecycle、序列化成本與並發模型影響。同步 runtime 要避免每個 request 建立連線；async runtime 要避免 blocking Redis client 卡住 event loop；輕量並發 runtime 要用 timeout、rate limit 與 pipeline 邊界保護 Redis。動態語言要特別留意 cache value schema 演進；強型別語言則要避免把內部型別直接當成跨服務快取 contract。

觀察

Shopify 在快取編碼轉換過程使用雙軌策略，先允許新舊格式共存，再逐步收斂。

判讀

快取格式轉換本質上是相容性遷移。若一次切換，回退與資料可讀性風險會放大。

策略

1. 新格式可編碼就先寫新格式。
2. 編碼失敗回落舊格式，保留服務可用性。
3. 維持一段雙軌期，觀測命中率與錯誤率再收斂。

下一步路由

回 2.2 cache aside 與 6.11 migration safety。

引用源

• Caching Without Marshal Part 2

對「純 cache、避免誤用為 source-of-truth、需要多執行緒高 throughput、極簡運維」這條路徑、Memcached 是首選。從 LiveJournal 2003 年開源至今、是業界最久經考驗的 cache。

本章目標

讀完本章後、你應該能：

1. 跑起 Memcached、用 telnet 或 memcached-tool 驗證
2. 用 SET / GET / DELETE / INCR / DECR 操作、區分 Memcached 跟 Redis 的場景界限
3. 設計 client-side consistent hashing 做 sharding
4. 看懂 hit rate / slab fragmentation / eviction 訊號
5. 評估 Memcached vs Redis 的選用判讀（何時純粹勝過豐富）

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

 1# 1. 啟動 Memcached（-t 4 開 4 條 worker thread、-m 64 給 64MB）
 2docker run -d --name memcached -p 11211:11211 memcached:1.6 memcached -t 4 -m 64
 3
 4# 2. 用 text protocol 驗證讀寫（沒有 redis-cli 這種專屬 CLI、直接走 TCP）
 5#    set <key> <flags> <ttl> <bytes>，下一行是 value
 6printf 'set foo 0 60 3\r\nbar\r\nget foo\r\nquit\r\n' | nc localhost 11211
 7# STORED
 8# VALUE foo 0 3
 9# bar
10# END
11
12# 3. 確認多執行緒與記憶體上限
13printf 'stats settings\r\nquit\r\n' | nc localhost 11211 | grep -E "num_threads|maxbytes"
14# STAT maxbytes 67108864      ← 64MB
15# STAT num_threads 4          ← -t 4 生效

最短路徑驗證「Memcached 起來、能讀寫、多執行緒生效」。Memcached 沒有 redis-cli 這類專屬 CLI、實際 ops 走 client library（python-memcached / pylibmc / go memcache）+ stats 系列命令。實機驗證於 memcached:1.6（VERSION 1.6.42）、最後檢查日 2026-06-16。

日常操作與決策形狀

協議與 client library

子議題：

• ASCII protocol vs binary protocol（兩種都支援、binary 較有效率）
• Client library：python-memcached、pylibmc（libmemcached 綁定）、go memcache、Java spymemcached
• Connection management：connection pool / persistent connection

指令對照

子議題：

• 基本：SET / GET / ADD / REPLACE / DELETE / FLUSH_ALL
• Counter：INCR / DECR（不能 < 0）
• 條件：CAS（compare-and-swap）做 optimistic lock
• 批次：GETS（批次 + CAS token）

Client-side sharding

Memcached server 本身無 cluster mode、靠 client library 做 sharding。子議題：

• Consistent hashing（ketama）— 加減 node 時 minimum key 移動
• Hash 演算法：md5 / SHA1 / ketama
• 對應 2.4 cache data shape

Memory model（slab allocator）

子議題：

• Memcached 用 slab allocator 預分配記憶體 chunk
• 不同 size class（slab class）對應不同 chunk size
• Fragmentation：當 value size 跟 slab 不對齊、memory 浪費
• 對應指令：stats slabs / stats items

進階主題（按需閱讀）

Slab allocator 與 memory fragmentation

子議題：

• Slab class 自動分配機制
• Slab reassignment（Memcached 1.4.25+）— 把記憶體在 slab class 間搬移
• 監控 STAT total_malloced vs STAT bytes_read
• 對應指令：stats slabs、slabs reassign <src> <dst>

Multi-threaded scaling

子議題：

• Memcached 從早期就 multi-threaded（vs Redis 早期 single-thread）
• -t 設 thread 數、預設 4、依 CPU core 調
• Lock contention：高 thread 數可能 hit per-bucket lock
• 對比 Redis：Redis 6+ 加 I/O threads、但 main thread 仍單線

AWS ElastiCache for Memcached

子議題：

• ElastiCache 提供 managed Memcached cluster
• Auto Discovery：客戶端自動發現 cluster node 變化
• ElastiCache config endpoint 取代 client-side sharding 配置
• 跟 Redis ElastiCache 的成本對照

CAS（compare-and-swap）

子議題：

• GETS 拿 value + token、SET 帶 token 做 conditional update
• 適合做 optimistic lock（vs Redis SETNX + lua）
• CAS 失敗時的 retry 策略

Memcached vs Redis 的場景區分

子議題：

• 純 cache 不需 data types → Memcached 更輕量
• Session store / counter / hot key 兩者都行
• Leaderboard / sorted set / Streams / Pub/Sub → 只 Redis
• Distributed lock → Redis（Memcached CAS 不夠強）
• 持久化（cache warmup 後不想全失）→ Redis（RDB / AOF）

排錯快速判讀

Hit rate 下降

操作原則：先看 eviction 是否提高、再看 key naming 是否變動。

1printf 'stats\r\nquit\r\n' | nc localhost 11211 | grep -E "get_hits|get_misses|evictions"
2# get_hits / get_misses 算 hit rate、evictions 持續增加代表 memory 壓力

Eviction 增加（memory pressure）

操作原則：超過 -m 設定的 memory limit、Memcached 用 LRU evict 老 key。看 stats slabs 哪些 slab class 最常 evict、可能要 slab reassign。

Slab fragmentation

操作原則：value size 跟 slab class 不對齊造成 wasted memory。判讀：stats slabs 看每個 slab class 的 used vs total chunks。

Client-side sharding 不平衡

操作原則：node 加減後、ketama 應 minimum 移動、但實際分布可能因 key 集中而偏斜。判讀：每個 node 的 stats 看 key count + memory usage 是否均衡。

Connection 耗盡

操作原則：每個 client 開太多 connection、Memcached 預設 max 1024 connection。看 stats curr_connections。

何時改走其他服務

不在本頁內的主題

• 各語言 Memcached client 完整 API
• Memcached internal data structure 細節
• Custom binary protocol 實作
• ASCII vs binary protocol 完整對照

案例回寫

直接相關案例

跨 vendor 對照

下一步路由

• 上游概念：2.2 Cache Aside、2.3 TTL eviction
• 平行 vendor：Redis、AWS ElastiCache
• 下游能力：2.4 cache data shape

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 反例。

觀察

Meta 透過 CacheLib 與 Kangaroo 把快取結構擴展到記憶體與快閃分層，改善容量與成本平衡。

判讀

當熱門資料集合超過 DRAM 經濟範圍時，單層快取會同時遇到成本與命中率瓶頸。

策略

1. 定義不同資料熱度的落層策略。
2. 把 eviction 與回補延遲納入共同指標。
3. 驗證分層後 tail latency 與成本曲線。

下一步路由

回 2.3 TTL/eviction 與 6.9 capacity/cost。

引用源

• CacheLib and Kangaroo

對「需要極高 single-instance throughput、多核機器希望充分利用 CPU、Redis drop-in 但要 scale up 而非 out」這條路徑、DragonflyDB 是值得評估的替代。

本章目標

讀完本章後、你應該能：

1. 跑起 DragonflyDB、用 redis-cli 驗證 protocol 相容
2. 評估從 Redis 遷移的相容性風險（unsupported commands）
3. 看懂 shared-nothing 多核架構跟 Redis I/O thread 的差異
4. 評估 BSL 授權對你的商業使用影響
5. 區分 DragonflyDB 跟 Redis Cluster / Garnet / KeyDB 的選用判讀

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

 1# 1. 啟動 DragonflyDB（thread 數預設 = CPU 核數、自動多核）
 2docker run -d --name dragonfly -p 6379:6379 \
 3  docker.dragonflydb.io/dragonflydb/dragonfly
 4
 5# 2. 用 redis-cli 驗證（wire-protocol 相容、直接用 redis-cli）
 6redis-cli SET foo bar    # → OK
 7redis-cli GET foo        # → bar
 8
 9# 3. 確認版本與多核：DragonflyDB 回報相容的 redis_version + 自身版本 + thread 數
10redis-cli INFO server | grep -E "redis_version|dragonfly_version|thread_count|multiplexing_api"
11# redis_version:7.4.0          ← client library 以此判斷相容性
12# dragonfly_version:df-v1.39.0 ← DragonflyDB 自身版本
13# thread_count:8               ← 自動對齊 CPU 核數（shared-nothing 多核）
14# multiplexing_api:epoll

第三步是 DragonflyDB 跟 Redis 的核心差異證據：thread_count 自動對齊 CPU 核數、每個 thread 管自己的 partition（shared-nothing），這是它高吞吐的來源；redis_version:7.4.0 讓既有 Redis client 直接相容、無需改 code。實機驗證於 dragonfly df-v1.39.0、最後檢查日 2026-06-16。實際遷移評估見 Redis 相容邊界。

日常操作與決策形狀

CLI 與 client API

子議題：

• 直接用 redis-cli（DragonflyDB 100% wire-protocol 相容）
• 所有 Redis client library 自動相容
• 沒有 dragonfly-cli、用 INFO 命令確認 server type

Redis 相容邊界

DragonflyDB 相容大多數 Redis commands、但部分行為差異。子議題：

• 支援：Core data types / commands / persistence / pub-sub / transactions
• 注意：部分 Module 不支援（RedisJSON 有自家版、RedisSearch 沒有）
• 注意：Lua scripting 支援但效能取捨不同
• 限制：Cluster mode 採 single-instance scale-up、沒有 Redis Cluster mode（單 instance 已能處理 Redis Cluster 規模）

對應指令：INFO server 確認 dragonfly version + 配置。

配置與調優

子議題：

• --threads：thread 數量、預設 CPU core 數
• --maxmemory：memory limit、行為跟 Redis 類似
• --cache_mode：傳統 cache 模式 vs DragonflyDB 預設模式
• --snapshot_cron：snapshot 策略

進階主題（按需閱讀）

Shared-nothing 多核架構

子議題：

• 每個 thread 管自己的 partition、no shared state
• VLL（Very Lightweight Lock）取代 Redis 的 single-thread model
• Hash 分到不同 thread、靠 epoll 跟 io_uring 做 I/O
• 跟 Redis I/O threads 的對比：Redis 仍 single main thread、只 I/O 多線；DragonflyDB 完全多線

Memory efficiency

子議題：

• 用 dashtable（DragonflyDB 自製 hash table）取代 Redis dict
• Snapshot 用 fork-less 機制、避免大記憶體 fork 開銷
• 同樣 dataset 通常比 Redis 省 20-40% memory（依資料形狀）

BSL 授權影響

子議題：

• BSL（Business Source License）：商業使用受限、4 年後轉 Apache 2.0
• 限制：不可作為 managed DragonflyDB service 對外提供
• 內部使用無限制（多數企業場景）
• 對 SaaS 供應商：要審慎評估

跟 KeyDB / Garnet 的對比

子議題：

• KeyDB：Redis fork、multi-threaded、Snap 收購後相對停滯
• Garnet（Microsoft）：研究用、極高 throughput、生態淺
• DragonflyDB：商業化最積極、生態最活躍

Scale-up vs Scale-out

子議題：

• DragonflyDB 哲學：single instance 撐到很大規模（廠商宣稱 1TB+ memory / 6.4M QPS）
• Redis 哲學：single instance 有上限、靠 Cluster sharding
• 何時 scale-up 不夠：跨 region / 跨 AZ HA 需求 → 仍需 replica / sentinel

從 Redis 遷移

子議題：

• 評估 module 使用：列出當前 modules、確認 DragonflyDB 對應
• 評估 Cluster mode 使用：DragonflyDB 不支援 Cluster mode、要評估能否回到 single instance
• 遷移路徑：replica 模式雙寫 / 直接 cutover
• 對應 BSL 授權影響評估

排錯快速判讀

Performance 不如預期

操作原則：先確認 thread 數對齊 CPU core、再看 memory pressure。

1redis-cli INFO server | grep -E "dragonfly_version|thread_count"
2# dragonfly_version:df-v1.39.0
3# thread_count:8                ← 對齊 CPU 核數才能發揮多核
4redis-cli INFO memory | grep -E "used_memory:|maxmemory:"

判讀：thread < core → 沒充分利用 CPU；memory > 50% maxmemory → 影響 throughput。

Command 不支援

操作原則：DragonflyDB 不支援全部 Redis commands、看 dragonflydb.io/docs/api/redis 確認。

判讀路徑：client error「unknown command」→ 確認 DragonflyDB 對應實作狀態。

Cluster mode client 連不上

操作原則：DragonflyDB 不支援 Redis Cluster mode、若 client 配置 cluster mode 會連不上。判讀：改回 standalone client config。

Module 不可用

對應 KeyDB / Garnet 的對照思路：DragonflyDB 自家 modules 偏少、Redis Stack modules 大多沒有 fork。

BSL 授權商業使用問題

操作原則：商業使用前審 license terms、若是 managed service 對外提供、需聯絡 DragonflyDB 取得商業 license。

何時改走其他服務

不在本頁內的主題

• DragonflyDB internal 架構細節（dashtable、VLL 等）
• BSL 授權法律解讀（請諮詢律師）
• 各語言 client 完整對應表
• 詳細 benchmark methodology

案例回寫

直接相關案例（沿用 Redis-compatible 同源案例 + 待補 DragonflyDB-specific case）

DragonflyDB 2022 年開源、wire-protocol 與 Redis 相容、Redis 上的 cache pattern 案例可作為框架參考。Production case 仍累積中。

待補 DragonflyDB-specific 案例：早期採用者 benchmark 報告、從 Redis Cluster 收回 single-instance 的遷移案例、BSL 授權實際商業使用評估、multi-core 加速效果的 production 實測。

跨 vendor 對照

下一步路由

• 上游概念：2.2 Cache Aside、2.3 TTL eviction
• 平行 vendor：Redis、Valkey
• 下游能力：2.6 high concurrency
• 回退路徑：DragonflyDB → Redis/Valkey

鎖與租約

分散式鎖通常採租約語意：持鎖者在租約有效期內擁有操作權，租約到期後鎖自動釋放、需重新競爭。租約的存在是為了處理「持鎖者掛掉但沒釋放鎖」這個分散式系統無法避免的情況——沒有租約，一個 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 反例。

觀察

Shopify 在高讀取路徑以 write-through 策略降低 miss 風險，改善熱門資料讀取穩定性。

判讀

當 cache miss 成本過高且資料更新可控時，write-through 能降低讀路徑抖動。

策略

1. 把寫入流程與快取更新綁定。
2. 對失敗寫入設計補償與重試。
3. 用 hit rate 與 stale rate 檢驗策略收益。

下一步路由

回 2.2 cache aside 與 6.8 release gate。

引用源

• How Shop App uses write-through caching

對「AWS 生態服務需要 cache、不想自管 Redis cluster、跨 AZ 高可用」這條路徑、ElastiCache 是首選。本頁先給最短路徑、再展開日常 cluster 管理跟 engine 選擇、最後進階治理（Serverless、MemoryDB 對照）跟排錯。

本章目標

讀完本章後、你應該能：

1. 用 AWS CLI 建立 ElastiCache cluster、選擇 engine（Redis / Valkey / Memcached）
2. 區分 Cluster mode enabled vs disabled 的選用條件
3. 配置 auto failover、cross-AZ replication、snapshot backup
4. 評估 ElastiCache Serverless vs node-based 的成本取捨
5. 區分 ElastiCache 跟 MemoryDB（durable）跟自管 Redis 的定位

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

 1# 1. 建立 Valkey replication group（cluster mode disabled、單 primary + 1 replica、Multi-AZ）
 2aws elasticache create-replication-group \
 3  --replication-group-id demo \
 4  --replication-group-description "demo cache" \
 5  --engine valkey \
 6  --cache-node-type cache.t4g.micro \
 7  --num-cache-clusters 2 \
 8  --automatic-failover-enabled \
 9  --multi-az-enabled
10
11# 2. 取得 primary endpoint（建立需數分鐘、status 變 available 才有 endpoint）
12aws elasticache describe-replication-groups \
13  --replication-group-id demo \
14  --query "ReplicationGroups[0].NodeGroups[0].PrimaryEndpoint.Address" --output text
15
16# 3. 從 VPC 內（EC2 / Lambda）用 redis-cli 連線（ElastiCache 只在 VPC 內可達）
17redis-cli -h <primary-endpoint> -p 6379 PING   # → PONG

指令依 AWS ElastiCache CLI 官方文件、最後檢查日 2026-06-16（managed 服務需 AWS 帳號與 VPC、本機無法 docker 驗證、引數以官方為準）。ElastiCache 端點只在 VPC 內可達、不對公網開放。實際 production 需要評估 cluster mode、節點大小、replica 數、AZ 分布。

日常操作與決策形狀

AWS CLI 與 console

子議題：

• CLI 指令對照表（create-cache-cluster / create-replication-group / describe-* / modify-* / delete-*）
• Console 操作流程（VPC subnet group / security group / parameter group）
• Terraform / CloudFormation 範例
• 對應指令範例：aws elasticache describe-replication-groups --replication-group-id <id>

Engine 選擇

子議題：

• Valkey（2024+ default）：成本低 20%、OSI 開源、Redis 7.2.4 fork
• Redis OSS（legacy support）：仍可選、但 AWS 不推
• Memcached：純 cache 場景、無 cluster mode 概念（client-side sharding）
• 選擇判讀：新部署 → Valkey；既有 Redis 遷移 → Valkey（API 相容）；純 cache → Memcached

Cluster mode enabled vs disabled

子議題：

• Disabled：1 primary + N replica（最多 5）、單 shard、上限 ~340GB
• Enabled：多 shard（最多 500）、自動 sharding、橫向擴展
• 客戶端要求：Cluster mode enabled 需要 cluster-aware client
• 選擇判讀：< 300GB + 簡單 → disabled；> 300GB 或要 sharding → enabled

Snapshot 與 backup

子議題：

• Automatic snapshot（保留 1-35 天）
• Manual snapshot（保留永久、可跨 region 複製）
• Restore：從 snapshot 建新 cluster
• 對應指令：aws elasticache create-snapshot

進階主題（按需閱讀）

Auto failover 機制

子議題：

• Multi-AZ 部署：primary 失敗、replica 自動晉升
• Failover 時間：~30 秒到幾分鐘（依 client 重連)
• Client 影響：DNS 切到新 primary、client 要 reconnect
• 對應 2.C6 Netflix EVCache 跨 AZ 對照

ElastiCache Serverless

子議題：

• On-demand 模式：不選 node type、按 ECPU + storage 計費
• 自動 scale：流量增加自動擴
• 適合：流量不可預測、不想規劃容量
• 不適合：成本敏感（serverless premium）、極大 dataset

跨 region replication（Global Datastore）

子議題：

• Global Datastore：1 primary region + 多個 secondary region read replica
• 跨 region replication lag < 1 second（業界宣稱）
• 適合 active-passive DR
• 不支援 active-active multi-master

MemoryDB 對照

子議題：

• ElastiCache：cache、Multi-AZ replica 但仍是 cache 語意（資料可重建）
• MemoryDB：Redis-compatible durable database、multi-AZ transaction log
• MemoryDB cost 2-3x ElastiCache、但提供 source-of-truth 語意
• 選擇判讀：要 source-of-truth Redis API → MemoryDB；cache 用途 → ElastiCache

Parameter group 與配置

子議題：

• Parameter group：custom maxmemory-policy、timeout、client-output-buffer-limit
• Cluster vs parameter group 的應用範圍
• 對應指令：aws elasticache modify-cache-parameter-group

IAM authentication（Redis 7+）

子議題：

• 從 Redis AUTH password 升級到 IAM-based authentication
• IAM role / user 連 ElastiCache、無需傳 password
• 對應 security 模組

Cost 模型

子議題：

• Node type 成本（t4g.micro 到 r7g.16xlarge）
• Reserved Instance（1/3 年承諾、折扣 30-60%）
• Data transfer cost（同 AZ 免費、跨 AZ 收費）
• Snapshot storage cost

排錯快速判讀

Endpoint 連不上

操作原則：先確認 VPC + security group + subnet group 配置正確。

1aws elasticache describe-replication-groups --replication-group-id <id> \
2  --query "ReplicationGroups[0].Status"
3# 從 VPC 內 EC2 測試連通性
4redis-cli -h <primary-endpoint> -p 6379 PING

判讀路徑：security group 沒開 6379 → VPC peering 不通 → DNS 解析失敗。

Failover 過程中 client 持續 error

操作原則：failover 期間 client 重連需要時間、確認 client 有 reconnect 邏輯。

1aws elasticache describe-events --source-identifier <id> --source-type replication-group
2# 看 failover 開始 / 完成事件、對照 client 重連時間軸

Replication lag 高

操作原則：cross-AZ replication 通常 ms 級、若 > 1 sec 看 CloudWatch ReplicationLag metric。原因可能是 write throughput 過高、replica node 規格不足。

Memory pressure / eviction

操作原則：看 CloudWatch DatabaseMemoryUsagePercentage、超 80% 考慮 scale up node type 或調 maxmemory-policy。

Snapshot 失敗

操作原則：snapshot 過程暫時 fork（Redis）會佔用記憶體、若 memory 已緊張可能失敗。看 CloudWatch BytesUsedForCache。

何時改走其他服務

不在本頁內的主題

• AWS IAM / VPC / Security Group 完整配置（見 security 模組）
• CloudFormation / Terraform 完整模板
• AWS pricing 詳細計算
• ElastiCache vs Memorystore vs Azure Cache 完整對照

案例回寫

直接相關案例

待補 ElastiCache-specific 案例：Airbnb / Lyft / Pinterest 等公開的 ElastiCache 規模化案例、re:Invent talks（如 ElastiCache for Valkey 遷移、Serverless 採用、Global Datastore active-passive DR 實作）。

跨 vendor 對照

下一步路由

• 上游概念：2.2 Cache Aside、0.6 成本取捨
• 平行 vendor：Redis、Valkey
• 下游能力：2.7 cache copy boundary

狀態模型

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 極熱、Redis Cluster 切不開、需要單實例多執行緒撐單 partition」這條路徑、KeyDB 是值得評估的 fork。Snap 在 GCP 上用 KeyDB 是這條路線最大的公開採用者——但要注意該案例的主因是 multi-cloud 架構下的 cross-cloud latency 治理（把 cache 跟 application 放同一個 cloud），KeyDB 的 multi-threaded 單實例吞吐是附帶優勢、不是 Snap 採用的主要驅動。

本章目標

讀完本章後、你應該能：

1. 跑起 KeyDB、用 redis-cli 驗證 protocol 相容
2. 評估 multi-threaded 命令執行跟 Redis I/O threads 的差異
3. 判斷 active-active 多主複製適用與衝突風險
4. 評估 KeyDB on FLASH 對大 dataset 的成本意義
5. 區分 KeyDB 跟 DragonflyDB / Redis Cluster 的選用判讀，並評估 Snap 收購後的治理風險

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

 1# 1. 啟動 KeyDB（--server-threads 開多執行緒、命令執行也多核）
 2docker run -d --name keydb -p 6379:6379 \
 3  eqalpha/keydb keydb-server --server-threads 4
 4
 5# 2. 用 redis-cli 驗證（KeyDB 100% Redis protocol 相容）
 6redis-cli SET foo bar    # → OK
 7redis-cli GET foo        # → bar
 8
 9# 3. 確認版本（KeyDB 回報 redis_version、client 以此判斷相容性）
10redis-cli INFO server | grep -E "redis_version|redis_mode"
11# redis_version:6.3.4    ← KeyDB 的版本方案、client library 以此協商相容
12# redis_mode:standalone

實機驗證於 eqalpha/keydb image、最後檢查日 2026-06-16；--server-threads 是啟動參數（不在 CONFIG GET 內、改值要重啟）。多主複製見進階主題。

日常操作與決策形狀

CLI 與 client API

子議題：

• 直接用 redis-cli / 所有 Redis client library（KeyDB 維持 Redis protocol）
• --server-threads N 設命令執行的執行緒數、對齊 CPU 核數
• INFO server 確認 redis_version（KeyDB 的版本對應 Redis 哪個 base）

Multi-threaded 命令執行

KeyDB 跟 Redis I/O threads 的差異是核心賣點。子議題：

• Redis 6+ 的 I/O threads 只分擔 socket 讀寫、命令仍在 main thread；KeyDB 連命令執行都多執行緒
• --server-threads 對齊核數、單實例吞吐隨核數擴展
• 多執行緒下單 key 的並發保護由 KeyDB 內部處理、application 端語意不變

Active-active 多主複製

子議題：

• 兩個（含以上）KeyDB master 互相複製、都可接受寫入
• 衝突解決用 last-write-wins（依時間戳）、不是強一致
• 適合跨 AZ / 跨 region 的讀寫就近、但要接受最終一致與衝突覆蓋風險

進階主題（按需閱讀）

Active-active 多主複製

子議題：

• replicaof + active-replica yes 開雙向複製
• 衝突語意：同 key 並發寫入、last-write-wins、可能丟其中一側的寫入
• 適用：跨區讀寫就近、可容忍最終一致的 cache；不適用：需要強一致的 counter / lock

KeyDB on FLASH

子議題：

• 把冷資料放 SSD、熱資料留記憶體、降低大 dataset 的記憶體成本
• 對應 Meta CacheLib + Kangaroo 的 DRAM + flash 分層思路
• 代價：FLASH 路徑延遲高於純記憶體、適合冷熱分明的 workload

跟 DragonflyDB / Garnet 的對比

子議題：

• KeyDB：Redis fork（沿用 Redis code base、相容度高、base 版本較舊）
• DragonflyDB：C++ 從零重寫（架構更激進、shared-nothing、相容核心但非 fork）
• Garnet（Microsoft）：研究型高吞吐 store、生態淺
• 對應 DragonflyDB 多核架構 deep article 的 fork vs 重寫光譜

治理風險（Snap 收購後）

子議題：

• KeyDB 公司 2022 年被 Snap 收購、開源版本的後續投入與 roadmap 不確定
• 評估採用前確認專案活躍度（commit 頻率、release cadence）
• 對長期依賴敏感的場景、Redis fork 光譜上的 Valkey（Linux Foundation 治理）治理更穩

排錯快速判讀

多執行緒下吞吐沒提升

操作原則：先確認 --server-threads 對齊 CPU 核數、再看是否 CPU 密集 workload。判讀：thread < core → 沒用滿多核；單 key 極熱 → 仍受單 partition 限制。

Active-active 衝突丟資料

操作原則：last-write-wins 下並發寫同 key 會覆蓋。判讀：跨區同 key 高頻寫入要改設計（key 分區到不同 master）、或改用強一致儲存。

Protocol 相容問題

操作原則：KeyDB base 版本較舊（redis_version 6.x），用到 Redis 7+ 新命令會不支援。判讀：INFO server 確認 base 版本、對照 application 用到的命令。

何時改走其他服務

不在本頁內的主題

• KeyDB 完整 command reference（沿用 Redis、查 redis.io/commands）
• 各語言 client API（用 Redis client 即可）
• KeyDB on FLASH 詳細調參
• Active-replication 內部複製協定細節

案例回寫

直接相關案例

待補 KeyDB-specific 案例：Snap 收購後的公開技術分享、KeyDB on FLASH 的 production 成本案例、active-active 多主複製的跨區衝突治理實例。

跨 vendor 對照

下一步路由

• deep article：KeyDB active-active 多主複製（last-write-wins 衝突與跨區寫入）
• 上游概念：2.6 high concurrency（單執行緒邊界的四個選項）
• 平行 vendor：DragonflyDB、Valkey、Redis
• 下游能力：2.7 cache copy boundary（跨區資料引力）
• 回退路徑：KeyDB → Redis/Valkey

觀察

Tinder 在 ElastiCache for Valkey 的關鍵數字（引自 ElastiCache customers）：

ElastiCache for Redis 7.1 在 r7g.4xlarge 上可達單節點 100 萬 RPS、單 cluster 5 億 RPS（引自 AWS Database Blog）。

判讀

Tinder 案例值得讀的是「快取在 long-running 服務的角色變化」。

1. 快取不是 DB 的補救、是主要服務面：配對引擎每次互動讀 cache 不讀 DB、cache miss 是 邊緣案例。對應 02 快取模組 的 cache-as-source-of-truth 與 02.4 cache copy freshness boundary 設計。
2. 次毫秒延遲是業務 KPI、不只是技術指標：手指滑動之後 250ms 內必須給結果、否則「卡頓」。中間整個 chain（網路、cache、序列化）的 latency budget 必須緊。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。
3. 長期 sustained growth 的容量曲線是成本曲線：47M MAU 沒有明顯峰谷、容量規劃變成「每月線性擴容 X%」的長期決策、不是峰值規劃。對應 9.7 成本邊界與 efficiency 的長期成本工程。

需要警惕：Tinder 的「configurable matching」業務邏輯複雜、快取資料的 schema 變化頻繁。一個 schema 變更可能讓既有 cache 全部 invalid、引發 cache stampede。對應 02.6 cache migration stampede rollback。

策略

可重用的工程做法：

1. cache layer 容量規劃跟 DB 容量規劃要分開：cache 容量受 working set size 影響、DB 容量受 total dataset 影響、兩者擴容邏輯不一樣。對應 02 快取模組 的 cache sizing。
2. cache 命中率變化是業務變化的訊號：突然命中率掉、可能是新功能影響 access pattern、不一定是 cache 容量問題。對應 9.8 效能可觀測性 的訊號治理。
3. Valkey vs Redis OSS vs MemoryDB 是不同 trade-off：Valkey（社群分支、AWS 主推）、Redis OSS（受授權變化影響）、MemoryDB（持久化）三者選擇影響長期 vendor lock-in。

跨平台等效：GCP Memorystore for Redis / Valkey、Azure Cache for Redis、自建 Redis Cluster + Sentinel 都可以實作對等架構。差異是 vendor 的 patch cadence 與容量擴張流程。

下一步路由

• 想設計 cache layer 容量 → 02 快取模組 + 9.5 瓶頸定位流程
• 想做 latency budget 反推 → 9.12 SLO 與 Performance Budget + 9.1 壓測理論與系統行為
• 想理解 cache stampede 風險 → 02.6 cache migration stampede rollback
• 對照其他 cache 案例 → 9.C5 Amazon Ads DynamoDB（KV 高吞吐）

引用源

• Amazon ElastiCache Customers
• Achieve over 500 million requests per second per cluster with ElastiCache for Redis 7.1
• Optimize Redis Client Performance for ElastiCache and MemoryDB

觀察

Netflix 用 EVCache 支撐大規模低延遲讀取，把快取從單服務實作提升為共用基礎設施。

判讀

當讀取延遲目標很嚴格且區域分布廣，快取需要跨區一致性與故障容忍設計。

策略

1. 平台化快取客戶端與治理規則。
2. 把失效策略與區域容錯納入同一模型。
3. 以可觀測指標評估命中率與恢復能力。

下一步路由

回 2.1 與 0.7。

引用源

• EVCache

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

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

熱門資料高度集中是第一個訊號。當少數 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 實作示範。

對「流量不可預測、不想規劃容量與 sizing、團隊沒有 cache 運維資源」這條路徑、Momento 是 serverless 方向的代表。它跟自管 Redis、managed cache 的上層取捨（自管 vs managed vs serverless vs BaaS bundle）見 0.22 能力級買 vs 建。

本頁的計費、limit 與功能宣稱以 Momento 官方文件 與 Momento 定價 為準、最後檢查日 2026-06-16。Momento 是 SaaS、需帳號與 API key、無法本機 docker 驗證、指令為依官方文件的範例。

本章目標

讀完本章後、你應該能：

1. 理解 serverless cache 跟 node-based / managed cache 的計費與維運差異
2. 評估按用量計費（per request + data transfer）對你的流量形狀划不划算
3. 判斷 Momento 原生 SDK vs Redis 相容介面的遷移路徑
4. 區分 Momento 跟 ElastiCache Serverless 的定位差異
5. 判斷哪些 cache 場景適合 serverless、哪些該回 node-based

最短路徑：用 SDK 連 Momento

1# 1. 在 Momento Console 建 cache + 取得 API key（無 node / cluster 配置）
2# 2. 用語言 SDK（以 pseudo-code 示意、實際 API 以官方 SDK 文件為準）
3
4client = CacheClient(api_key, default_ttl=60s)
5client.set("my-cache", "foo", "bar")     # 寫入、TTL 內有效
6client.get("my-cache", "foo")            # → "bar"

最短路徑的重點是「沒有 endpoint / node / sizing 要配」——建 cache 是一個 API 動作、不是 provision 一台機器。實際 SDK 介面以 Momento SDK 文件 為準。

日常操作與決策形狀

SDK 與相容介面

子議題：

• 原生 SDK（多語言）：gRPC-based、Momento 自有 API
• Redis / Memcached 相容介面：既有 Redis / Memcached client 可遷（相容範圍以官方為準、要驗證）
• 沒有 redis-cli 等價的 server 操作（serverless 無 server 可登入）

計費模型（核心決策）

子議題：

• 按用量計費：data transfer（傳輸量）+ 可能的 request / storage 維度（以官方定價為準）
• 無固定 node 費用：閒置時段不付 idle node 的錢
• 流量尖峰自動 scale：不需預留容量、但尖峰量直接反映在帳單

沒有容量規劃

子議題：

• 不選 node type、不設 maxmemory、不規劃 shard
• scaling 由 Momento 處理、application 端不感知
• 代價：失去對底層的控制（無法調 eviction policy 等 server 參數）

進階主題（按需閱讀）

Serverless 計費的甜蜜點與陷阱

子議題：

• 甜蜜點：流量不可預測、有大量閒置時段、不想為峰值預留容量
• 陷阱：穩態高流量下、按用量可能比 node-based + Reserved Instance 貴
• 跟 ElastiCache Serverless 的計費踩坑 同類議題、access pattern 低效會推高帳單

Momento vs ElastiCache Serverless

子議題：

• Momento：cache-as-API、完全 serverless、跨雲（不綁單一 cloud）
• ElastiCache Serverless：AWS 生態內的 node 抽象、仍是 ElastiCache engine、綁 AWS
• 選擇：要完全擺脫容量規劃 + 跨雲 → Momento；已在 AWS 生態 + 要 engine 控制 → ElastiCache

遷移與相容性驗證

子議題：

• 從 Redis / Memcached 遷 Momento：用相容介面或改用原生 SDK
• 相容範圍要逐項驗證（serverless 不支援 server-side 操作如 SCAN 全庫、Lua 等、以官方為準）
• 失去的能力：server 參數調校、自管 persistence、module

排錯快速判讀

帳單超出預期

操作原則：serverless 帳單反映實際用量、先看 data transfer 與 request 量。判讀：access pattern 低效（大量小請求、大 value）會推高、用批次 / 合併降量；穩態高流量重新評估 node-based。

延遲比自管高

操作原則：serverless cache 多一層 API gateway / 跨網路、延遲可能高於同 VPC 的自管 Redis。判讀：latency-sensitive 且穩態高流量的場景、評估自管或 managed node-based。

相容介面行為差異

操作原則：Redis 相容介面不等於 100% Redis、server-side 操作可能不支援。判讀：對照官方相容清單、用到的命令逐一驗證。

何時改走其他服務

不在本頁內的主題

• Momento 完整 SDK API（各語言、以官方文件為準）
• 詳細計費計算（以官方定價為準）
• Redis / Memcached 相容介面的完整相容矩陣
• Momento Topics（pub/sub）等 cache 以外的產品線

案例回寫

跨 vendor 對照（本模組 case 庫暫無 Momento-specific case）

Momento 是較新的 serverless cache、本 blog 的 cache case 庫（Meta / Shopify / Netflix / Cloudflare / Tinder / Tubi / Snap）暫無 Momento production case。以下用 serverless 的角度對照既有 case 提供判讀。

待補 Momento-specific 案例：serverless cache 的成本與彈性 production 個案、從 ElastiCache 遷 Momento 的成本對照、不可預測流量場景的採用分享。

下一步路由

• 上游能力：0.22 能力級買 vs 建（自管 vs managed vs serverless）、0.6 成本取捨
• 平行 vendor：AWS ElastiCache（Serverless 選項）、Caffeine（另一端：process-local）
• 上游概念：2.2 Cache Aside

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。

觀察

Cloudflare Cache Reserve 透過分層儲存延長快取可用性，降低 origin 回源成本。

判讀

當熱門資料長尾明顯，僅靠 edge cache 會有命中率上限，需引入分層儲存。

策略

1. 定義 edge 與 reserve 的資料分層規則。
2. 把回源成本納入快取策略評估。
3. 監控命中率、延遲與儲存成本三者平衡。

下一步路由

回 2.3 與 6.9。

引用源

• Cloudflare Cache Reserve

對「每個請求重複讀同一份小資料、Redis 的網路往返都嫌慢、資料可在每個實例各存一份」這條路徑、Caffeine 是 process-local 層的標準選擇。它常跟 Redis 組成兩層 cache（Caffeine L1 + Redis L2）、不是二選一。Caffeine 是 Guava Cache 的後繼、由同作者重寫、Spring Boot 等框架的預設 local cache。

本章目標

讀完本章後、你應該能：

1. 用 Maven / Gradle 引入 Caffeine、寫出基本 cache
2. 理解 Window TinyLFU 為何命中率優於 LRU
3. 設計 expire-after-write / refresh-after-write / 容量上限
4. 判斷 process-local cache 跟 Redis 的兩層 cache 分工
5. 評估跨實例 invalidation 的限制與 GC 壓力

最短路徑：引入 Caffeine 寫一個 cache

1<!-- Maven 依賴（version 為範例、實際以 Maven Central 最新為準、最後檢查日 2026-06-16）-->
2<dependency>
3  <groupId>com.github.ben-manes.caffeine</groupId>
4  <artifactId>caffeine</artifactId>
5  <version>3.2.4</version>
6</dependency>

 1// 基本 cache：容量上限 10000、寫入後 5 分鐘過期
 2Cache<String, User> cache = Caffeine.newBuilder()
 3    .maximumSize(10_000)
 4    .expireAfterWrite(Duration.ofMinutes(5))
 5    .build();
 6
 7cache.put("user:123", user);
 8User u = cache.getIfPresent("user:123");
 9
10// loading cache：miss 時自動回源（取代手寫 cache-aside）
11LoadingCache<String, User> loading = Caffeine.newBuilder()
12    .maximumSize(10_000)
13    .refreshAfterWrite(Duration.ofMinutes(1))   // 背景非同步 refresh、不阻塞讀
14    .build(key -> userRepository.findById(key)); // miss / refresh 時呼叫
15User u2 = loading.get("user:123");

Caffeine 是 library 不是 server、跑在 application JVM 內、無法 docker 獨立驗證；上面是依官方 API 的範例（API 以 Caffeine wiki 為準）。

日常操作與決策形狀

淘汰與過期策略

Caffeine 把 cache 行為拆成幾個正交的旋鈕。子議題：

• maximumSize / maximumWeight：容量上限（筆數或加權大小）、超過用 W-TinyLFU 淘汰
• expireAfterWrite：寫入後固定時間過期（資料新鮮度上限）
• expireAfterAccess：最後存取後過期（淘汰冷資料）
• refreshAfterWrite：到期後背景 refresh、舊值先服務、不阻塞（跟 expire 不同）

Window TinyLFU 淘汰

子議題：

• W-TinyLFU 結合 recency（window）+ frequency（TinyLFU sketch）、命中率逼近最佳
• 比 LRU 更抗一次性掃描污染（scan resistance）、跟 Redis LFU 的動機類似但演算法更先進
• frequency 用 count-min sketch 近似、記憶體開銷小

兩層 cache（L1 Caffeine + L2 Redis）

子議題：

• L1 Caffeine（process-local、奈秒級、每實例一份）擋掉大部分讀
• L2 Redis（共享、毫秒級、跨實例一致）擋掉 L1 miss
• 對應 2.6 high concurrency 的 hot key 兩層解法

進階主題（按需閱讀）

跨實例 invalidation 的根本限制

子議題：

• 每個 JVM 實例有自己的 Caffeine 副本、一個實例更新不會通知其他實例
• 解法：短 TTL 容忍 stale、或用 Redis pub/sub 廣播 invalidation 訊息給各實例
• 這是 process-local cache 的固有取捨：最低延遲換來最弱的跨實例一致性

GC 壓力與 on-heap vs off-heap

子議題：

• Caffeine 預設 on-heap、大 cache 會增加 JVM heap 與 GC 壓力
• 容量上限要對齊 heap 預算、避免 cache 把 heap 撐爆觸發 full GC
• 極大 local cache 考慮 off-heap 方案（如 Ehcache 的 off-heap tier），但 Caffeine 本身專注 on-heap

async 與 refresh 語意

子議題：

• AsyncCache / AsyncLoadingCache：回傳 CompletableFuture、不阻塞 caller
• refreshAfterWrite：到期後第一個讀觸發背景 refresh、舊值立即回、避免 stampede
• refresh vs expire 的差異是「舊值能不能先服務」

排錯快速判讀

跨實例讀到舊值

操作原則：process-local cache 各實例獨立、更新不傳播。判讀：縮短 TTL 容忍 stale、或加 Redis pub/sub 廣播 invalidation；強一致需求不該用 process-local cache。

命中率低 / cache 沒效果

操作原則：先看 maximumSize 是否太小（working set 放不下）、再看 TTL 是否太短。判讀：用 recordStats() 看 hit rate / eviction count、對齊 working set。

Full GC 頻繁

操作原則：on-heap cache 太大撐爆 heap。判讀：降 maximumSize 或用 maximumWeight 控制實際記憶體、對齊 JVM heap 預算。

何時改走其他服務

不在本頁內的主題

• Caffeine 完整 API（以官方 wiki 為準）
• 各 JVM 框架（Spring Cache abstraction）的整合細節
• Guava Cache 到 Caffeine 的完整 API 對照
• off-heap cache 方案比較

案例回寫

跨 vendor 對照（本模組 case 庫暫無 Caffeine-specific case）

Caffeine 是 library 層元件、本 blog cache case 庫（Meta / Shopify / Netflix / Cloudflare / Tinder / Tubi / Snap）暫無 Caffeine-specific case。以下用 process-local 的角度對照。

待補 Caffeine-specific 案例：L1 Caffeine + L2 Redis 兩層 cache 的 production 命中率分層數據、跨實例 invalidation 的 Redis pub/sub 廣播實作、W-TinyLFU vs LRU 的實測命中率對照。

下一步路由

• deep article：Caffeine + Redis 兩層 cache 與跨實例失效（L1+L2 + pub/sub 廣播失效）
• 上游概念：2.6 high concurrency（hot key 兩層解法）、2.3 TTL eviction
• 平行 vendor：Redis（兩層 cache 的 L2）、Momento（另一端：serverless）
• 下游能力：2.7 cache copy boundary（跨實例一致性窗口）

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 與即時狀態。

觀察

Meta TAO 用於社交圖讀取，演進重點在一致性、可擴展性與資料關聯查詢效率。

判讀

當查詢負載是高度關聯圖資料，快取策略需從 key-value 轉向資料模型治理。

策略

1. 把資料關聯模型納入快取鍵設計。
2. 以一致性窗口設計更新策略。
3. 定期驗證讀取正確性與延遲目標。

下一步路由

回 2.2 與 1.2。

引用源

• TAO: Facebook’s Distributed Data 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 證據。

事故長相

一次看似低風險的 cache key 或 TTL 切換，會讓熱門資料同時 miss。使用者看到的是 API 變慢與錯誤率上升，資料庫看到的是原本被快取吸收的流量突然全部回源。

為什麼會擴大

快取切換如果沒有 warmup、singleflight、節流與降級保護，miss 會引發重試，重試又會增加 origin 壓力。影響面是讀取路徑同時失去緩衝，單一 key 層級的思考抓不到全貌。

回退判讀

回退不應只把程式版本切回去。若新舊快取 key、TTL 或序列化格式已經混在一起，回退還要處理資料可讀性與回源壓力。實務上要先降載或恢復舊 key 讀取，再逐步清理新策略留下的快取狀態。

快取專屬告警條件

• 熱門 key miss 同步上升，且 origin QPS 快速超過平日基線
• response time 拉長並伴隨重試流量增加
• stale read 與 cache miss 同時惡化

下一步路由

回 2.2 與 6.24。

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。

小型服務常見判讀

小型服務最常遇到的問題是切換時沒有先保護回源，快取架構本身夠用。用 cache-aside + TTL 完全可行，但如果沒有 warmup 與簡單限流，某次部署就可能讓熱門 key 全部 miss，直接打爆資料庫。

中型服務常見判讀

中型服務開始同時承受活動流量與版本切換壓力。這時失敗通常出在「切換順序」而不是策略名稱。先改 key 結構還是先改 TTL，會決定是否出現 stampede 連鎖反應。

大型服務常見判讀

大型服務下，快取已經是資料平面的一部分。跨區路由、分層儲存與一致性窗口會直接影響業務正確性。這個階段若只盯 hit rate，會漏掉最關鍵的資料一致性風險。

這個情境的專屬告警條件

• origin QPS 在 5 分鐘內超過基線 2 倍且持續上升
• 熱門 key miss 同步上升，並伴隨重試流量增加
• stale read 比例連續惡化

任何一條成立就先暫停切換，回退上一個策略狀態，優先保護回源與資料一致性。

本文是跨 vendor migration playbook、cross-link 到 DragonflyDB（source）跟 Redis / Valkey（target）。反向路徑見 Redis → DragonflyDB。跑 6 維 diff dimension audit 後判定為 Type B drop-in（RESP 協定相容），但 HA 和持久化有差異需要處理。

為什麼從 DragonflyDB 遷回

DragonflyDB 遷回 Redis/Valkey 的 driver 跟正向遷移互為鏡像：

• Redis Modules 需求：業務開始需要 RedisJSON、RediSearch 或 RedisTimeSeries，DragonflyDB 不支援 Redis Modules 生態
• Cluster mode 需求：DragonflyDB 設計為單機 scale-up，當資料量超過單機記憶體上限（數 TB）或需要跨 node sharding 時，Redis Cluster 或 Valkey Cluster 是成熟選擇
• Sentinel / HA 生態：DragonflyDB 的 HA 用自家 replication，不支援 Sentinel。若團隊已有 Sentinel 或 Operator 基礎設施，回到 Redis/Valkey 整合成本更低
• BSL 授權疑慮：DragonflyDB 是 BSL 1.1（4 年後轉 Apache 2.0），部分組織偏好 BSD（Valkey）或即使是 RSALv2（Redis）的已知授權

6 維 diff dimension audit

全域 Low-Medium → Type B drop-in，工作重心在 HA 架構切換和持久化模式對齊。

相容性確認

DragonflyDB → Redis 的相容方向跟 Redis → DragonflyDB 相反 — Redis 是 superset，回到 Redis 不會有功能缺失。但有幾個操作面差異需要處理：

階段一：資料匯出

DragonflyDB 支援 SAVE / BGSAVE 產生 RDB 格式 snapshot，跟 Redis RDB 相容。

1# 在 DragonflyDB 觸發 snapshot
2redis-cli -h dragonfly-host BGSAVE
3
4# 等 BGSAVE 完成
5redis-cli -h dragonfly-host LASTSAVE
6
7# 複製 snapshot 檔案到 Redis 資料目錄
8cp /dragonfly-data/dump.rdb /redis-data/dump.rdb

RDB 載入驗證：

1# 啟動 Redis 載入 RDB
2redis-server --dbfilename dump.rdb --dir /redis-data
3
4# 驗證 key count
5redis-cli DBSIZE

若 DragonflyDB 跑的是較新版本產出的 RDB，先在測試環境驗證 Redis 能正常載入。DragonflyDB 的 RDB 基於 Redis 6.x 格式，Redis 7.x 和 Valkey 8.x 向下相容無問題。

階段二：HA 架構重建

DragonflyDB 回到 Redis/Valkey 後，HA 需要從 DragonflyDB replication 切換到 Sentinel 或 Cluster。

Sentinel 路徑（適合非分片場景）

1 primary + N replica + 3 Sentinel nodes。配置見 Sentinel HA Failover。

Cluster 路徑（適合需要分片的場景）

最小 3 primary + 3 replica。配置見 Redis Cluster Resharding。

選擇依據：資料量 < 單機記憶體的 70% 用 Sentinel，需要水平擴展用 Cluster。

階段三：Client 切換

Application 的 Redis client 不需要改 API — DragonflyDB 跟 Redis 用同一套 RESP 協定。需要改的只有：

1. Endpoint：從 DragonflyDB host:port 改為 Redis primary（或 Sentinel/Cluster endpoint）
2. 認證：若 DragonflyDB 用 requirepass，Redis 同參數；若要升級到 ACL 趁此機會配置
3. Sentinel/Cluster 配置：client library 需要啟用 Sentinel discovery 或 Cluster mode

1# 切換前：直連 DragonflyDB
2r = redis.Redis(host="dragonfly-host", port=6379, password="secret")
3
4# 切換後：Sentinel 模式
5sentinel = redis.Sentinel([("sentinel-1", 26379), ("sentinel-2", 26379), ("sentinel-3", 26379)])
6r = sentinel.master_for("mymaster", password="secret")

階段四：效能 baseline 與回退

效能預期

回到 Redis 後，單機 throughput 會低於 DragonflyDB（Redis 單主線程 vs DragonflyDB 多線程）。建立 baseline 時要跟 Redis 的歷史數據比，不是跟 DragonflyDB 比。

回退路徑

回退到 DragonflyDB：把 Redis 的 RDB dump 回 DragonflyDB 載入，endpoint 改回。Cache 資料可重建，即使 RDB 不搬，DragonflyDB 重啟後 cache miss 回源到 DB 即可。

DragonflyDB 在遷移完成後保留 7 天再下線。

交接路由

• Source vendor：DragonflyDB
• Target vendor：Redis / Valkey
• 反向路徑：Redis → DragonflyDB
• HA 重建：Sentinel HA Failover、Cluster Resharding
• 持久化注意：Persistence Fork Latency

本文是跨 vendor migration playbook、cross-link 到 KeyDB（source）跟 Redis / Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type B drop-in（KeyDB 是 Redis fork、RESP 相容、RDB/AOF 相容），但 active-active replication 跟 multi-threading 特性回退需要額外處理。

為什麼從 KeyDB 遷回

KeyDB 是 Snap 維護的 Redis fork，主要差異化在多線程和 active-active replication。遷回的 driver：

• 維護活躍度疑慮：KeyDB 的 release cadence 跟 Redis/Valkey 主線比較慢，部分組織擔心長期維護與安全 patch 的及時性
• Valkey 生態收斂：Valkey 在 Linux Foundation 治理下快速演進（8.x 多線程改進），KeyDB 的多線程優勢逐漸縮小
• Active-active 不再需要：業務不再需要跨 region active-active、或改用 application 層處理衝突解析
• 社群與工具生態：Redis/Valkey 的 client library、monitoring exporter、Operator 支援度更廣

6 維 diff dimension audit

Type B drop-in，工作重心在 active-active replication 拆除和效能 baseline 對齊。

KeyDB 特有功能的處理

FLASH storage 的處理取決於冷資料比例。如果多數資料在 FLASH 上（用 OBJECT FREQ 確認），遷移後的 Redis 記憶體需求會大幅上升 — 要提前計算純記憶體所需容量，調整 instance 規格或改用更積極的 eviction policy。Subkey expires 和 EXPIREMEMBER 的影響範圍通常較小，但一旦 application 依賴就需要重構資料結構（用 top-level key + TTL 或 sorted set 模擬過期）。

Active-active 拆除

若 KeyDB 的 active-active replication 正在使用，遷移前需要先收斂為單主寫入：

1. 選定一個 region 的 KeyDB 為 primary，其他 region 停止寫入
2. 等資料同步完成（replica 追上 primary offset）
3. 從 primary 做 RDB export
4. 用 RDB 建立 Redis/Valkey instance
5. 各 region 的 application 切到新的 Redis/Valkey（Sentinel 或 Cluster）

資料搬遷

KeyDB 的 RDB 和 AOF 與 Redis 格式相容，搬遷流程跟 DragonflyDB 回退類似：

1# KeyDB 端觸發 BGSAVE
2redis-cli -h keydb-host BGSAVE
3
4# 複製 RDB 到 Redis/Valkey 資料目錄
5scp keydb-host:/data/dump.rdb redis-host:/data/dump.rdb
6
7# Redis/Valkey 載入
8redis-server --dbfilename dump.rdb --dir /data

如果使用了 FLASH storage，RDB 只包含記憶體中的資料。FLASH 上的冷資料需要先用 OBJECT FREQ 確認存取頻率，決定是要 warm up 到記憶體再 export，還是接受遷移後冷資料 cache miss 回源。

效能差異預期

回退路徑

Cache 資料可重建，回退方式：

1. Application endpoint 改回 KeyDB
2. 若 KeyDB 已下線，重啟 KeyDB 載入 Redis 的 RDB（格式相容）
3. Cache miss 回源到 DB 自然 warm up

KeyDB 保留 7 天再下線。

交接路由

• Source vendor：KeyDB、KeyDB Active-Active Replication
• Target vendor：Redis / Valkey
• HA 重建：Sentinel HA Failover
• 效能參考：Persistence Fork Latency、Connection Pipeline Latency

與 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。

本文是 AWS ElastiCache overview 的 implementation-layer deep article。選型層（為何用 managed、engine 選擇、跟自管取捨）見 overview；本文只處理「決定用 ElastiCache 後，哪些是 AWS 的責任、哪些仍是你的」。CLI 與計費以 AWS ElastiCache 官方文件、ElastiCache 定價 為準、最後檢查日 2026-06-16（managed 服務的引數與價格會變、以官方為準）。

managed 不等於 hands-off

把 cache 換成 ElastiCache 之後，最危險的心態是「現在 AWS 全包了」。AWS 確實接走了一大塊運維——它幫你做 failover、patching、snapshot、跨 AZ 複製，你不用再自己部署 Sentinel、不用半夜起來手動切 master。但有一類問題 ElastiCache 一個都沒幫你解，而且因為「以為 AWS 會處理」，這些問題在 managed 環境反而更容易被忽略到上線才爆。

Tinder 的配對引擎跑在 ElastiCache for Valkey 上、4700 萬月活、sub-millisecond 延遲——這證明 managed 撐得起極大規模，但 Tinder 仍要自己設計 key、處理 cache miss、控制 client 行為。ElastiCache for Redis 7.1 在 r7g.4xlarge 上單 node 可達約 100 萬 RPS、單 cluster 約 5 億 RPS（引自 AWS Database Blog）——這個吞吐是 AWS 給的，但用不用得好取決於你的 key 分布與 client 設計。

理解 ElastiCache 就是劃清這條責任邊界。本文按 shared responsibility 展開：AWS 管什麼、你管什麼、邊界上的踩坑在哪。

核心概念：shared responsibility 的兩側

ElastiCache 的責任劃分可以列成一張清楚的表，這張表是判讀所有 ElastiCache 事故的起點：

左欄是用 managed 換到的，右欄是用 managed 換不掉的。2.C9 cache stampede 的雪崩、連線風暴、eviction 選錯 在 ElastiCache 上跟自管 Redis 一模一樣會發生——因為這些是 cache 使用方式的問題，不是運維的問題。

engine 選擇與 cluster mode

ElastiCache 的兩個結構性決策：

engine：2024 起 default 是 Valkey（成本約低 20%、OSI 開源、Redis 7.2.4 fork、API 相容）；Redis OSS 仍可選但 AWS 不推；Memcached 是另一條線（純 KV、無 cluster mode 概念）。新部署或既有 Redis 遷移都走 Valkey（相容、便宜），純 cache 才考慮 Memcached。

cluster mode：disabled 是 1 primary + 最多 5 replica、單 shard、上限約 340GB；enabled 是多 shard（最多 500）、自動 sharding、橫向擴展。判讀：dataset < 300GB 且不需 sharding 用 disabled（簡單），> 300GB 或要橫向擴展用 enabled（但 client 要 cluster-aware）。

配置：建立與治理的設定路徑

 1# 建立 Valkey replication group（Multi-AZ、auto failover、cluster mode disabled）
 2aws elasticache create-replication-group \
 3  --replication-group-id prod-cache \
 4  --replication-group-description "prod cache" \
 5  --engine valkey \
 6  --cache-node-type cache.r7g.large \
 7  --num-cache-clusters 3 \           # 1 primary + 2 replica
 8  --automatic-failover-enabled \
 9  --multi-az-enabled \
10  --snapshot-retention-limit 7 \     # 自動 snapshot 保留 7 天
11  --at-rest-encryption-enabled \
12  --transit-encryption-enabled
13
14# 自訂 parameter group（maxmemory-policy 等仍是你的責任）
15aws elasticache create-cache-parameter-group \
16  --cache-parameter-group-name prod-params \
17  --cache-parameter-group-family valkey8 \
18  --description "prod cache params"
19aws elasticache modify-cache-parameter-group \
20  --cache-parameter-group-name prod-params \
21  --parameter-name-values "ParameterName=maxmemory-policy,ParameterValue=allkeys-lru"

配置判讀：

• --automatic-failover-enabled + --multi-az-enabled 是 HA 的核心，把 Sentinel 那條 failover 時序鏈託管掉
• maxmemory-policy 透過 parameter group 設定——AWS 給旋鈕、選哪個是你的責任（見 eviction 調校）
• --transit-encryption-enabled 加 TLS，但 TLS 增加 client 建連成本，連線池更重要
• IAM authentication（Redis 7+）取代 AUTH password，對應 security 模組

Production 故障演練

Case 1：failover 期間 client 持續 error

徵兆：ElastiCache 觸發 failover（看 describe-events），AWS 端 replica 晉升完成，但 application 持續 30 秒到幾分鐘大量連線 error。

根因：failover 時 primary endpoint 的 DNS 切到新 primary，但 client 的連線池還握著舊 primary 的連線、DNS 也可能有快取。AWS 完成了 failover，但 client 重連是你的責任——ElastiCache 不會幫你的 application 重連。

修法：

1. client 用支援自動重連的 library，設合理的 socket timeout 與 retry（見 連線調校）
2. 連到 primary endpoint（會跟著 failover 更新 DNS），不要連到特定 node 的 endpoint
3. 縮短 client 的 DNS 快取 TTL，讓 failover 後的 DNS 切換更快被看到
4. failover 期間的寫入中斷無法完全避免（非同步複製 + 重連時間），latency-sensitive 服務要設計降級

Case 2：跨 AZ replication lag 造成 stale read

徵兆：寫入 primary 後立刻從 replica 讀，偶爾讀到舊值；CloudWatch 的 ReplicationLag 在高寫入時段上升。

根因：ElastiCache 的跨 AZ 複製是非同步的，replica 有 lag。AWS 保證複製會發生，但不保證即時——read-from-replica 在寫後立即讀的場景會看到 stale window。這跟自管 Redis 的 replica 行為一致，managed 沒有消除它。

修法：

1. 寫後需要立即一致讀的路徑，強制 read from primary
2. 監控 CloudWatch ReplicationLag，持續高代表寫入超過複製能力，要 scale up node 或降寫入
3. 接受 cache 的最終一致性——這是 cache copy 的本質，不是 bug（見 cache copy boundary）
4. 需要強一致 + durability 走 MemoryDB（見本文 Capacity / cost 邊界段）

Case 3：Serverless 計費超出預期

徵兆：用了 ElastiCache Serverless 想省容量規劃，月底帳單遠超預期。

根因：Serverless 按 ECPU（運算）+ storage 計費，流量尖峰或低效的 access pattern（大量小命令、大 value）會推高 ECPU 消耗。Serverless 解的是「不想規劃容量」，不是「一定更便宜」——可預測的穩態流量用 node-based + Reserved Instance 通常更省。

修法：

1. 流量可預測、穩態高的 workload 用 node-based + Reserved Instance（1/3 年承諾、折扣約 30-60%）
2. 流量不可預測、有大量閒置時段的才適合 Serverless
3. 監控 ECPU 消耗，找出推高成本的 access pattern（用 pipeline 合併小命令降 ECPU）
4. 成本模型對比要算實際 workload，不要假設 Serverless 一定划算

Case 4：cluster mode enabled 但 client 不是 cluster-aware

徵兆：建了 cluster mode enabled 的 cluster，application 連線報 MOVED redirect 或連不上某些 key。

根因：cluster mode enabled 把 keyspace 分到多 shard，client 必須 cluster-aware（懂 CLUSTER SLOTS、處理 MOVED/ASK redirect）才能正確路由。普通 standalone client 連 cluster mode enabled 會失敗。

修法：

1. cluster mode enabled 一律用 cluster-aware client（連 configuration endpoint 不是單一 node）
2. 確認 application 的多 key 操作用 hash tag 把相關 key co-locate 同 slot（見 cluster re-sharding）
3. dataset < 300GB 且不需 sharding，用 cluster mode disabled 省掉這層複雜度
4. 從 disabled 升 enabled 是有成本的架構變更，初期規劃就要決定

Case 5：snapshot 期間記憶體尖峰、node 不穩

徵兆：自動 snapshot 時段 node 延遲上升、DatabaseMemoryUsagePercentage 衝高，偶爾 snapshot 失敗。

根因：Redis engine 的 snapshot 靠 fork（見 persistence / fork latency），fork 期間 copy-on-write 推高記憶體。如果 node 記憶體已吃緊，snapshot 的 fork 把它推爆。AWS 託管了 snapshot 排程，但 fork 的記憶體成本仍在 engine 層存在。

修法：

1. node 記憶體留 headroom（不要長期 > 80%），給 snapshot 的 fork copy-on-write 空間
2. snapshot window 設在低流量時段，減少 fork 期間被改的 page
3. 監控 CloudWatch DatabaseMemoryUsagePercentage，> 80% 考慮 scale up node type
4. Valkey engine 繼承 Redis 的 fork 模型，這個成本換 engine 到 Valkey 也還在（fork-less 要 DragonflyDB、但 ElastiCache 不提供）

Capacity / cost 邊界

ElastiCache 的容量判讀，混合了 AWS 的 metric 與 engine 層的行為：

撞牆後的路由判斷：

• 需要 source-of-truth 的 Redis API（不是 cache）：ElastiCache 是 cache 語意（資料可重建）。需要 durability 走 AWS MemoryDB——Redis-compatible 但有 multi-AZ transaction log、提供 source-of-truth 語意，成本約 ElastiCache 的 2-3 倍。判讀：Tubi 把 feature store 從 ScyllaDB 遷到 ElastiCache 的前提是「feature 可重新計算」——可重建選 ElastiCache，不可重建選 MemoryDB 或 database。
• 跨雲 / 不在 AWS 生態：ElastiCache 綁 AWS，跨雲走自管 Redis / Valkey 或 GCP Memorystore / Azure Cache。
• 極端單機 throughput：要榨單機多核走自管 DragonflyDB（ElastiCache 不提供 Dragonfly engine）。
• 跨 region active-passive DR：ElastiCache 的 Global Datastore（1 primary region + 多 secondary read replica、跨 region lag < 1 秒），不支援 active-active multi-master。

整合 / 下一步

ElastiCache 的 deep article 本質是「劃清 managed 邊界」，它跟 engine 層的調校知識緊密相連：

• 跟 Redis 全系列 deep article：eviction、persistence/fork、連線的調校在 ElastiCache 上仍適用（engine 是 Redis/Valkey），AWS 託管的是 failover/patching/snapshot 排程，不是這些 engine 行為。
• 跟 Valkey 相容性：ElastiCache 的 default engine 就是 Valkey，相容性與 io-threads 的判讀直接適用。
• 跟 Netflix EVCache：EVCache 是 Netflix 自管的 Memcached-based 全域 cache，對照 ElastiCache for Memcached + Global Datastore——展示了自管跨區 vs managed 跨區的取捨。
• 跟 Tinder / Tubi：兩個 ElastiCache 規模化案例，一個是 sub-ms 配對引擎、一個是 ML feature store p99<10ms，都展示了「AWS 給吞吐、你給設計」的邊界。

相關連結

• 上游 vendor 頁：AWS ElastiCache
• engine 層 deep article：Redis 記憶體與淘汰、persistence 與 fork latency、Sentinel 與 failover 時序、Valkey 相容性
• 上游能力：0.6 成本取捨、cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是 Caffeine overview 的 implementation-layer deep article。選型層（Caffeine vs Redis、process-local 的定位）見 overview；本文只處理「決定用 L1 Caffeine + L2 Redis 後，跨實例一致性怎麼處理」。API 以 Caffeine wiki 為準、最後檢查日 2026-06-16。

兩層 cache 搭起來容易，難的在後面

L1 Caffeine + L2 Redis 的兩層 cache，讀寫路徑三十行 Java 就寫完：讀的時候先查 L1（process-local、奈秒級），miss 再查 L2（Redis、毫秒級），再 miss 才回源。它擋掉了大部分 Redis 的網路往返，對「每個請求重複讀同一份小資料」的場景效果立竿見影。

真正的難度不在搭兩層，在「每個 JVM 實例有自己的 L1 副本」這個事實。假設有 10 個 application 實例，就有 10 份獨立的 Caffeine cache。實例 A 更新了某個 user 的資料、寫進 L2 Redis，但實例 B、C、D… 的 L1 還握著舊值——它們不知道資料變了。下一個打到實例 B 的請求，L1 命中，回的是舊值。Redis 是對的，但讀不到 Redis，因為 L1 先攔截了。

這就是兩層 cache 的核心問題：L1 的速度來自「不跟任何人協調」，而一致性恰恰需要協調。本文聚焦這個矛盾——兩層讀寫路徑只是背景，跨實例 invalidation 才是全部的工程量。

核心概念：L1 的 stale 從哪裡來

兩層 cache 的一致性問題，根源是 L1 的三個特性：

L1 是 per-instance 的私有副本。Caffeine 活在 JVM heap 內，每個實例一份。這是它快的原因（無網路、無序列化），也是它難一致的原因（無法被其他實例直接更新或清除）。L2 Redis 是共享的，所以 L2 一致相對容易；L1 才是 stale 的來源。

寫入只更新本地 L1 + 共享 L2。實例 A 處理一個更新：寫 L2 Redis（所有實例可見）+ 更新或清除自己的 L1。但 A 沒有辦法直接碰 B 的 L1——B 的 L1 還是舊的，直到它自己過期或被通知。

沒有通知機制，L1 只能靠 TTL 自然過期。如果不做任何跨實例協調，L1 的 stale window 就等於 L1 的 TTL。把 L1 TTL 設短（幾秒到幾十秒）是最簡單的「容忍 stale」策略——犧牲一點新鮮度換掉協調的複雜度。需要更快失效就得主動廣播。

跨實例失效的標準解法是用 L2 Redis 的 pub/sub 當廣播通道：任一實例更新資料時，往一個 channel 發一條「key X 失效了」的訊息，所有實例訂閱這個 channel、收到就清掉自己 L1 對應的 entry。這把「各自為政的 L1」連成一個能協同失效的網。

配置：兩層讀寫 + pub/sub 失效的程式碼

兩層讀取路徑（L1 → L2 → origin）：

 1public User getUser(String id) {
 2    // L1：Caffeine、奈秒級、命中就回
 3    User u = l1.getIfPresent(id);
 4    if (u != null) return u;
 5
 6    // L1 miss → L2 Redis、毫秒級
 7    String json = redis.get("user:" + id);
 8    if (json != null) {
 9        u = deserialize(json);
10        l1.put(id, u);                 // 回填 L1
11        return u;
12    }
13
14    // L2 miss → 回源 + 雙層回填
15    u = userRepository.findById(id);
16    redis.setex("user:" + id, 300, serialize(u));  // L2 TTL 5 分鐘
17    l1.put(id, u);                     // L1
18    return u;
19}

跨實例失效（寫入時往 Redis pub/sub 廣播、所有實例清 L1）：

 1// L1 設短 TTL 當保險（廣播漏掉時的上界）
 2Cache<String, User> l1 = Caffeine.newBuilder()
 3    .maximumSize(10_000)
 4    .expireAfterWrite(Duration.ofSeconds(30))  // 廣播失效之外的兜底
 5    .build();
 6
 7// 寫入：更新 L2 + 廣播失效
 8public void updateUser(User u) {
 9    userRepository.save(u);
10    redis.setex("user:" + u.id(), 300, serialize(u));  // 更新 L2（TTL 對齊讀路徑的 300s）
11    redis.publish("cache:invalidate", u.id());   // 廣播給所有實例
12    l1.invalidate(u.id());                        // 清自己的 L1
13}
14
15// 每個實例啟動時訂閱、收到就清本地 L1
16redis.subscribe("cache:invalidate", message -> l1.invalidate(message));

關鍵：L1 的短 TTL 是廣播機制的兜底——即使某個實例漏掉一條 pub/sub 訊息（pub/sub 是 fire-and-forget、訂閱者離線會錯過），L1 最多 stale 到 TTL 過期。廣播負責「快」，TTL 負責「最終」。

Production 故障演練

Case 1：更新後其他實例持續回舊值

徵兆：使用者改了資料、自己刷新看到新值（打到處理寫入的實例），但同事看到的還是舊值（打到別的實例），且持續好幾分鐘。

根因：只更新了寫入實例的 L1 與 L2，沒有跨實例廣播。其他實例的 L1 還握著舊值、攔截了讀取、根本沒查到已更新的 L2。stale window 等於 L1 TTL（如果 TTL 設很長就是好幾分鐘）。

修法：

1. 加 Redis pub/sub 廣播失效，寫入時通知所有實例清 L1
2. 廣播之外把 L1 TTL 設短當兜底（幾秒到幾十秒），縮短漏訊息時的 stale 上界
3. 強一致需求的資料根本不該進 L1——L1 的本質就是「容忍一個 stale window 換速度」
4. 對應 cache copy boundary 的新鮮度邊界判斷

Case 2：pub/sub 漏訊息、個別實例 L1 卡舊值

徵兆：多數實例更新後正常，但偶爾某個實例持續回舊值，直到重啟或 TTL 過期。

根因：Redis pub/sub 是 fire-and-forget——訂閱者在訊息發出的瞬間若斷線（網路抖動、GC pause、重連中），就永久錯過那條失效訊息。沒有兜底的話，那個實例的 L1 會一直 stale 到 TTL。

修法：

1. L1 TTL 設短是必要兜底，不要依賴 pub/sub 100% 送達（它不保證）
2. 需要可靠失效用 Redis Streams（有 consumer group + 重放）取代 pub/sub，代價是複雜度
3. 監控各實例的 L1 命中率與 stale 投訴，個別實例異常代表漏訊息
4. 接受 pub/sub 的 at-most-once 語意，用 TTL 補足最終一致

Case 3：L1 太大撐爆 heap、Full GC 風暴

徵兆：加了 L1 後 application 的 GC 時間變長、偶發 Full GC 導致請求暫停（STW），延遲尖刺。

根因：Caffeine 預設 on-heap，L1 的 maximumSize 設太大、cache 的物件佔據大量 heap，增加 GC 掃描與回收壓力。大物件 + 大容量直接推高 old gen 佔用。

修法：

1. maximumSize 對齊 heap 預算，用 recordStats() 看實際記憶體佔用
2. 用 maximumWeight + weigher 按物件實際大小限制（不只筆數），避免大物件撐爆
3. L1 只放「小、熱、重複讀」的資料，大物件留 L2 Redis（off-heap 視角）
4. 監控 GC 時間與 old gen 佔用，L1 容量是可調的 GC 旋鈕

Case 4：L1 快取了不該快取的 per-user 大物件

徵兆：L1 命中率偏低、heap 壓力大、效果不如預期。

根因：把 per-user 的大物件或低重複率的資料放 L1。L1 的價值在「少量資料被大量重複讀」（如設定檔、熱門商品、權限表），per-user 資料每個 user 一份、重複率低、塞滿 L1 又命中率低。

修法：

1. L1 只放高重複率的共享熱資料（config、feature flag、熱門 item、權限）
2. per-user 低重複資料放 L2 Redis 就好，不要進 L1
3. 用 recordStats() 的 hit rate 驗證——L1 命中率低代表放錯資料
4. 對應 2.4 cache data shape 的存取形狀判斷

Case 5：refreshAfterWrite 與 expireAfterWrite 混淆、行為不如預期

徵兆：以為設了自動刷新、結果到期還是 miss 阻塞回源；或以為會過期、結果一直回舊值。

根因：expireAfterWrite（到期 entry 失效、下次讀 miss + 阻塞載入）跟 refreshAfterWrite（到期後第一個讀觸發背景刷新、舊值立即回、不阻塞）語意不同，混用導致行為不符預期。

修法：

1. 要「到期就不可用」用 expireAfterWrite；要「到期背景刷新、舊值先頂」用 refreshAfterWrite
2. 兩者可組合：refreshAfterWrite 短 + expireAfterWrite 長，得到「背景刷新 + 最終過期」
3. refreshAfterWrite 避免 stampede（舊值先服務、單一背景刷新），適合熱 key
4. 用 LoadingCache 的 build(key -> load) 配 refresh，行為以官方 wiki 為準

Capacity / cost 邊界

兩層 cache 的容量判讀，核心在 L1 命中率、stale window 與 GC：

撞牆後的路由判斷：

• 需要強一致 / 不能容忍任何 stale：L1 process-local 本質有 stale window，不該放這類資料。強一致只用 Redis / Valkey 共享層（甚至直接回源）。
• L1 容量需求超過 heap：on-heap Caffeine 撐不住，用 off-heap 方案（Ehcache off-heap tier）或把資料留 L2 Redis。
• 可靠失效（不能漏）：pub/sub 是 at-most-once，要可靠用 Redis Streams 的 consumer group，代價是複雜度。
• 非 JVM 服務：Caffeine 綁 JVM，其他語言用對應的 process-local cache（Go ristretto、Rust moka），兩層架構的思路相同。

整合 / 下一步

兩層 cache 的工程量集中在跨實例一致性，它跟多個議題交織：

• 跟 Caffeine overview：overview 點到「跨實例 invalidation 是固有限制」、本文展開 pub/sub 廣播 + TTL 兜底的具體解法。
• 跟 Redis connection / pipeline：L1 的價值正是消除 L2 Redis 的 RTT 稅，兩層 cache 是 RTT 優化的極致（L1 命中連網路都省）。
• 跟 2.6 high concurrency：hot key 的兩層解法（local cache + Redis）就是這個架構，L1 擋掉打在單一熱 key 的洪峰。
• 跟 Tinder：每次互動查多個 cache 的服務，L1 Caffeine 可擋掉重複讀、降低 L2（ElastiCache）的壓力與 RTT——但 per-user 配對資料重複率低、要判斷哪些放得進 L1。

相關連結

• 上游 vendor 頁：Caffeine
• L2 對照：Redis 記憶體與淘汰、Redis 連線 / pipeline
• 上游概念：2.6 high concurrency、2.7 cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是 DragonflyDB overview 的 implementation-layer deep article。選型層（為何選 DragonflyDB、BSL 授權、相容度）見 overview；本文只處理「決定用 DragonflyDB 後，多核架構怎麼用、相容邊界在哪」。命令實機驗證於 dragonfly df-v1.39.0（redis_version:7.4.0）、最後檢查日 2026-06-16；效能數字以 DragonflyDB 官方 benchmark 為準。

scale-up 還是 scale-out：一個架構賭注

把一台 32 核機器交給 Redis，Redis 的主執行緒只用得到其中一核處理命令——要榨乾這台機器，你得在同一台上跑好幾個 Redis 進程、組成 Cluster、用 hash slot 把 key 分片。多核利用變成了一個分散式系統問題（cluster re-sharding、cross-slot transaction、hash tag 治理全都來了）。

DragonflyDB 賭的是相反方向：一個進程、thread-per-core、shared-nothing，讓單機在不分片的情況下用滿所有核。它的論點是——多數「需要 Redis Cluster」的場景，真正的需求是吞吐與記憶體，不是跨機器分散；如果單機就能撐到那個規模，Cluster 的複雜度就不必付。實機可以看到這個架構：

1redis-cli INFO server | grep -E "thread_count|redis_version|dragonfly_version"
2# thread_count:8               ← 自動對齊 CPU 核數
3# redis_version:7.4.0          ← 對 client 裝成 Redis 7.4
4# dragonfly_version:df-v1.39.0

thread_count:8 在一個進程內，不是 8 個 Redis 進程組 Cluster。這就是賭注的核心：把 Redis Cluster 的水平分片，收進單一進程的垂直多核。理解 DragonflyDB 就是理解這個賭注成立的條件與它撞牆的地方。

對高吞吐單機 workload，這個賭注有現成的對照。Snap 在 multi-cloud 用 KeyDB（Redis 的 multi-threaded fork、單實例吞吐提升 5-10x）撐超高吞吐 cache，正是「不想為了多核去組 Cluster」的同一類需求；DragonflyDB 是這條路線更激進的版本（從零用 C++ 重寫、不是在 Redis 上加 thread）。

核心概念：thread-per-core 與 shared-nothing

DragonflyDB 的多核不是「多個執行緒搶同一份資料」，而是把資料切給各個執行緒、彼此不共享——這是它能線性擴展到多核的關鍵。

thread-per-core + 資料分區。每個 thread 綁一個核，keyspace 被 hash 切成多個 slice，每個 slice 只由一個 thread 擁有。一個命令進來，被路由到擁有該 key 的 thread 處理。因為一個 key 只有一個 thread 碰，單 key 操作不需要鎖——這消除了 Redis 多執行緒方案最大的開銷（lock contention）。

dashtable 取代 Redis 的 dict。DragonflyDB 用自製的 dashtable（一種 hash table）取代 Redis 的 dictionary，記憶體佈局更緊湊、resize 時不需要像 Redis 那樣漸進式 rehash 全表，同樣的 dataset 通常比 Redis 省 20-40% 記憶體（依資料形狀，以官方 benchmark 為準）。

fork-less snapshot。Redis 的持久化靠 fork()，大記憶體下會凍結主執行緒並讓記憶體接近翻倍（見 Redis persistence deep article）。DragonflyDB 不用 fork——它用自己的快照演算法在不複製整個進程的前提下做一致性快照，大記憶體場景不付 fork 的延遲尖峰與記憶體翻倍代價。這是它對「fork 是 Redis 結構性瓶頸」這個痛點的直接回答。

多執行緒的代價：沒有 Redis Cluster mode。資料分區在單進程內，DragonflyDB 不提供 Redis Cluster mode（它的哲學是單機撐大、不跨機器分片）。這個取捨決定了它的相容邊界與容量天花板，是後面踩坑的根源。

配置：多核與持久化的設定路徑

1docker run -d --name dragonfly -p 6379:6379 \
2  docker.dragonflydb.io/dragonflydb/dragonfly \
3    --threads 8 \              # thread 數、預設等於 CPU 核數（一般不需手動設）
4    --maxmemory 4gb \          # 記憶體上限、行為類似 Redis maxmemory
5    --cache_mode true \        # 純 cache 模式：記憶體滿時自動 evict（類似 allkeys-lru）
6    --snapshot_cron "0 3 * * *" # fork-less snapshot 排程（cron 格式、這裡每天 3 點）

調校判讀：

• --threads 預設對齊 CPU 核數，多數情況不需手動設；設小於核數會浪費核，設大於核數沒有意義
• --cache_mode true 讓 DragonflyDB 在記憶體滿時自動淘汰（純 cache 行為）；不開則記憶體滿時拒絕寫入（類似 Redis noeviction）
• --maxmemory 留 headroom，但因為 fork-less，headroom 不需要像 Redis 留那麼多給 fork copy-on-write
• snapshot 用 --snapshot_cron 排程，fork-less 機制讓大記憶體快照不產生延遲尖峰

Production 故障演練

Case 1：client 配 Cluster mode、連不上

徵兆：從 Redis Cluster 遷來，application 的 client library 還配著 cluster mode，連 DragonflyDB 報錯或 hang，CLUSTER 相關命令行為不如預期。

根因：DragonflyDB 不提供 Redis Cluster mode（單進程多核、不跨機器分片）。cluster-aware client 會嘗試 CLUSTER SLOTS 之類的拓樸發現，跟 standalone 的 DragonflyDB 對不上。

修法：

1. client 改回 standalone 配置（不要 cluster mode）
2. 評估原本用 Cluster 的理由：若是為了多核吞吐，DragonflyDB 單進程多核已涵蓋，不需要 cluster mode
3. 若原本用 Cluster 是為了超過單機的容量 / 跨機器分散，DragonflyDB 的 scale-up 模型撐不住，該留在 Redis Cluster
4. 確認 application 沒有依賴 cluster-specific 行為（hash tag 的跨 slot 語意等）

Case 2：某些 Redis 命令 / module 不支援

徵兆：核心 SET/GET/HASH 等正常，但某個命令報 unknown command 或行為跟 Redis 不同，特別是 module 命令（RedisJSON / RedisSearch）與部分冷門命令。

根因：DragonflyDB 相容大多數 Redis 命令但不是 100%；它宣稱相容 redis_version:7.4.0，但部分 module、部分冷門命令、部分 Lua 行為有差異。

修法：

1. 遷移前盤點 application 用到的命令，對照 DragonflyDB 的 API 相容清單（官方 docs）
2. module 重度依賴（RedisJSON / RedisSearch）要特別確認——DragonflyDB 的 module 生態比 Redis 淺
3. Lua script 行為差異要實測，不要假設跟 Redis 完全一致
4. 相容性是遷移的主要風險，跟 Valkey 的相容性驗證同理但 DragonflyDB 邊界更寬（重寫而非 fork）

Case 3：thread 沒對齊核數、多核優勢沒發揮

徵兆：吞吐沒有達到預期、CPU 使用率不均（部分核閒置），thread_count 跟機器核數對不上。

根因：--threads 被手動設成小於 CPU 核數，或容器的 CPU limit 限制了實際可用核數，DragonflyDB 沒能用滿所有核。

修法：

1. redis-cli INFO server | grep thread_count 確認 thread 數對齊實體核數
2. 容器環境確認 CPU limit 沒有卡住 DragonflyDB 的核數（cgroup CPU quota）
3. 不要手動把 --threads 設小，預設對齊核數就是最佳
4. 吞吐沒到預期也可能是 workload 本身（大命令、網路 RTT），用 連線 / pipeline 的 RTT 分析交叉判斷

Case 4：跨 partition 的多 key 操作有額外成本

徵兆：大量多 key 命令（MGET 跨很多 key、跨 key 的 Lua）的延遲比預期高，單 key 操作則很快。

根因：shared-nothing 下 key 分散在不同 thread，多 key 操作要跨 thread 協調——單 key 免鎖的好處在多 key 跨 partition 時要付協調成本。這跟 Redis Cluster 的 cross-slot 是類似的本質（資料分散的代價），只是發生在單進程內。

修法：

1. 高頻的多 key 操作盡量讓 key 落在同 partition（DragonflyDB 的 key 分布規則）
2. 評估能否用單 key 結構（hash）取代多個 key 的聚合
3. 跨 partition 協調是分區架構的固有成本，不是 bug，量大時要設計繞過
4. 對照 Redis Cluster 的 cross-slot 限制，兩者都是「資料分散換吞吐」的代價

Case 5：BSL 授權踩到商業使用限制

徵兆：準備把 DragonflyDB 包成對外的 managed service 提供給客戶，法務 review 卡關。

根因：DragonflyDB 用 BSL（Business Source License），商業使用受限——具體限制是不可把 DragonflyDB 當成 managed service 對外提供（4 年後該版本轉 Apache 2.0）。內部使用無限制，但 SaaS 對外提供 DragonflyDB 即服務受限。

修法：

1. 內部使用（多數企業場景）無限制，直接用
2. 要把 DragonflyDB 當 managed service 對外賣，聯絡 DragonflyDB 取得商業 license
3. 開源合規敏感（公部門 / 企業 OSI 政策）走 OSI 認可的 Valkey（BSD）
4. 授權法律解讀諮詢法務，不要憑技術判斷

Capacity / cost 邊界

DragonflyDB 的容量判讀，核心在 scale-up 的天花板與多核效率：

撞牆後的路由判斷：

• 超過單機容量、需要跨機器分散：DragonflyDB 的 scale-up 賭注在這裡輸——它沒有 Cluster mode。要跨機器分片走 Redis / Valkey Cluster。
• 需要 OSI 認可開源授權：BSL 不是 OSI 認可，合規敏感走 Valkey（BSD）。
• 不想自管：DragonflyDB 目前沒有 fully managed offering（無 ElastiCache for Dragonfly），必須自管。要 managed 走 ElastiCache（Redis / Valkey / Memcached）。
• 跨 AZ / 跨 region HA：DragonflyDB 有 replica 模式（primary-replica）跨 AZ 可行，但跨 region 需自建——大規模跨區走 managed 的 Global Datastore。

整合 / 下一步

DragonflyDB 的定位是「Redis 相容 + 激進多核」，它在 Redis 相容服務的光譜上有明確座標：

• 跟 Valkey：兩者都打「Redis 相容 + 更好的多核」，但 Valkey 是 fork（同源、最高相容、漸進加 thread），DragonflyDB 是 C++ 重寫（相容核心但架構激進、多核更徹底）。相容度要極致選 Valkey，多核吞吐要極致選 DragonflyDB。
• 跟 KeyDB / Garnet：KeyDB 是 Redis 的 multi-threaded fork（Snap 採用、Snap 收購後相對停滯）；Garnet 是 Microsoft 的研究型高吞吐 store（生態淺）。DragonflyDB 是這個「高吞吐 Redis 替代」群裡商業化最積極、生態最活躍的。
• 跟 Redis Cluster re-sharding：如果你的 Redis Cluster re-sharding 頻繁觸發、運維負擔重，DragonflyDB 的 scale-up 模型可能用單機取代整個 Cluster——這是評估遷移的主要動機。
• 跟 Shopify write-through：write-through 在 DragonflyDB 上行為一致，但單進程多核能承接比單 Redis 進程更大的 throughput，是 read-heavy + write-through 場景的 scale-up 選項。

相關連結

• 上游 vendor 頁：DragonflyDB
• 對照 vendor：Valkey 相容性與 io-threads、Redis persistence 與 fork latency（fork-less 對照的痛點）
• 相關 migration：Redis → DragonflyDB
• Methodology：Vendor 深度技術文章寫作方法論

本文是 KeyDB overview 的 implementation-layer deep article。選型層（KeyDB vs Redis / DragonflyDB / Valkey、為何選 fork）見 overview；本文只處理「決定用 KeyDB active-active 後，衝突與一致性怎麼判」。命令實機驗證於 eqalpha/keydb image、最後檢查日 2026-06-16；複製機制以 KeyDB active-replication 文件 為準。

兩邊都能寫，聽起來太美好

Redis 的複製是單向的：一個 master 寫、replica 唯讀。要跨區讓兩邊都能就近寫入，Redis 本身做不到（得靠應用層分區或外部工具）。KeyDB 的 active-active 把這個限制拿掉——兩個（含以上）KeyDB 節點都是 master、都能接受寫入、互相把寫入同步給對方。對「兩個 region 都要低延遲寫入同一份 cache」的場景，這聽起來解決了所有問題。

問題藏在「兩邊同時寫同一個 key」的那一刻。active-active 沒有全域協調者來仲裁誰對誰錯，它用 last-write-wins（LWW）：比較兩筆寫入的時間戳，留下較晚的、默默丟掉較早的。多數時候沒事，但當兩個 region 在幾毫秒內各自更新同一個 key，其中一筆寫入會無聲消失——沒有錯誤、沒有日誌、application 以為自己寫成功了。

理解 KeyDB active-active 就是理解這個取捨：它用 LWW 換到了「兩邊都能寫」的可用性，代價是放棄了強一致與「不丟寫入」的保證。本文展開複製機制、衝突語意，以及哪些資料放得進這個模型、哪些放進去就是 bug。

核心概念：active-active 的複製與衝突語意

active-active 不是「分散式交易」，它是「雙向非同步複製 + LWW 衝突解決」。理解它要抓三個點：

每個節點都是 active-replica。一般 Redis replica 是唯讀的；KeyDB 的 active-replica 既接受本地寫入、又接收對方的複製流。兩個節點互相設定對方為 master，形成雙向複製環。實機看到的 role 就是 active-replica（不是 master / slave）。

複製是非同步的。本地寫入立即回 OK 給 client，之後才非同步傳給對方節點。這意味著兩個節點之間永遠有一個複製延遲窗口——在這個窗口內，兩邊看到的資料可能不同。這是 active-active 是 AP（可用性 + 分區容忍）而非 CP 的根本原因。

衝突用 last-write-wins 解決。同一個 key 在兩個節點被並發修改時，KeyDB 比較版本，保留較晚的寫入、丟棄較早的。沒有 merge、沒有 vector clock、沒有 application callback——就是比誰較晚。KeyDB 用 hybrid logical clock（HLC）排序、不是純 wall-clock，但 HLC 仍綁節點實體時鐘——時鐘不同步（clock skew）會直接影響哪一筆被判定為「較晚」。同步的是 key 的「值」不是「操作」，這也是為什麼並發 INCR 會互相覆蓋而非累加（見故障演練 Case 1）。

每筆寫入帶來源標記避免無限迴圈。A 的寫入同步給 B 後，B 不會再把它當成新寫入傳回 A（否則會無限循環）。KeyDB 用來源標記處理這個，但複製拓樸設計錯（例如環狀多節點）仍可能放大流量。

配置：兩節點 active-active 的設定路徑

實機驗證的最小雙主設定（兩個節點互相複製）：

1# 節點 A 與 B 都開 active-replica + multi-master
2docker run -d --name kdb-a --network kdbnet -p 6401:6379 \
3  eqalpha/keydb keydb-server --active-replica yes --multi-master yes
4docker run -d --name kdb-b --network kdbnet -p 6402:6379 \
5  eqalpha/keydb keydb-server --active-replica yes --multi-master yes
6
7# 互相指向對方（形成雙向複製）
8keydb-cli -p 6401 replicaof kdb-b 6379
9keydb-cli -p 6402 replicaof kdb-a 6379

實機驗證雙向同步（最後檢查日 2026-06-16）：

 1# 寫 A、讀 B
 2keydb-cli -p 6401 SET fromA hello   # → OK
 3keydb-cli -p 6402 GET fromA         # → hello   （A 的寫入同步到 B）
 4
 5# 寫 B、讀 A（雙向）
 6keydb-cli -p 6402 SET fromB world   # → OK
 7keydb-cli -p 6401 GET fromB         # → world   （B 的寫入同步到 A）
 8
 9# 確認 role 與複製鏈路
10keydb-cli -p 6401 INFO replication | grep -E "role|master_link_status|connected_slaves"
11# role:active-replica
12# master_link_status:up
13# connected_slaves:1

兩個節點都回報 role:active-replica（不是傳統的 master / slave），master_link_status:up 確認複製鏈路健康。寫入任一節點、另一節點都讀得到，這就是 active-active 的核心行為。

Production 故障演練

Case 1：並發寫同一 key、一筆寫入無聲消失

徵兆：兩個 region 的 application 各自更新同一個 user 的 cache（例如 profile），事後發現其中一個 region 的更新「沒生效」——但寫入時 application 收到的是 OK，沒有任何錯誤。

根因：active-active 的 LWW。兩筆寫入在複製延遲窗口內並發發生，KeyDB 比較時間戳保留較晚的、默默丟棄較早的。application 兩邊都以為自己寫成功了（本地確實 OK），但同步後只有一筆存活。

修法：

1. 不要讓同一個 key 被多個 region 並發寫——按 key 分區（user X 的寫入永遠路由到 region A），把多主退化成「就近讀 + 單點寫」
2. 真的需要多點寫的計數器類資料，用 CRDT 語意的結構（KeyDB 的 LWW 不適合 counter，並發 INCR 會互相覆蓋而非累加）
3. 接受 LWW 是 cache 的取捨——可重建的 cache 副本丟一筆寫入可回源重算，不可重建的資料不該放 active-active
4. 衝突無聲是最危險的——加應用層的寫入審計（不靠 KeyDB 告警）

Case 2：clock skew 讓「較晚」的判定錯亂

徵兆：明明 region B 後寫的值，最後存活的卻是 region A 先寫的值——LWW 的「後寫者勝」失效。

根因：LWW 比較時間戳，但兩個節點的系統時鐘若沒同步（clock skew），「較晚」的判定就錯了。B 的時鐘慢了 200ms，B 後寫的值帶的時間戳反而比 A 早，被判定為「較舊」丟棄。

修法：

1. 所有 KeyDB 節點強制 NTP 時鐘同步，把 skew 壓到毫秒級
2. 監控節點間的時鐘偏差，skew 超過複製延遲就有 LWW 判定錯亂風險
3. 對時間敏感的衝突，LWW 本質不可靠——時鐘永遠無法完美同步，這是 LWW 模型的固有弱點
4. 需要正確衝突解決的場景，不要用 LWW 的 active-active，改強一致儲存

Case 3：複製延遲下的 stale read

徵兆：region A 寫入後，立刻有請求打到 region B 讀同一 key，讀到舊值；幾百毫秒後再讀才是新值。

根因：active-active 是非同步複製，A 的寫入要經過網路傳到 B 才可見。在這個複製延遲窗口內，B 讀到的是 stale 值。跨 region 的延遲窗口比同 AZ 大得多。

修法：

1. 寫後需要立即一致讀的路徑，讀同一個寫入的節點（read-your-writes 綁定到寫入 region）
2. 監控節點間複製延遲，跨 region 的延遲是 stale window 的下界
3. 接受最終一致——這是 active-active 的本質，cache 場景多數可容忍短暫 stale
4. 不可容忍 stale 的資料不適合 active-active，走單寫入點 + 跨區唯讀 replica

Case 4：複製拓樸設計錯、流量放大或迴圈

徵兆：加了第三個 active 節點組成環狀後，節點間流量異常放大、CPU 升高，甚至同一筆寫入被反覆傳遞。

根因：active-active 多節點（> 2）的拓樸需要小心設計。全互連（full mesh）下每筆寫入要傳給所有其他節點、流量隨節點數平方成長；環狀拓樸若來源標記處理不當可能放大傳遞。

修法：

1. 多節點 active-active 優先用 full mesh 但控制節點數（active-active 不適合大量節點）
2. 監控節點間複製流量，異常放大代表拓樸或來源標記問題
3. 大規模多區優先考慮「每區單寫入點 + 跨區唯讀」而非全 active-active
4. active-active 的甜蜜點是 2-3 個區的雙向就近寫，不是大規模 mesh

Case 5：節點重連後的全量重同步衝擊

徵兆：一個節點短暫斷線後重連，重連瞬間 CPU / 網路尖峰，期間延遲升高。

根因：節點斷線時間過長、超過複製 backlog 能覆蓋的範圍，重連時要做全量重同步（full resync）——對方節點要產生快照（fork、見 Redis persistence 的 fork 成本，KeyDB 繼承 Redis 的 fork 機制）並傳輸整個 dataset。

修法：

1. 設足夠大的 repl-backlog-size，讓短暫斷線走部分同步（partial resync）而非全量
2. 重同步的 fork 成本跟記憶體 headroom 相關，節點要留 fork 空間
3. 監控 master_link_status，頻繁 down / up 代表網路不穩、要先修網路
4. 跨 region 的 active-active 對網路穩定性敏感，不穩的鏈路會頻繁觸發重同步

Capacity / cost 邊界

active-active 的容量判讀，核心在衝突率與複製健康：

撞牆後的路由判斷：

• 需要正確的衝突解決 / 不能丟寫入：LWW 不保證，走強一致儲存（database 模組 的 multi-region 一致性方案）或單寫入點架構。
• 需要 counter / 累加語意的多點寫：LWW 會讓並發 INCR 互相覆蓋，KeyDB active-active 不適合，改 CRDT 或單點 counter。
• 跨 region 但可接受單寫入點：用 Redis / Valkey 的單向複製（一區寫、其他區唯讀），比 active-active 簡單且無衝突。
• 大規模多區：active-active 的甜蜜點是 2-3 區，更大規模走 managed 的跨區方案（ElastiCache Global Datastore 的 active-passive）。

整合 / 下一步

active-active 是 KeyDB 區別於 Redis 的核心能力之一，但它的取捨跨多個子系統：

• 跟 KeyDB overview：overview 點到 active-active 是 last-write-wins、本文展開它什麼時候默默丟資料。
• 跟 Redis persistence / fork latency：KeyDB 繼承 Redis 的 fork 機制，節點重連的全量重同步付 fork 成本。
• 跟 cache copy boundary：active-active 的 stale window 與 LWW 丟寫入，本質是「cache 副本的新鮮度與一致性邊界」議題的多主版本。
• 跟 Snap KeyDB cross-cloud case：Snap 用 KeyDB 的主因是 cross-cloud latency 治理（cache 與 application 共置），active-active 的雙向就近寫是這類 multi-cloud 場景的工具，但要按 key 分區避開 LWW 衝突。

相關連結

• 上游 vendor 頁：KeyDB
• 對照 vendor：DragonflyDB 多核架構、Redis Sentinel failover（單向複製的 HA）
• 上游概念：2.7 cache copy boundary
• Methodology：Vendor 深度技術文章寫作方法論

本文是 Memcached overview 的 implementation-layer deep article。選型層（純 KV vs Redis data types、何時選 Memcached）見 overview；本文只處理「決定用 Memcached 後，slab 記憶體怎麼配才不會莫名淘汰」。命令實機驗證於 memcached:1.6（VERSION 1.6.42）、最後檢查日 2026-06-16；機制以 Memcached 官方 wiki 為準。

明明有記憶體、卻在 evict

Memcached 最違反直覺的故障是這樣：監控顯示 evictions 持續上升、hit rate 在掉，但 stats 算下來實際用掉的記憶體遠低於 -m 設的上限——機器明明還有空間，Memcached 卻在淘汰資料。換成 Redis 思維的人會卡住，因為 Redis 是一個共用的記憶體池，不會出現「有空間卻淘汰」。

這個現象叫 slab calcification，根因在 Memcached 的記憶體模型：它把記憶體預先切成許多固定大小的格子（slab class），每個 class 各自管自己那塊，跟 Redis 共用一個記憶體池的模型相反。記憶體一旦分配給某個 class，預設不會還回去給別的 class 用。如果你的 value 大小分布隨時間改變（早期都是小 value、後來都是大 value），早期被小 value 佔走的記憶體還鎖在小 class 裡，大 value 的 class 沒有足夠空間、開始淘汰——即使整體還有大量「屬於別人」的空閒記憶體。

理解 Memcached 就是理解這套 slab 經濟學。它用「放棄記憶體的靈活性」換到了「永不碎片化、O(1) 分配、可預測的多執行緒擴展」。這個取捨在純 cache 場景非常划算，但它的失敗模式跟 Redis 完全不同，要用 slab 的語言來判讀。

核心概念：slab allocator 的會計模型

Memcached 啟動時不會把 -m 指定的記憶體一次配掉，而是按需求以 page（預設 1MB）為單位分配給 slab class，每個 class 存放某個大小區間的 item。

slab class 與 chunk size。每個 slab class 對應一個固定的 chunk size，item 被放進「裝得下它的最小 class」。class 的 chunk size 按 growth_factor 等比成長——實機看預設值：

1printf 'stats settings\r\nquit\r\n' | nc localhost 11211 | grep growth_factor
2# STAT growth_factor 1.25
3
4printf 'set k1 0 0 5\r\nhello\r\nstats slabs\r\nquit\r\n' | nc localhost 11211 | grep -E "chunk_size|active_slabs"
5# STAT 1:chunk_size 96      ← 最小的 slab class、chunk 96 bytes
6# STAT active_slabs 1

growth_factor 1.25 表示每個 class 的 chunk size 是前一個的 1.25 倍：class 1 是 96 bytes、class 2 約 120、class 3 約 152……一路到 item 大小上限。一個 100 bytes 的 value 放不進 96 bytes 的 class 1，被放進 120 bytes 的 class 2——浪費 20 bytes。這個「向上取整到 chunk size」的浪費是 slab 模型的固有成本。

page 分配是單向的。當某個 class 需要空間，Memcached 給它一個 1MB 的 page，切成該 class 的 chunk。這個 page 預設永久屬於這個 class——這就是 calcification 的來源。-o slab_automove 與手動 slabs reassign 可以把 page 在 class 間搬移，但預設行為偏保守。

LRU 是 per-slab-class 的。淘汰不是全域的，是每個 slab class 維護自己的 LRU。所以「class 2 滿了開始淘汰、但 class 5 有空閒 page」是正常現象——淘汰看的是該 class 自己的空間，不是全域記憶體。

這三點合起來解釋了開頭的悖論：evict 發生在某個 class 內，跟全域剩餘記憶體無關。

配置：slab 與多執行緒的設定路徑

1# 啟動參數（Memcached 的調校多在啟動參數、不像 Redis 有大量 runtime CONFIG SET）
2docker run -d --name memcached -p 11211:11211 memcached:1.6 \
3  memcached \
4    -m 1024 \          # 記憶體上限 1024 MB
5    -t 4 \             # worker thread 數（多執行緒、對齊 CPU 核數）
6    -f 1.25 \          # slab growth factor（預設 1.25、調小→class 更密集→浪費更少但 class 更多）
7    -I 2m \            # 單一 item 大小上限（預設 1MB、超過要調大或拆 value）
8    -o slab_automove=1 # 自動把空閒 page 從一個 class 搬到吃緊的 class（緩解 calcification）

調校判讀：

• -m 是給 item 資料的上限，Memcached 自身的 hash table、連線 buffer 等 overhead 在 -m 之外，機器要留 headroom
• -t 對齊 CPU 核數——Memcached 從早期就是 multi-threaded，這是它跟早期單執行緒 Redis 的核心差異
• -f 調小（例如 1.08）讓 slab class 更密集、向上取整浪費更少，代價是 class 數變多、管理開銷略增
• -I 是單 item 上限，超過會 store 失敗（見故障演練 Case 3）
• slab_automove=1 是緩解 calcification 的關鍵，預設視版本而定，明確開啟較穩

Production 故障演練

Case 1：slab calcification——value 大小漂移造成假性記憶體不足

徵兆：evictions 上升、hit rate 下降，但 stats 顯示 bytes 遠低於 limit_maxbytes。stats slabs 看到某個 class 的 page 用滿在淘汰，另一個 class 有大量空閒 chunk。

根因：value 大小分布隨時間漂移。早期 value 小、記憶體被分配給小 slab class；後來 value 變大、需要大 class，但 page 已被小 class 鎖住不還，大 class 空間不足開始淘汰。整體記憶體沒滿，但「對的 class」沒空間。

修法：

1. 開 -o slab_automove=1，讓 Memcached 自動把空閒 page 從冷 class 搬到吃緊的 class
2. 手動觸發搬移：slabs reassign <src_class> <dst_class>（緊急救火用）
3. 監控 stats slabs 各 class 的 used_chunks vs total_chunks 與 stats items 的 per-class evicted，找出失衡的 class
4. 從源頭穩定 value 大小分布——序列化格式統一、避免同類資料時大時小

Case 2：chunk 向上取整浪費大量記憶體

徵兆：存的 value 總大小算起來只有 600MB，但 Memcached 報用掉接近 1GB，記憶體效率異常低。

根因：value 大小剛好落在 slab class chunk size 的「上緣之外」，被向上取整到下一個更大的 class，每個 item 浪費接近一個 growth step 的空間。例如大量 130 bytes 的 value 被放進 152 bytes 的 class，每個浪費 22 bytes，量大就顯著。

修法：

1. -f 調小（1.25 → 1.08）讓 class 粒度更細，向上取整的浪費變小
2. stats slabs 看主要 class 的 chunk_size 跟你的 value 實際大小差多少，量化浪費
3. value 設計上靠近 chunk 邊界（例如壓縮或裁剪 metadata 讓 value 剛好塞進較小的 class）
4. 浪費是 slab 模型的固有成本，純 KV 的 trade-off——換到的是永不碎片化與 O(1) 分配

Case 3：value 超過 item 大小上限、store 直接失敗

徵兆：某些大 value 的寫入回 SERVER_ERROR object too large for cache，application 端 cache 寫入靜默失敗、之後一直 miss。

根因：單一 item 超過 -I 設的上限（預設 1MB）。Memcached 設計上不適合存大 object，預設 1MB 是刻意的純 cache 邊界。

修法：

1. 確認 value 大小分布，大 value 是否真該進 Memcached（純 KV cache 不適合大 blob）
2. 必要時調大 -I（例如 -I 2m），但這會改變 slab class 結構、增加大 chunk 的記憶體佔用
3. 大 object 考慮壓縮、或拆成多個小 key、或改放適合的儲存（物件儲存 / Redis 的 hash）
4. application 端要處理 store 失敗，不要假設 set 一定成功——失敗就走 origin

Case 4：thread 數設太高、lock contention 反而拖慢

徵兆：把 -t 從 4 調到 32 想榨多核效能，throughput 沒升反降，CPU 在 system time 飆高。

根因：Memcached 的多執行緒有 per-item lock（hash bucket lock），thread 數遠超核數時，執行緒互搶 lock 與 CPU、context switch 開銷超過平行收益。

修法：

1. -t 對齊實體核數，不要超配（多數場景 4-8 已足夠，極高核機器再往上調並壓測）
2. 用實際 workload 壓測對比不同 -t 的 throughput，找拐點
3. hot key 集中時 lock contention 更明顯（同 bucket），這是資料分布問題不是 thread 數問題
4. 跨機器水平擴展（client-side consistent hashing）比單機堆 thread 更能解規模，見本文整合段

Case 5：連線數打到上限、新連線被拒

徵兆：高並發下新連線報錯或 hang，stats 的 curr_connections 接近 max_connections，listen_disabled_num 在增加。

根因：每個 client 連線佔一個 connection slot，Memcached 預設 -c 1024。大量 client（尤其沒用連線池、每請求建連）會打滿 connection 上限。

修法：

1. client 端用連線池重用連線，不要每請求建連
2. 調高 -c（例如 -c 4096），但連線本身有記憶體 overhead（在 -m 之外），要算進機器容量
3. 監控 curr_connections 與 listen_disabled_num，後者非零代表曾達上限拒絕連線
4. 連線數爆炸常是 client fan-out 問題，跨多 Memcached node 分散（consistent hashing）能攤平單 node 連線壓力

Capacity / cost 邊界

Memcached 的容量判讀，核心在 slab 效率與多執行緒擴展：

撞牆後的路由判斷：

• 需要 data types / 持久化 / distributed lock：Memcached 是純 KV、刻意不做這些。需要這些走 Redis / Valkey，這是 capability 差異不是調校能補。
• 單機容量 / throughput 不夠：Memcached 沒有 server-side cluster，靠 client-side consistent hashing（ketama）水平擴展到多 node，見整合。
• 想要 Memcached 的多執行緒 + Redis 的 data types：DragonflyDB 兼具多核與 Redis 相容，是兩者的中間點。

整合 / 下一步

Memcached 的單機很簡單，它的工程深度在「如何把多個 Memcached node 組成一個 cache 層」——而這發生在 client 端與代理層，不在 server：

• client-side consistent hashing（ketama）：Memcached server 之間互不知道彼此，sharding 由 client library 用 consistent hashing 決定 key 去哪個 node，加減 node 時最小化 key 重新分布。這是 Memcached 水平擴展的基礎。
• 跟 Meta mcrouter：Meta 的 mcrouter 是 Memcached 專屬的 protocol-aware routing proxy，把跨叢集 / 跨區的流量收斂、失效隔離、pool 管理從 client 端移到代理層——這是 Memcached 大規模治理的標準答案。
• 跟 Netflix EVCache：EVCache 基於 Memcached，Netflix 在上面加跨 AZ replication 與 client-side smart routing，補足 Memcached 沒有的跨區 HA。
• 跟 Meta TAO：TAO 底層用 Memcached 作為 social graph 的 cache 層，上層加一致性與關聯查詢——展示了純 KV 之上如何疊加語意。
• 跟 Meta CacheLib + Kangaroo：當 DRAM 的記憶體經濟撞到極限，Meta 用 CacheLib 把 cache 分層到 flash——這是 slab 記憶體經濟學的下一個邊界。

相關連結

• 上游 vendor 頁：Memcached
• 對照 vendor：Redis 記憶體與淘汰調校（jemalloc 池 vs slab class 的差異）、DragonflyDB
• 相關 migration：Redis → Memcached
• Methodology：Vendor 深度技術文章寫作方法論

本文是跨 vendor migration playbook、cross-link 到 Redis（source）跟 Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type B drop-in（全維度 Low），結構走 6-section + 相容性 audit 前置。實機驗證於 valkey/valkey:8（valkey_version 8.1.8、redis_version 7.2.4）、最後檢查日 2026-06-16。

同一份程式碼、不同授權

多數 migration 的工作量在「source 跟 target 不一樣」——schema 要翻譯、API 要改、資料要轉。Redis → Valkey 幾乎沒有這個問題：Valkey 是 2024 年從 Redis 7.2.4 直接 fork 出來的，那一刻它跟 Redis 是 bit-for-bit 同一份程式碼。RDB 與 AOF 檔案格式相同（可以直接把 Redis 的資料目錄拷給 Valkey 載入）、RESP 協定相同、所有 Redis client library 不改一行就能連。技術上，這是 cache 領域最容易的遷移。

那為什麼要寫一篇 playbook？因為這個遷移的工作量不在資料層，在兩個別的地方。第一是授權——Redis 2024 改成 RSALv2 / SSPL（非 OSI 認可），Valkey 是 BSD 3-clause（OSI、Linux Foundation 治理），這個遷移的整個 driver 是授權合規，而合規驗證有它自己的流程。第二是fork 後的分歧——fork 那一刻兩者相同，但之後各自演進：Redis 加了 7.4+ 的新功能、Valkey 加了自己的（如 8.x 多執行緒），用到 fork 之後 Redis 新功能的部署會有相容缺口。

INFO server 上看得到這個「同源但分歧」的事實：

1valkey-cli INFO server | grep -E "redis_version|valkey_version"
2# redis_version:7.2.4    ← fork 點、client 以此判斷相容性（裝成 Redis 7.2.4）
3# valkey_version:8.1.8   ← Valkey 自己的演進線

redis_version:7.2.4 是相容性的保證（client 看到就以 Redis 7.2.4 行為運作）；valkey_version 是分歧的證據。這篇 playbook 處理的就是「資料層幾乎零工作、工作在授權與分歧盤點」的 drop-in 遷移。

6 維 diff dimension audit：為什麼是 Type B

跑 diff dimension audit，Redis → Valkey 全維度 Low：

全 Low → Type B drop-in（6-section + 相容性 audit 前置、週期 1-4 週）。跟同模組的 Redis → DragonflyDB 對照：DragonflyDB 是 C++ 重寫（drop-in 但 Lua / encoding / module 有差異），Valkey 是 fork（同源、連 RDB 檔都相容）——Valkey 的相容度比 DragonflyDB 更高，是 Type B 裡最純粹的一端。

這個遷移的特殊之處是 driver 在資料層之外：它是授權 / 合規驅動。依 migration 方法論 的漏類處理，政策 / 合規驅動的遷移資料層仍走 Type B，但 audit 重點多一塊授權驗證與證據收集。

相容性 audit：cutover 前要確認的清單

Valkey 號稱 100% 相容 Redis 7.2.4，但「100%」的邊界在 fork 之後的分歧。Pre-migration 必跑的 audit：

audit 的關鍵 output：兩份清單——(1) 用到的 Redis 7.4+ 功能（fork 後新增、Valkey 可能沒有）、(2) 載入的 Redis Stack module。這兩塊是僅有的相容風險，其餘資料層零工作。盤點方法：

1# 盤點載入的 module（最大相容風險）
2redis-cli MODULE LIST
3
4# 盤點是否用到 7.4+ 功能（抓 production traffic 對照 Redis 7.4 changelog）
5redis-cli MONITOR    # 限時抓樣、grep 可疑的新命令

Step-by-step cutover

因為 RDB 檔案相容，cutover 比 DragonflyDB 更簡單（無版本轉換風險）：

 1# 1. 部署 Valkey（同 Redis 配置、可直接沿用 redis.conf）
 2docker run -d --name valkey -p 6380:6379 \
 3  -v /data/valkey:/data \
 4  valkey/valkey:8 valkey-server /etc/valkey/valkey.conf
 5
 6# 2. Redis 端 BGSAVE 產生 RDB
 7redis-cli -h redis-primary BGSAVE
 8redis-cli -h redis-primary INFO Persistence | grep rdb_last_save_time
 9
10# 3. 把 dump.rdb 拷給 Valkey（檔案格式相容、無需轉換）
11scp redis-primary:/var/lib/redis/dump.rdb valkey-host:/data/valkey/
12
13# 4. 重啟 Valkey 載入 RDB
14docker restart valkey
15
16# 5. 驗證資料一致 + 版本
17valkey-cli -h valkey-host -p 6380 DBSIZE          # 對齊 Redis DBSIZE
18valkey-cli -h valkey-host -p 6380 INFO server | grep redis_version  # 7.2.4
19
20# 6. 替代方案（零停機）：用 replicaof 讓 Valkey 當 Redis 的 replica、即時同步後 promote
21#    valkey-cli -h valkey-host REPLICAOF redis-primary 6379
22#    重要邊界：此路徑只在 source 是 Redis 7.2 或更早版本時成立。
23#    Redis 7.4+（Community Edition）改了複製格式、Valkey 無法當其 replica
24#    → source 為 7.4+ 時改走上面的 RDB 拷貝路徑（步驟 2-4）。
25
26# 7. Cutover：client 配置切到 Valkey endpoint、Redis 留 standby

關鍵時間點：

• RDB 拷貝 + load：100GB 約 5-15 分鐘（無版本轉換、比 DragonflyDB 少一道風險）
• replicaof 路徑：要零停機可讓 Valkey 當 Redis replica 即時同步、確認 lag 趨零後 promote + 切 client（僅限 source 為 Redis 7.2 或更早；7.4+ 複製格式已分歧、不適用、改走 RDB 拷貝）
• Cutover：client 配置切換（單次完成、硬邊界）、Redis 留 standby 1-2 週
• Decom：無相容問題後關閉 Redis

Production 故障演練

Case 1：用到 Redis 7.4+ 功能、Valkey 沒有

徵兆：cutover 後某功能報 unknown command 或行為不同，命令是 Redis 在 7.4 之後（fork 點之後）才加的。

根因：Valkey fork 自 Redis 7.2.4，Redis 7.4+ 新增的功能 Valkey 不一定跟進。pre-migration audit 漏掉了這些 fork 後的新功能。

修法：

1. pre-migration 對照 Redis 7.4+ changelog 盤點用到的新功能（audit 清單第一項）
2. Valkey 有對應就確認版本、沒有就評估改寫或留在 Redis 商業版
3. 多數標準 cache 用法不碰 7.4+ 新功能，這個風險集中在用了較新進階功能的部署
4. Valkey 自己的 roadmap（valkey.io）會逐步補上 Redis 新功能，可追蹤

Case 2：載入了 Redis Stack 商業 module

徵兆：cutover 後 JSON.SET / FT.SEARCH 報 unknown command，application 部分功能失效。

根因：用了 Redis Stack 的商業 module（RedisJSON / RedisSearch），這些不在 fork 範圍。Valkey 有自己的 valkey-search / valkey-bloom，但不是同一套命令、要另外安裝。

修法：

1. pre-migration MODULE LIST 盤點所有載入的 module（audit 清單第二項）
2. 確認 Valkey 對應替代（valkey-search 對 RedisSearch）、確認命令相容度
3. 沒有對應的評估改 module-free 設計（JSON 操作拉回 application 層）或留在 Redis Inc 商業版
4. 對應 Valkey 相容性 deep article 的三層相容邊界

Case 3：以為換 Valkey 解決了記憶體 / fork 問題

徵兆：因為 Redis 的 OOM 或 fork 延遲尖峰而遷 Valkey，遷完發現同樣問題還在。

根因：Valkey fork 自 Redis 7.2.4，繼承了完全相同的記憶體模型、eviction 演算法、AOF/RDB fork 機制。這些行為在 Valkey 上一模一樣——遷移沒有改變它們。

修法：

1. 記憶體 / fork 調校在 Valkey 上跟 Redis 完全相同，直接套用 Redis 記憶體調校 與 persistence / fork latency
2. 遷 Valkey 的理由應是授權合規 / 多執行緒吞吐 / managed 成本，不是記憶體問題
3. fork 尖峰要根治走 DragonflyDB 的 fork-less，不是換 Valkey
4. 遷移前釐清痛點是授權（Valkey 解）還是架構（Valkey 不解）

Case 4：授權合規驗證沒做完整、合規卡關

徵兆：技術遷移完成、但法務 / 合規 review 要求證明「不再使用 RSALv2 / SSPL 授權的軟體」，缺少證據。

根因：這個遷移的 driver 是授權合規，但團隊只做了技術 cutover、沒收集合規證據。Redis 的 binary / image / 相依套件若還殘留在某些環境，合規目標沒真正達成。

修法：

1. 盤點所有環境（dev / staging / prod / CI）的 Redis binary / image / 相依，確認全部換成 Valkey
2. 收集合規證據：image SBOM、套件清單、部署 manifest 顯示 Valkey BSD 授權
3. 把「不再使用非 OSI 授權 cache」寫成可驗證的 CI 檢查（掃 image / 依賴）
4. 依 migration 方法論 的合規驅動漏類，audit 重點就是 evidence collection

Case 5：監控 dashboard 部分指標斷掉

徵兆：cutover 後 RedisInsight 或某監控 dashboard 部分面板空白、vendor-specific 命令回錯。

根因：RedisInsight 等 Redis Inc 工具有部分偏商業版的命令，Valkey 不一定實作。核心指標通用，但進階面板可能缺。

修法：

1. 監控改用通用工具：valkey-cli INFO、Prometheus + redis_exporter（相容 Valkey）、Grafana
2. 核心指標（used_memory / keyspace_hits / connected_clients）在 Valkey 完全相容、覆蓋不受影響
3. 把監控相容性納入 cutover 前驗證、不要遷完才發現面板空白
4. RedisInsight 連 Valkey 多數仍可用、只是部分 vendor 進階面板缺

Capacity / cost 對照

判讀：合規敏感（公部門 / 企業 OSI 政策）或想降 managed 成本 → 遷 Valkey（drop-in、風險集中在 module / 7.4+ 盤點）；重度依賴 Redis Stack 商業 module → 留 Redis Inc 商業版。

整合 / 下一步

跟 ElastiCache for Valkey 對位

AWS 已把 ElastiCache default engine 設為 Valkey（約低 Redis 20%）。自管 Redis → ElastiCache for Valkey 是「換授權 + 轉 managed」一次到位，但要同時處理 managed 責任邊界（failover / cluster mode / client 重連）。

跟 client / 監控整合

client library 零改（透過 redis_version 協商）；監控把 exporter 指向 Valkey 即可（redis_exporter 相容）、RedisInsight 部分面板需換通用工具。

跟 Valkey 8 多執行緒對位

遷移後可評估開 Valkey 8 的 io-threads 榨多核吞吐（Redis 7.2.4 沒有的能力），見 Valkey 相容性與 io-threads deep article。

下一步議題

• 反向遷移（Valkey → Redis）：僅在重度依賴 Redis 7.4+ 功能或 Stack 商業 module 時需要、同樣 drop-in
• 跨雲 managed Valkey：GCP Memorystore / Azure Cache 的 Valkey 支援陸續推出、評估 vendor boundary
• 授權合規 CI 化：把「不使用非 OSI 授權 cache」寫成持續檢查

相關連結

• Source vendor：Redis
• Target vendor：Valkey
• 平行 migration playbook：Redis → DragonflyDB（重寫型 drop-in）、Redis → Memcached
• Methodology：Migration playbook methodology（Type B drop-in + 合規驅動漏類）

本文是 Valkey overview 的 implementation-layer deep article。選型層（為何 fork、授權治理、何時選 Valkey）見 overview；本文只處理「決定用 Valkey 後，相容性怎麼驗、執行緒怎麼調」。命令實機驗證於 valkey/valkey:8 image（valkey_version 8.1.8）、最後檢查日 2026-06-16；效能數字以 valkey.io 官方 benchmark 為準。

「100% 相容」要能驗證才敢切

Valkey 從 Redis 7.2.4 fork、宣稱 100% API 相容、drop-in 替換——這對選型是好消息，對上線前的工程師卻是一個需要證據的斷言。把 production 的 Redis 換成 Valkey，最怕的不是「大部分指令能跑」，而是某個邊角行為、某個 client library 的版本協商、某個 module 沒有對應 fork，在切換後才浮現。相容性不能靠信任，要靠驗證。

驗證的起點是一個容易被忽略的細節：Valkey 的 INFO server 同時回報兩個版本號。

1docker exec valkey valkey-cli INFO server | grep -E "redis_version|valkey_version|server_name"
2# redis_version:7.2.4    ← client library 以此協商相容行為
3# server_name:valkey
4# valkey_version:8.1.8   ← Valkey 自身的演進線

這個雙版本回報就是相容性的機制本身：client library 看到 redis_version:7.2.4，就以 Redis 7.2.4 的協定與行為運作，完全不知道背後是 Valkey；valkey_version 才是 Valkey 自己的版本，記錄它在 fork 之後加了什麼（例如 8.x 的多執行緒）。理解這條雙線——「對外裝成 Redis 7.2.4、對內持續演進」——是判斷相容性邊界的鑰匙。

對大規模生產驗證，Tinder 的配對引擎是現成的證據：4700 萬月活、每次滑動讀多個 cache、sub-millisecond 延遲，跑在 Amazon ElastiCache for Valkey 上——這個規模的服務跑在 Valkey 上，本身就是相容性的背書。另一個訊號是 AWS 在 2024 把 ElastiCache 的 default engine 從 Redis 改成 Valkey（AWS 宣稱成本較 Redis OSS 低約 20%、以 ElastiCache 定價 為準、最後檢查日 2026-06-16）。這些都是外部背書，但各服務有自己的 client library、module 與邊角用法，仍需自行驗證。

核心概念：相容性的三層邊界

「100% 相容」在不同層次有不同的精確度，驗證要分三層做。

協定與核心指令層：完全相容。string / hash / list / set / sorted set / stream / hyperloglog / geo 的所有指令、TTL / eviction / persistence / pub-sub / transaction、RESP 協定——這層是 fork 自 Redis 7.2.4 的部分，行為一致。所有標準 Redis client library 透過 redis_version 協商，直接連、不改 code。

檔案格式層：相容。RDB 與 AOF 的檔案格式跟 Redis 7.2.4 一致，可以直接把 Redis 的資料目錄拷給 Valkey 載入——這是 drop-in 遷移的基礎，不需要 dump / reload。

生態與新功能層：要逐項確認。Redis 7.4+ 在 fork 之後新增的功能（Valkey 不一定跟進）、Redis Stack 的商業 module（RedisJSON / RedisSearch，Valkey 有自己的 valkey-search / valkey-bloom 但不是同一套）、偏 Redis Inc 的監控工具（RedisInsight 部分 vendor-specific 命令）——這層是相容性的真實風險所在，驗證要集中在這裡。

驗證的操作順序：先確認 client library 連得上且核心指令正常（第一層），再確認資料能載入（第二層），最後盤點你實際用到的 module 與 7.4+ 功能（第三層）。前兩層幾乎必過，工夫花在第三層。

配置：io-threads 多執行緒調校

Valkey 跟 Redis 7.2.4 拉開的第一個實質技術差異是執行緒模型。Redis 的命令處理是單執行緒（I/O threads 只分擔 socket 讀寫，命令仍在主執行緒），Valkey 8.x 把更多 I/O 路徑非同步化，在多核機器上能讓單實例吞吐明顯高於 Redis——具體倍數依 workload 與核數而定，以 valkey.io 官方 benchmark 為準，這裡不複述未經自己壓測的數字。

執行緒由 io-threads 控制，預設 1（單執行緒，跟 Redis 行為一致）：

1# 確認目前執行緒數（預設 1）
2valkey-cli CONFIG GET io-threads
3# 1) "io-threads"
4# 2) "1"
5
6# 調高 I/O 執行緒數（建議不超過機器實體核數、留核給其他進程）
7# redis.conf / valkey.conf:
8#   io-threads 4

調校判讀：

• io-threads 是啟動參數，多數版本需要重啟生效（不是所有 CONFIG SET 都能熱套），改 conf 後 rolling restart
• 設定值對齊機器核數但留 headroom，例如 8 核機器設 4-6，不要設滿
• 單核或低核機器設 1（預設）即可，多執行緒在核數不足時沒有收益反而增加切換開銷
• I/O 密集（大量小命令、高連線數）的 workload 收益最明顯；CPU 密集的重命令（大 Lua、大 collection 操作）收益有限

調完用實際 workload 壓測驗證，不要假設「開了就快」——執行緒配置的收益高度依賴 workload 形狀。

Production 故障演練

Case 1：切換後 module 指令報 unknown command

徵兆：drop-in 換成 Valkey 後核心功能正常，但某些路徑報 ERR unknown command 'JSON.SET' 或 FT.SEARCH，application 部分功能失效。

根因：用到了 Redis Stack 的商業 module（RedisJSON / RedisSearch）。這些 module 不在 fork 範圍內，Valkey 有自己的 valkey-search / valkey-bloom，但不是同一套指令、需要另外安裝。

修法：

1. 切換前用 MODULE LIST 在原 Redis 上盤點所有載入的 module
2. 逐個確認 Valkey 是否有對應替代（valkey-search 對 RedisSearch 等），確認指令相容度
3. 沒有對應的 module，評估改用 module-free 設計（例如把 JSON 操作拉回 application 層）
4. 重度依賴 Redis Stack 商業 module 的場景，相容性邊界在這裡，可能該留在 Redis Inc 商業版

Case 2：client library 太舊、協商失敗

徵兆：絕大多數 client 正常，但某個老服務的 client library 連 Valkey 報協定錯誤或行為異常。

根因：Valkey 回報 redis_version:7.2.4，client library 若太舊（不支援 Redis 7.2 對應的協定特性，例如 RESP3）會協商失敗。這不是 Valkey 的問題，是 client 本來就跟不上 Redis 7.2。

修法：

1. valkey-cli INFO server 確認回報的 redis_version，對照 client library 支援到哪個 Redis 版本
2. 升級過舊的 client library 到支援 Redis 7.2 的版本
3. 必要時 client 端強制用 RESP2（多數 library 可配置），避開 RESP3 協商
4. 這類問題在升級 Redis 7.2 時也會遇到，不是 Valkey 特有

Case 3：監控工具部分指標消失

徵兆：切換後 RedisInsight 或某監控 dashboard 部分面板空白、某些 vendor-specific 命令回錯。

根因：RedisInsight 等 Redis Inc 工具有部分偏 Redis 商業版的命令，Valkey 不一定實作。核心指標（memory / hit rate / connections）通用，但 vendor-specific 的進階面板可能缺。

修法：

1. 監控改用通用工具：valkey-cli INFO、Prometheus + redis_exporter（相容 Valkey）、Grafana
2. 核心指標（used_memory / keyspace_hits / connected_clients）在 Valkey 完全相容，監控覆蓋不受影響
3. 把監控的相容性納入切換前驗證清單，不要切換後才發現面板空白
4. 對應 記憶體 與 連線 調校用到的 INFO 指標，這些在 Valkey 都通用

Case 4：io-threads 開太多、效能反而下降

徵兆：把 io-threads 從 1 調到 16 想榨效能，結果延遲不降反升、CPU 使用率異常。

根因：io-threads 設成超過機器實體核數，執行緒互搶 CPU、context switch 開銷超過平行收益。或 workload 是 CPU 密集（重命令），I/O 多執行緒對它沒幫助。

修法：

1. io-threads 不超過實體核數，留 headroom 給 OS 與其他進程（8 核設 4-6）
2. 用實際 workload 壓測對比不同 io-threads 值的延遲與吞吐，不要憑感覺調滿
3. CPU 密集 workload 收益有限，問題可能在命令本身太重（大 collection / 大 Lua），先優化命令
4. 多執行緒解的是 I/O 平行度，不是單命令執行速度，分清楚瓶頸在哪

Case 5：以為換 Valkey 就解決了 Redis 的記憶體 / fork 問題

徵兆：因為 Redis 的 fork 延遲尖峰或記憶體 OOM 而切到 Valkey，切完發現同樣的尖峰與 OOM 還在。

根因：Valkey fork 自 Redis 7.2.4，繼承了 Redis 的記憶體模型、eviction 演算法、AOF/RDB fork 機制。這些行為在 Valkey 上完全一致——Valkey 的差異在執行緒與授權，不在記憶體與持久化架構。

修法：

1. 記憶體 / 淘汰 / fork 的調校在 Valkey 上跟 Redis 完全一樣，直接套用 Redis 記憶體調校 與 persistence / fork latency
2. fork 尖峰是 Redis 系列的共同架構限制，要根治走 DragonflyDB 的 fork-less 機制，不是換 Valkey
3. 切換 Valkey 的理由應該是授權合規、多執行緒吞吐或 managed 成本，不是記憶體問題
4. 切換前釐清痛點：是授權 / 成本（Valkey 解）還是記憶體 / fork 架構（Valkey 不解）

Capacity / cost 邊界

Valkey 的容量判讀，多數沿用 Redis（同源），差異集中在執行緒與授權成本：

撞牆後的路由判斷：

• 記憶體 / fork 是瓶頸：Valkey 同源、不解這層，走 DragonflyDB（fork-less + 更省記憶體）或 Redis 系列的 Cluster 分片。
• 需要 Redis Stack 商業 module：Valkey 的 valkey-search / valkey-bloom 覆蓋不到全部，重度依賴走 Redis Inc 商業版。
• 不想自管：ElastiCache for Valkey 是 AWS 的 default engine，managed failover / snapshot / patching 全託管，成本比 ElastiCache for Redis 低約 20%。

整合 / 下一步

Valkey 的 deep article 大量複用 Redis 的調校知識（同源），它自己的獨特性在相容性驗證、執行緒與授權：

• 跟 Redis 全系列 deep article：記憶體、持久化、Sentinel、連線的調校在 Valkey 上完全一致，Valkey 不重寫這些，直接套用。
• 跟 ElastiCache for Valkey：managed Valkey 把執行緒與 failover 託管，省掉自管的調校與演練。
• 跟 Tinder 的 ElastiCache for Valkey 案例：4700 萬月活的 sub-millisecond 配對引擎是相容性與規模化的生產證據，但 module / client 的相容性仍需逐案驗證。
• 跟 DragonflyDB：兩者都打「Redis 相容 + 更好的執行緒」，但 Valkey 是 fork（同源、最高相容），DragonflyDB 是 C++ 重寫（相容核心但架構不同），選型差異在相容度 vs 架構激進度。

相關連結

• 上游 vendor 頁：Valkey
• 同源 deep article：Redis 記憶體與淘汰調校、persistence 與 fork latency
• 平行 vendor：AWS ElastiCache（default engine 即 Valkey）、DragonflyDB
• Methodology：Vendor 深度技術文章寫作方法論

本文是跨 vendor migration playbook、cross-link 到 AWS ElastiCache（source）跟 Redis / Valkey（target）。跑 6 維 diff dimension audit 後判定為 Type C operational redesign hybrid：engine 層相容（Low）但 operational model 差異大（IAM auth → password/ACL、CloudWatch → 自管監控、auto failover → Sentinel/自建 HA）。

為什麼從 managed 遷出

ElastiCache 遷出的 driver 通常不是 engine 層問題 — 它跑的就是 Redis 或 Valkey。常見遷出原因：

• 成本：managed premium 在大規模（數百 GB、多叢集）下比自管 + 運維人力更貴，尤其跨帳戶大量叢集時
• 跨雲或混合雲：業務需要在 GCP、Azure 或 on-prem 同時運行 cache 層，ElastiCache 只在 AWS
• 功能限制：ElastiCache 不支援所有 Redis module（RediSearch、RedisJSON 等），或 Valkey 8.x 新功能 ElastiCache 尚未上線
• 控制權：自管可以自訂 redis.conf、自選 kernel 參數、自決 upgrade 時機

資料搬遷用 RDB export + import 就完成，真正的工程量在 operational model 重建 — ElastiCache 幫你管的 HA、monitoring、backup、security，遷出後全要自建。

6 維 diff dimension audit

Operational model 是 High — 這是 Type C 的判定依據。遷移重心在重建 ElastiCache 幫你做的那些事。

階段一：盤點 ElastiCache 依賴

在動手之前，先列出 ElastiCache 幫你管的所有東西，每一項都要在自管環境重建或決定不要。

認證與網路

• IAM auth：ElastiCache 支援 IAM auth token（短效 token），自管 Redis 改用 requirepass 或 Redis 6+ ACL
• VPC / Security Group：自管 Redis 仍需 VPC 隔離，但 security group 規則要自己維護
• TLS：ElastiCache 原生 in-transit encryption，自管要自己配 redis TLS 憑證

高可用

• Auto failover：ElastiCache 自動偵測 primary failure 並 promote replica。自管用 Sentinel HA failover 或 Redis Cluster 內建 failover
• Cross-AZ replication：ElastiCache 自動跨 AZ。自管要自己在不同 AZ 部署 replica

監控與備份

• CloudWatch metrics：ElastiCache 自動發 CurrConnections、CacheHitRate、ReplicationLag 等。自管用 INFO 指令 + Prometheus redis_exporter
• Snapshot：ElastiCache 自動 daily snapshot + 手動 snapshot。自管用 BGSAVE + cron + 外部 storage

跨 region replication

• Global Datastore：ElastiCache 支援跨 region active-passive replication。自管 Redis 沒有原生跨 region replication — 若目前使用 Global Datastore，遷出前需要決定是用 application-level replication、第三方工具（Redis Enterprise Active-Active）還是放棄跨 region cache 同步

升級與維護

• Engine 升級：ElastiCache 在維護窗口自動或手動升級。自管要自己做 rolling upgrade
• Patch：安全 patch 由 AWS 負責。自管要自己追蹤 CVE

階段二：建立自管環境

部署架構

最小 production 架構：1 primary + 1 replica + 3 Sentinel（或 Redis Cluster 3 primary + 3 replica）。

1# Docker Compose 驗證用（production 用 VM 或 K8s）
2# Primary
3docker run -d --name redis-primary -p 6379:6379 redis:7 \
4  redis-server --requirepass "$REDIS_PASSWORD" --appendonly yes
5
6# Replica
7docker run -d --name redis-replica -p 6380:6379 redis:7 \
8  redis-server --replicaof redis-primary 6379 \
9  --masterauth "$REDIS_PASSWORD" --requirepass "$REDIS_PASSWORD"

Sentinel 或 Redis Cluster 配置見 Sentinel HA Failover。

監控重建

ElastiCache CloudWatch metrics 對應的自管替代：

用 Prometheus redis_exporter 自動採集，接 Grafana dashboard。

Backup 重建

1# cron job: 每日 BGSAVE + 等完成 + 上傳 S3
2# LASTSAVE 回傳 Unix timestamp，BGSAVE 完成後 LASTSAVE 會更新
30 3 * * * BEFORE=$(redis-cli -a "$REDIS_PASSWORD" LASTSAVE) && \
4  redis-cli -a "$REDIS_PASSWORD" BGSAVE && \
5  while [ "$(redis-cli -a "$REDIS_PASSWORD" LASTSAVE)" = "$BEFORE" ]; do sleep 5; done && \
6  aws s3 cp /data/dump.rdb s3://backup-bucket/redis/$(date +\%Y\%m\%d).rdb

Production 建議搭配 persistence fork latency 的監控，確認 BGSAVE 的 fork 不會造成延遲 spike。

階段三：資料搬遷與切換

搬遷策略

ElastiCache 的資料搬遷有兩條路：

RDB export + import（適合 downtime 可接受的場景）：

1. ElastiCache 建立手動 snapshot
2. 把 snapshot export 到 S3（ElastiCache console → Export snapshot）
3. 下載 RDB 檔，放到自管 Redis 的資料目錄
4. 重啟自管 Redis 載入 RDB

雙寫期間遷移（適合零停機需求）：

1. Application 同時寫 ElastiCache 和自管 Redis（雙寫）
2. 讀取仍走 ElastiCache
3. 監控自管 Redis 的資料量與命中率追上後，切讀取到自管
4. 移除 ElastiCache 寫入
5. 下線 ElastiCache

雙寫的複雜度高於 RDB export。Cache 資料可重建的特性讓第一種策略在多數場景夠用 — 短暫 cache miss 的代價是回源到 DB，通常可接受。

Endpoint 切換

Application 用 endpoint 連 ElastiCache。切換時：

1. 把 application config 的 Redis host 改為自管 Redis endpoint
2. 確認 TLS 與認證方式對齊（IAM token → password/ACL）
3. Rolling restart application
4. 監控 cache hit rate 與 latency 回到 baseline

如果用 DNS CNAME 間接指向 ElastiCache endpoint，可以直接改 CNAME 指向自管 Redis，application 不用改 config。

階段四：驗證與回退

驗證清單

回退路徑

Cache 遷移的回退比 DB 遷移簡單 — cache 資料可重建。回退步驟：

1. Application config 改回 ElastiCache endpoint（或 CNAME 指回）
2. Rolling restart
3. Cache miss 回源到 DB，自然 warm up

ElastiCache 在遷移期間不要下線，保留 7-14 天作為回退保險。確認自管 Redis 穩定運行後再刪除 ElastiCache cluster。

成本對照

小規模（< 50 GB、< 5 cluster）通常 ElastiCache 的 managed premium 比自管人力便宜。Compute 跟 HA 的差額在小規模可忽略，但監控跟 backup 的自建成本是固定開銷 — 即使只管一個 cluster，redis_exporter + Prometheus + cron backup 的設定跟維護都要做。大規模（數百 GB、多叢集）或跨雲場景下，managed premium 累積到 cluster 數 × node 數的倍數，自管的邊際成本反而更低，遷出 ROI 才成立。

交接路由

• Source vendor overview：AWS ElastiCache
• Target vendor 操作：Redis Sentinel HA、Redis Cluster Resharding
• 監控重建：Redis Memory Eviction Tuning、Redis Persistence Fork Latency
• 反向路徑：Redis → ElastiCache

本文是跨 vendor migration playbook、cross-link 到 Redis（source）跟 DragonflyDB（target）。跟前一篇 Splunk → Elastic Security 的 6-phase playbook 對照、Redis → DragonflyDB 是 drop-in 相容 形態的 migration、結構更接近 vendor deep article methodology 的 6-section flow + 一段「相容性驗證」前置。

為什麼遷：cost / single-thread / multi-tenancy 三條 driver

反向 driver（DragonflyDB → Redis）也存在 — 主要是 Redis Modules 依賴（RedisJSON / RedisSearch / RedisGraph）DragonflyDB 不支援、或 Lua script 用了 redis.call 進階 API。

跟 phased migration 的對照：drop-in 不需要 phased

跟前一篇 Splunk → Elastic 的 6-phase playbook 不同、Redis → DragonflyDB 的 migration 結構接近 standard deep article：

判斷依據：migration 結構由 source 跟 target 的 schema / protocol 差異程度 決定、不是 universal phased playbook。本批第 2 篇驗證 deep article methodology 的 6-section 框架 在 drop-in migration 仍適用（只需前置 相容性驗證 段、其他 6 段對位）。

相容性驗證：在 cutover 前要確認的清單

DragonflyDB 號稱 Redis drop-in、但「drop-in」涵蓋範圍依 Redis feature 使用程度而定。Pre-migration 必跑的相容性 audit：

Audit 的關鍵 output：列「不相容功能」清單 + 對應 application code 修改範圍；若 Modules 在 production 使用、migration 退役。

Step-by-step cutover

 1# 1. 部署 DragonflyDB
 2docker run -d --name dragonfly -p 6380:6379 \
 3  -v /data/dragonfly:/data \
 4  docker.dragonflydb.io/dragonflydb/dragonfly:latest \
 5  --logtostderr --requirepass=<your_password>
 6
 7# 2. Redis 端 BGSAVE
 8redis-cli -h redis-primary BGSAVE
 9# 等到 BGSAVE 完成
10redis-cli -h redis-primary INFO Persistence | grep rdb_last_save_time
11
12# 3. 把 dump.rdb 拷到 DragonflyDB
13scp redis-primary:/var/lib/redis/dump.rdb dragonfly-host:/data/dragonfly/
14
15# 4. 重啟 DragonflyDB 載入 RDB
16docker restart dragonfly
17
18# 5. 驗證資料一致
19redis-cli -h dragonfly-host -p 6380 DBSIZE
20redis-cli -h redis-primary DBSIZE
21# 兩端 key 數對齊
22
23# 6. Dual-write 1-7 天（application 同時寫兩端）
24# 7. Read 切換到 DragonflyDB、Redis 端只寫不讀
25# 8. Write 切換、Redis 端 standby
26# 9. 觀察 1-2 週、無異常後 Redis decommission

關鍵時間點：

• BGSAVE → load：100GB RDB 約 5-15 分鐘、跨網路 SCP 時間另算
• Dual-write window：1-7 天觀察、application 寫兩端、read 仍走 Redis
• Cutover：read switch → write switch、每步間隔 24 小時
• Decom：Redis 保留 standby 1-2 週、無異常後關閉

Production 故障演練

Case 1：RDB 版本差，DragonflyDB load 失敗

徵兆：Redis 7.2 端 BGSAVE 出的 dump.rdb 在 DragonflyDB load 時報 Unsupported RDB version、DragonflyDB 啟動失敗。

根因：Redis 7.2 RDB version 11 含新 feature（function library / sharded pubsub）DragonflyDB 當前 release 沒支援；版本相容性需逐 release 確認。

修法：

1. Pre-migration 版本相容矩陣 audit：DragonflyDB release note 對照 Redis version、確認 RDB version 支援
2. 降級 BGSAVE：Redis 端設 rdb-version 9（Redis 6.x 兼容版本）、犧牲 Redis 7.x 新 feature
3. 替代方案：用 redis-cli --scan + MIGRATE 命令 incremental 搬、不用 RDB；速度慢 100x 但相容性好

Case 2：Lua script 跑進 EVAL 不一致

徵兆：dual-write 階段、發現某些 EVAL script 在 Redis 跟 DragonflyDB 結果不同；具體是某個 redis.call("OBJECT", "ENCODING", key) 在 DragonflyDB 回不一樣的 encoding 字串。

根因：DragonflyDB 內部不用 Redis 的 ziplist / listpack encoding（dashtable 不需要）、OBJECT ENCODING 返回值不對等；script 邏輯依賴 encoding 來決定行為、結果不同。

修法：

1. Audit Lua script：grep 所有 redis.call("OBJECT"、列出依賴 encoding 的 script
2. 改寫 application：不依賴 encoding、改用 MEMORY USAGE 或 high-level check
3. 接受差異：DragonflyDB 不會回 encoding 但 functional 結果對等、SOC review 確認可接受

Case 3：Pub/Sub fanout 高負載 latency

徵兆：production 切到 DragonflyDB 後、Pub/Sub 訂閱端 latency p99 從 5ms 漲到 20-50ms；topic fanout >10K subscriber 場景。

根因：DragonflyDB 多 thread 設計、Pub/Sub message 在 thread 間 dispatch 需要 routing；Redis single-thread 沒這個 overhead。高 fanout 是 DragonflyDB 設計取捨。

修法：

1. 架構：高 fanout Pub/Sub 不用 DragonflyDB、改 NATS / Redis Streams + consumer group
2. DragonflyDB 配置調整：--proactor_threads 對 Pub/Sub 影響大、調到符合 CPU 核心數
3. 接受 latency：< 10K subscriber 差異可忽略、不必動

Case 4：Cluster mode 看似相容但 slot routing 行為差

徵兆：application 用 Redis Cluster client（lettuce / Jedis cluster mode）連 DragonflyDB emulated cluster、運行幾天後 MOVED redirect 異常、key 找不到。

根因：DragonflyDB emulated cluster mode 是 single node 模擬、CLUSTER SLOTS 返回固定 mapping；某些 client 端 cluster topology cache 跟實際 routing 不對齊、發 redirect。

修法：

1. Application 改 standalone client：DragonflyDB single node 已能達 cluster 級 throughput、不必用 cluster client
2. Client config：lettuce 端 clusterTopologyRefreshOptions(...) 設較長 refresh、減少 redirect 機會
3. 長期：等 DragonflyDB cluster 正式 GA 後再評估

Case 5：Modules 用了沒注意，migration 卡住

徵兆：cutover 後幾天、application 某個功能完全壞、log 顯示 ERR unknown command 'JSON.SET'；DragonflyDB 不支援 RedisJSON。

根因：Pre-migration audit 漏掉 application 用了 RedisJSON（透過某 client library 抽象）；DragonflyDB 不支援該 Module 命令、application 直接壞。