為什麼需要這個
老實說，我從來沒有「選擇」過 Redis。每一份工作接手的系統裡，它都已經在那裡——設定跑著、沒人講得清楚當初為什麼是它、參數為什麼這樣調。我猜這是多數後端工程師的真實處境：你不是選型者，是繼承者。
而繼承者比選型者更需要這張演進地圖。因為你遲早要回答兩個選型者不用面對的問題：這套接手的設定，當初是在解什麼牆？我現在撞的牆，還是同一堵嗎？答不出來，你就只能在出事的時候瞎調參數，或者跟風升級到一個解不了你問題的新工具。
這篇不是編年史。快取工具的每一代，都是在前一代撞牆的地方長出來的——看懂每堵牆，你就知道自己現在撞的是哪一堵、該不該換工具。
牆 1：DB 撞 QPS 上限 → 記憶體快取誕生（Memcached，2003）
- 場景：LiveJournal 的讀流量把 MySQL 打爆，加 replica 也追不上
- 解法本質：把「讀」搬進記憶體，DB 只扛「寫」與 miss
- Memcached 的性格：純 KV、多執行緒、slab 記憶體管理、資料不落地——它只想做好一件事
我自己撞上牆 1 的版本是電商的下單流程。某天開始下單變慢，接著訂單的金流、物流狀態更新也跟著不穩。追下去才發現：request 量上來之後，同一批資料被瘋狂讀寫，DB 卡住的影響一路往外擴散——先是我們跟其他系統對接的 API 開始不穩，最後嚴重到連 log 都掉。修法就是教科書那一招：補 Redis，把讀扛走。但那次也給我留了一個疙瘩——快取是加上去了，代價是什麼、怎麼用才是對的，當時沒人講得清楚。這個疙瘩後來變成我開專案把 Redis 從頭驗一遍的起點，也是這整個系列存在的原因。
牆 2：只能存 string → 資料結構進場（Redis，2009）
- Memcached 的極限：排行榜需要 sorted set、feed 需要 list、去重需要 set——全都得在 app 層自己序列化硬幹，又慢又醜
- Redis 帶著資料結構來，順手多了持久化（RDB/AOF）與 pub/sub
- 這一段接 Redis 資料結構：用對結構少寫五十行 code
牆 3：單機記憶體與單點 → HA 與水平切分（Sentinel / Cluster）
- 資料塞不進一台機器的記憶體、master 掛了全站冷啟動——兩個不同的痛，兩種解法
- Sentinel 解「掛了誰接手」、Cluster 解「一台裝不下」（slot 分片）
- 運維深入 ⛔️ 歸 infra I04，這裡只講「什麼訊號出現時你需要它們」
牆 4：單執行緒吃滿一顆核 → 多執行緒重寫（DragonflyDB / KeyDB，2022+）
- Redis 單執行緒模型的極限：高 QPS 下一顆 CPU 100%、其他核在旁邊看
- DragonflyDB / KeyDB 用多執行緒架構重寫、宣稱相容 Redis 協定
那大多數人需要嗎？我的暫定立場是：不需要。我沒親眼看過 Redis 單核吃滿——我看過的死法名單是 DB 先倒、然後 app 層（event loop 卡死、連線池耗盡）、再來是網路 RTT，Redis 從來沒排上過。自己在 primer 專案實測 pipeline 效能也印證同一件事：對 Redis 狂打一輪指令，時間全耗在網路來回，Redis 本體閒得很。所以在 Redis 變成你的瓶頸之前，你會先撞上三堵別的牆——牆 4 的解法是給每秒幾十萬 ops 等級的大型平台用的，不是給你我。這個立場標「暫定」，因為我正在從頭拆這套東西，等我親手把它壓到崩潰，再回來改這段。
心智模型：一張「牆與解」對照
| 撞的牆 | 解它的工具 | 你該看到的訊號 |
|---|---|---|
| DB 讀 QPS 上限 | Memcached / 任何記憶體快取 | DB CPU 高、讀寫比懸殊 |
| 資料結構需求 | Redis | app 層一堆序列化 hack |
| 單點 / 裝不下 | Sentinel / Cluster | failover 演練失敗、記憶體水位 |
| 單執行緒 CPU | DragonflyDB / KeyDB | Redis 單核吃滿而 QPS 上不去 |
下一堵牆會是什麼
我的猜測：快取與 DB 的邊界模糊化——但不是「DragonflyDB 加持久化」單一條線，而是好幾件事同時發生。持久化是一塊；app 層自己的 cache 優化是一塊；把運算結果直接轉存成靜態檔（build 時就把答案算好）又是一塊。每一塊都在把「資料的第二份」放到不同的地方，「快取」不再是機房裡那台 Redis，而是散在各層的影子資料。
所以我認為下一堵牆撞的不是某個工具的效能，是抽象層：repository pattern 裡那層 data access 到底要接什麼？以前答案很單純——接 DB，快取是前面順手擋一下的東西。現在同一個 interface 後面可能是 Redis、可能是靜態檔、可能是 process 內的記憶體，情境不同用法就不同。誰能把這坨異質的「第二份資料」收進一個講得清楚的抽象，誰就是下一代——這是我正在想、還沒有答案的題目。
何時不適合
- 這篇是「認識工具地圖」，不是選型指南——實際選型看使用情境與團隊運維能力，不是看誰最新
- 沒撞牆就不用換：絕大多數服務一台 Redis 用到退休