"Cache"
- 2.C1 Meta：Cache Consistency 升級
快取 invalidation 一致性如何從常見錯誤演進到高可信治理。
- 2.1 高併發下的 Redis 讀寫邊界
說明高併發服務如何共用 Redis client、控制 pipeline 與避免 cache stampede
- 2.C2 Meta：mcrouter 與跨區快取路由
快取從單點最佳化演進到分散式路由層的案例。
- 2.2 cache aside 與失效策略
整理 read-through 思路、cache miss 與 invalidation
- 2.C3 Shopify：快取序列化格式遷移
快取 payload 從 Marshal 轉 MessagePack 的遷移策略。
- 2.3 TTL 與 eviction
整理過期策略、容量控制與熱點資料
- 2.C4 Meta：CacheLib / Kangaroo 分層快取
快取從 DRAM-only 轉向分層快取架構的實務案例。
- 2.4 distributed lock 與租約
整理鎖語意、租約風險與適用場景
- 2.C5 Shopify：Write-through Cache 在高讀流量的實作
read-heavy 服務如何轉向 write-through 快取模型。
- 2.5 presence store 與即時狀態
整理線上狀態、跨節點查詢與過期清理
- 9.C6 Tinder：ElastiCache for Valkey 撐 4700 萬月活的配對引擎
Tinder 用 Amazon ElastiCache for Valkey 提供配對引擎所需的次毫秒延遲快取層
- 2.C6 Netflix：EVCache 全域快取層
快取從本地層演進為跨區分散式能力的案例。
- 2.6 快取威脅建模（Threat Modeling）
從快取污染、一致性偏移與流量放大風險，盤點 cache/redis 的主要弱點
- 2.7 Cache Copy Boundary 與 Freshness
說明快取何時只是可重建副本，何時會影響交易、權限或配額正確性。
- 2.C7 Cloudflare：Cache Reserve 分層儲存快取
邊緣快取延伸到持久層以降低回源壓力的案例。
- 2.8 Cache Data Shape 與 Access Pattern
說明 cache value、key space、資料結構與存取型態如何反映服務語意。
- 2.C8 Meta：TAO 社交圖快取演進
社交圖查詢在規模化下如何把快取做成資料層能力。
- 2.9 Cache Migration 與 Stampede Rollback（實作示範）
以商品詳情與價格快取示範 cache migration 如何交付 evidence package、release gate 與 incident decision log。
- 2.C9 反例：快取切換引發 Stampede 回歸
快取策略切換若缺乏保護，會導致回源壓力與錯誤率連鎖上升。
- 2.10 Pub/Sub 與即時 fan-out
說明 Redis Pub/Sub 的即時廣播責任、at-most-once 邊界，以及何時升級到 Streams 或正式 message queue
- 2.C10 對照：規模差異下的快取策略
同一快取策略在小中大型服務下會產生不同風險。
- DragonflyDB → Redis / Valkey：回退到標準生態的遷移路徑
從 DragonflyDB 遷回 Redis 或 Valkey，處理 snapshotting → RDB/AOF 差異、HA 架構切換與 Cluster mode 重建的階段化流程
- KeyDB → Redis / Valkey：從多線程 fork 回歸主線的遷移路徑
從 KeyDB 遷回 Redis 或 Valkey，處理 active-active replication 拆除、多線程 → 單線程效能差異、FLASH storage 移除與 Sentinel/Cluster 對齊
- 2.11 Redis data types 實作
說明 sorted set、bitmap、HyperLogLog、counter 與 hash 各自承擔的服務語意、容量行為與原子性邊界
- AWS ElastiCache 的責任邊界：managed 接手了什麼、又默默留下什麼
ElastiCache 把 failover、patching、snapshot、跨 AZ 複製接走，但 cache stampede、client 重連、key 設計、eviction policy 還是你的事。本文用 shared responsibility 拆解 managed 的真實邊界、展開 engine 選擇與 cluster mode 配置、5 個把『以為 AWS 全包』寫成事故的 production 踩坑，以及 ElastiCache 到 MemoryDB 的 durability 邊界
- Caffeine + Redis 兩層 cache：搭起來很容易，跨實例失效才是全部的問題
L1 Caffeine（process-local）+ L2 Redis（共享）的兩層 cache 程式碼三十行就寫完，但每個 JVM 實例有自己的 L1 副本、一個實例更新不會通知其他實例——跨實例 invalidation 才是這個架構的全部難度。本文展開兩層讀寫路徑、用 Redis pub/sub 廣播失效、5 個把 L1 stale 與 GC 寫成事故的 production 踩坑，以及哪些資料適合放 L1
- DragonflyDB shared-nothing 多核架構：用 scale-up 取代 Redis Cluster
Redis 要靠 Cluster 分片才能用滿一台多核機器，DragonflyDB 賭的是相反方向——單一進程 thread-per-core、shared-nothing、把單機推到 Redis 要好幾個 shard 才達到的規模。本文展開 thread-per-core 與 dashtable 的架構、fork-less snapshot、5 個把架構假設寫成 production 事故的踩坑，以及 scale-up 撞牆該回 Cluster 的邊界
- KeyDB active-active 多主複製：last-write-wins 會默默吃掉哪一筆寫入
KeyDB 的 active-active 讓兩個 master 都能寫、互相同步，聽起來解決了跨區寫入的所有問題——直到兩邊同時寫同一個 key，last-write-wins 默默丟掉其中一筆。本文展開 active-active 的複製機制與衝突語意、實機驗證雙向同步、5 個把多主複製寫成資料遺失與迴圈的 production 踩坑，以及哪些資料能放 active-active、哪些不能的邊界
- Memcached slab allocator 與記憶體經濟學：明明有記憶體卻在 evict
Memcached 用 slab allocator 預切記憶體成固定大小的 chunk，這讓它永不碎片化、卻會在還有大量空閒記憶體時就開始淘汰——slab calcification。本文展開 slab class、growth_factor、page 分配的會計模型、5 個把 slab 機制寫成記憶體浪費與淘汰事故的 production 踩坑，以及純 KV 邊界與多執行緒擴展的判讀
- Redis → Valkey：同一份程式碼、不同授權的 drop-in 遷移
Valkey 是 Redis 7.2.4 的 fork，bit-for-bit 幾乎同源、RDB/AOF 檔案相容、client 一行不改——這是技術上最容易的 cache 遷移。真正的工作不在搬資料，在授權合規驗證與 fork 後分歧（Redis 7.4+ 功能、Stack 商業 module）的盤點。本文走 Type B drop-in、相容性 audit 前置、5 個把『最容易的遷移』寫成事故的踩坑
- Valkey 相容性驗證與 io-threads 調校：drop-in 切換與多執行緒的實機判讀
Valkey 跟 Redis 100% 相容這句話要怎麼驗證、切換才敢上線。本文用 INFO server 的雙版本回報拆解相容性的真實邊界、展開 Valkey 8 的 io-threads 多執行緒調校、5 個把 drop-in 切換或執行緒配置寫成事故的 production 踩坑，以及相容性撞牆該怎麼判斷的邊界
- ElastiCache → 自管 Redis / Valkey：脫離 managed 的遷移路徑
從 AWS ElastiCache 遷移到自管 Redis 或 Valkey，處理 RDB export、DNS 切換、IAM 認證移除與監控重建的階段化流程
- Redis → DragonflyDB：drop-in 相容下的容量躍升 + 5 個踩雷
DragonflyDB 號稱 Redis drop-in 替代、單機 throughput 25x、記憶體效率 30% 提升；遷移流程簡單但有 5 個 production 踩雷（RDB 版本差 / Lua 腳本不全支援 / Pub-Sub fanout 行為差異 / Cluster mode 兼容度 / Modules 不支援）、跟 Sentinel / Cluster 模式對位
- Redis → Memcached：Memcached 不是 simpler Redis、是 cache paradigm
Redis → Memcached 是 Type E paradigm reduction migration — 從 multi-paradigm（KV + 資料結構 + pub/sub + Lua + streams）退到 pure cache；不是「remove Redis features」、是「重新分配 Redis-specific feature 到對應 specialized 服務」；5 個 production 踩雷 + paradigm reduction 路線
- Redis Cluster Re-sharding：source = target，但 topology 重劃的 5 段流程
Redis cluster re-sharding 是 5 type migration 漏類實證 — source / target 同 cluster、無 schema / paradigm 差、但 16384 slot 重分配是核心；本文涵蓋 4 種 re-sharding driver、slot migration 機制、redis-cli --cluster rebalance / reshard 工具、5 個 production 踩雷（cluster busy / replica lag / client cache stale / cross-slot transaction / monitor gap）
- Redis 記憶體與淘汰調校：maxmemory-policy、LFU 與碎片化的實戰判讀
Redis 的記憶體是一條會在半夜爆掉的曲線：maxmemory 設多少、policy 選 LRU 還 LFU、碎片化什麼時候開始吃掉 30% RAM、OOM 時 noeviction 怎麼讓寫入全部失敗。本文展開 Redis 記憶體會計模型、eviction policy 的選型判讀、5 個把記憶體配置寫成 production 事故的踩坑，以及單機記憶體撞牆後該往 cluster 還是 DragonflyDB 走的邊界
- Redis 持久化與 fork latency：AOF、RDB 與那一次卡住整個 cluster 的 fork
Redis 的 RDB save 與 AOF rewrite 都靠一次 fork()，而 fork 在大記憶體實例上會凍結主執行緒數百毫秒、複製分頁讓記憶體逼近翻倍。本文展開 AOF / RDB 的機制與 fsync 取捨、copy-on-write 的記憶體放大、5 個把持久化寫成延遲尖峰與資料遺失的 production 踩坑，以及 cache 場景到底要不要持久化的邊界
- Redis Sentinel 與 failover 時序：從 master 死掉到 client 重連的每一段
Redis Sentinel 的 failover 不是一個瞬間動作，是 down 偵測 → quorum 確認 → 選主 → 提升 → 配置廣播 → client 重連的一條時序鏈，每一段都有自己的延遲與失敗模式。本文展開 Sentinel 的判定模型與這條時序、5 個讓 failover 卡住或丟資料的 production 踩坑，以及 Sentinel 撐不住該往 Cluster 或 managed 走的邊界
- Redis 連線與 pipeline：RTT 稅、連線池與一次往返打包多命令
Redis 單命令通常微秒級執行，但 application 端量到的延遲是毫秒級——差距全在網路往返（RTT）。pipelining 的本質不是『批次發命令』，是把 N 次 RTT 壓成 1 次。本文展開 RTT 會計、連線池配置、pipeline 與 MULTI 的差異、5 個把連線與往返寫成延遲與正確性問題的 production 踩坑，以及連線模型撞牆的邊界
- Memcached → Redis：不搬資料、搬存取層的能力升級遷移
Memcached → Redis 跟一般 migration 最大的不同：cache 是可重建的，所以這個遷移不搬資料、讓新 cache 重新 warm 就好，真正的工作在存取層（client、協定）跟可選的能力升級（data types）。本文跑 6 維 diff audit、用兩階段（drop-in pure KV → 採用 data types）結構、5 個把『outgrew pure KV』寫成事故的踩坑
- 自管 Redis / Valkey → AWS ElastiCache：engine 不變、變的是誰運維
自管 Redis/Valkey 遷到 ElastiCache 的特殊之處：engine 沒變（Redis 還是 Redis）、data model 沒變、API 沒變——變的只有運維責任歸屬。本文跑 6 維 diff audit 對映 Type C operational hybrid、展開 VPC/安全/cutover 的實際工作、以及『把 failover/patching 交出去、同時交出哪些控制權』的責任邊界，5 個 production 踩坑
- 9.C25 Tubi：從 ScyllaDB 遷到 ElastiCache、ML feature store 達 sub-10ms p99
Tubi 把 ML 推薦的 feature store 從 ScyllaDB 遷到 ElastiCache for Redis、99 百分位延遲降到 10ms 以下
- MongoDB Connection Management and Cache Layer：driver × 部署模型 × cache × predictive scaling
MongoDB 大規模 OLTP 撞牆不是單一 driver 議題、是 driver × 部署模型 × cache × scaling trigger 三層協作；含 Coinbase mongobetween / freshness token / ML 預測擴容三件套 + 適用範圍紀律
- 9.C35 Snap：GCP + KeyDB 在 multi-cloud 架構下的低延遲快取
Snap 用 GCP 上的 KeyDB cluster 減少跨 cloud cache 延遲、用 TPU 訓練廣告推薦模型
- DynamoDB DAX 快取策略：cluster 架構、item/query cache、write-through 與 invalidation 邊界
DAX 不是「加上去就變快」的開關；本文展開 DAX cluster 架構、item cache vs query cache 兩種快取、write-through 一致性語意、query cache 只靠 TTL 失效的陷阱，以及 strongly consistent read 繞過 cache 的邊界，含 Lemino 讀峰值補位 case fact 與 gsi-lsi-design 的 SSoT 切分