"Valkey"
- 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 對齊
- 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 認證移除與監控重建的階段化流程