"Redis"
- 2.2 cache aside 與失效策略
整理 read-through 思路、cache miss 與 invalidation
- 2.8 Cache Data Shape 與 Access Pattern
說明 cache value、key space、資料結構與存取型態如何反映服務語意。
- 2.9 Cache Migration 與 Stampede Rollback（實作示範）
以商品詳情與價格快取示範 cache migration 如何交付 evidence package、release gate 與 incident decision log。
- 2.10 Pub/Sub 與即時 fan-out
說明 Redis Pub/Sub 的即時廣播責任、at-most-once 邊界，以及何時升級到 Streams 或正式 message queue
- 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 對齊
- Rate Limit 實作
單機 middleware / Redis 分散式限速 / 配額設計 — 概念見 DevOps 流量管控，本章聚焦後端實作
- 2.11 Redis data types 實作
說明 sorted set、bitmap、HyperLogLog、counter 與 hash 各自承擔的服務語意、容量行為與原子性邊界
- 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 個把『最容易的遷移』寫成事故的踩坑
- 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 踩坑
- 終端機訊息佇列客戶端：Kafka 的 kaskade/yozefu/ktea 與 Redis 的 iredis
在純文字終端機連 broker、瀏覽 topic、消費訊息、檢視 consumer 狀態的客戶端：Kafka 的全螢幕 TUI（kaskade/yozefu/ktea）、Redis 的增強型 REPL（iredis），以及訊息佇列 TUI 多半綁單一 broker 協議這個跟 SQL 客戶端最大的不同。