為什麼需要這個
跟 上一篇 的分工：那篇給你「工具地圖」，這篇回答「我怎麼知道自己該搬家了？」——升級快取技術的成本從來不是裝新軟體，是遷移資料、改 client、重學運維。搬早了浪費，搬晚了半夜掛。
我在電商後端遇到的幾乎都是第三種劇本：訊號早就出現了，升級案卻推不上去。下單變慢、金物流狀態更新開始不穩，大家都看得出來 DB 撐不住，升級的提案也不是沒人提——但搬家的成本就擋在那裡：要遷資料、要改 client、要排一個避開大促的時間窗，每次評估完就先擱著。最後拖到跟外部系統對接的 API 不穩、掉 log，才用最急就章的方式把 Redis 補上去。
所以我對「搬家時機」的體感是：難的從來不是看出該搬，是把搬家案推到真的執行。這也是這篇存在的理由——你需要的不是「我覺得快撐不住了」的模糊感覺，而是一張講得出口的訊號清單，拿去說服那個排優先序的人。
驅動力不是「更快」，是「撞牆的形狀」
- 每次世代交替的宣傳都是 benchmark，但真正的遷移動力從來是某個具體場景做不到——不是慢 10%，是根本做不了
- 反例（不要這樣決策）：「Redis 比 Memcached 新所以用 Redis」「DragonflyDB 快 25 倍所以升級」
- 正確的問法：我現在的痛，是下一代工具「專門解的那種痛」嗎？
為什麼資料結構才是 Redis 起飛的關鍵
- Memcached → Redis 的遷移潮，動力不是速度（兩者都是記憶體級），是排行榜 / feed / 去重這些場景在純 KV 上做不出來
- 在 app 層用 string 硬幹 sorted set 的代價：序列化開銷、race condition、code 醜到沒人想維護
- 教訓的一般化：平台級工具的勝負在「解鎖新場景」，不在「同場景快一點」
這條規律我認為成立，但我的親身經歷替它補了一個殘酷的註腳：解鎖新場景說服得了架構圖，說服不了人。我遇過更極端的版本——瓶頸是真的踩到了、新工具也確實能解，但團隊裡的 RD 就是抵抗，最後變成我在中間 cover，cover 到心很累。所以規律的完整版也許是：平台級工具的勝負在「解鎖新場景」，但普及的速度取決於「重學成本」。Redis 能掀起 Memcached 的遷移潮，不只因為資料結構解鎖了場景，也因為它的重學成本低——client 換掉就好，指令一個下午學得完。反例是 K8s：解鎖的場景再大，重學成本讓多少團隊寧可停在 Compose。工具要同時贏兩邊，才真的推得動。
每一堵牆的「該搬訊號」清單
- DB → 加快取：DB CPU 持續高檔、讀寫比 9:1 以上、同查詢反覆執行
- Memcached/純 KV → Redis：app 層出現第二個手工序列化的資料結構 hack
- 單機 → Sentinel/Cluster：記憶體水位 > 70% 且還在長、或 failover 是「打電話叫人」
- Redis → 多執行緒實作：單核 100% 而機器其他核閒著、且 pipeline/cluster 都已用盡
四個訊號裡我親身遇過的是第一個。當時的判斷方式老實說很被動：出事了，大家打開 AWS 的 dashboard 盯著 DB 的圖，確認「喔，真的卡住了」——訊號是 AWS 幫我們畫好的，不是我們設計出來的。這件事的後座力比事件本身大：我後來花了不少時間自己整理「監控到底要看什麼」，因為那次讓我意識到這張訊號清單有一個隱藏前提——你看得見訊號。雲平台給的現成圖表只能讓你事後對答案；要在撞牆前就看見牆，得自己想清楚每一堵牆對應哪個指標、擺在哪個 dashboard 上。
下一代也會撞牆：預測練習
老實說這題我還沒研究到有把握的程度，手上只有一個真實的觀察：在雲端服務商上用 Redis 存資料，帳單其實不便宜——記憶體本來就是最貴的儲存，managed 服務再往上疊一層溢價。
從這個觀察往下推，我的暫定猜測是：多執行緒世代解掉的是 CPU 的牆，但完全沒動到成本結構——資料還是全量住在 RAM 裡。量繼續長上去，下一堵牆撞的不會是效能，是帳單。到時候的解法大概率是分層儲存：熱資料留 RAM、冷資料下沉 SSD——但工具一旦這樣做，它就越來越像一顆 DB，繞回 上一篇 結尾講的「快取與 DB 邊界模糊化」。預測練習的誠實版結尾：這段是推測不是研究結論，等我把這塊拆完會回來改——到時候對答案。
何時不適合
- 這套「撞牆判斷法」適用於平台級選型；業務層的小快取（memoize、local LRU）不需要這麼重的決策流程
- 訊號清單是經驗法則不是 SLA——你的量級可能讓某些牆永遠不會出現