Redis 在 2024 年 3 月把授權從 BSD 改成 SSPL + RSALv2，等於把雲端服務商和部分商業使用者擋在門外。一個月後，Linux Foundation 就集結了 AWS、Google Cloud、Oracle 等主要雲端供應商，推出 Valkey 作為 BSD 授權的社群分支。到了 2026 年中，Valkey 已經推進到 9.1 版，不只是 Redis 的替代品——它在效能和功能上都已經走出自己的路線。
授權風波的來龍去脈
Redis Labs（後改名 Redis Inc.）的授權異動早有跡可循。2018 年先把部分模組改為 Commons Clause，2019 年再換成 RSAL，到了 2024 年索性把核心引擎也一併改成 SSPL + RSALv2 雙授權。OSI（Open Source Initiative）不承認 SSPL 為開源授權，這代表任何需要在合規框架內運作的組織，都無法再將 Redis 視為開源軟體使用。
社群反應極其迅速。Valkey 從 Redis 7.2.4 分支出來，在短短幾週內就累積超過 150 位貢獻者和上千個 commit。到 2024 年底的調查顯示，83% 的大型企業已經在生產環境中採用 Valkey 或正在測試。Aiven 在幾個月內就把數千台 Redis 伺服器遷移到 Valkey。
Redis Inc. 在 2025 年 5 月試圖補救，跟著 Redis 8.0 加入 AGPLv3 作為第三授權選項。但傷害已經造成——核心貢獻者永久遷移到 Valkey，主要雲端供應商的託管服務全部轉向 Valkey，回頭的機率極低。
Valkey 9.x 帶來的技術跳躍
Valkey 不只是換個名字繼續跑。9.0 和 9.1 兩個版本累積了大量工程投入，以下是幾個值得注意的改進。
Pipeline 記憶體預取與零拷貝回應：9.0 針對管線化工作負載做了記憶體預取最佳化，吞吐量提升最高達 40%。零拷貝回應機制則帶來額外 20% 的效能增長。對大量使用 pipeline 的應用場景——像是批量寫入日誌或即時分析——這兩項改進直接反映在延遲數字上。
原子化 Slot 遷移：過去 Redis Cluster 的 slot 遷移是逐 key 進行的，碰到大型集合就容易卡住，客戶端還得處理部分遷移狀態的重試邏輯。Valkey 9.0 改成以 AOF 格式整個 slot 原子搬移，遷移期間不再出現中間狀態。
Hash Field 獨立過期：新增 HEXPIRE、HPERSIST、HTTL 等指令，讓 hash 內的個別欄位可以設定獨立的 TTL。以前要做到這件事得拆成多個 key 再配合命名規則管理，現在一個 hash 就搞定。這對 session 管理、使用者偏好快取這類場景特別實用。
Cluster 模式支援編號資料庫：Redis Cluster 從設計之初就只允許 db 0，要從 standalone 模式搬到 cluster 得先把所有 SELECT 呼叫拿掉。Valkey 9.0 拿掉了這個限制，cluster 模式下可以直接使用編號資料庫，大幅降低遷移門檻。
記憶體用量下降：9.1 版重新設計了內部資料儲存結構，常見工作負載的每 key 記憶體用量減少約 10%。聽起來不多，但在百萬、千萬 key 的規模下，省下來的記憶體非常可觀。
模組生態系不再被授權綁架
Redis Inc. 過去把 RediSearch、RedisJSON、RedisBloom、RedisTimeSeries 等模組鎖在自家授權下，社群版使用者只能看得到吃不到。Valkey 9.0 推出了 Valkey Bundle，以 BSD 授權提供 JSON、Bloom Filter 和搜尋模組（含向量搜尋）。
Valkey Search 在 1.2 版更進一步加入了全文檢索和聚合查詢功能，支援數值篩選、標籤查找和向量相似度搜尋。對需要在快取層同時處理搜尋需求的架構來說，這代表可以少架一套 Elasticsearch 或 MeiliSearch。
不過要注意的是，時序資料（Time Series）模組目前還沒有完整的 Valkey 對應方案。如果生產環境重度依賴 RedisTimeSeries，遷移前需要評估是否改用 InfluxDB、QuestDB 等專門的時序資料庫。
用 Docker Compose 部署 Valkey
單機部署 Valkey 非常直觀。以下是一個適合生產環境的 Docker Compose 設定：
1 | services: |
幾個設定值得說明：
--appendonly yes啟用 AOF 持久化，確保重啟後資料不遺失。如果對持久化需求不高（純快取場景），可以關掉以換取寫入效能。--maxmemory和--maxmemory-policy控制記憶體上限和淘汰策略。allkeys-lru適合快取場景；如果是當作主資料庫用，改成noeviction避免資料被靜默刪除。- port binding 限制在
127.0.0.1，避免直接暴露到公網。如果需要遠端存取，透過 WireGuard 或 SSH tunnel 比開放防火牆安全得多。
用 docker compose up -d 啟動後，可以用 valkey-cli 驗證連線：
1 | docker exec -e VALKEYCLI_AUTH=YOUR_STRONG_PASSWORD -it valkey valkey-cli ping |
從 Redis 搬到 Valkey 的實務路徑
Valkey 跟 Redis OSS 7.2 維持完整的協定相容性——RESP2、RESP3 協定一致，RDB 和 AOF 檔案格式可以直接互通，指令集完全相同。這代表應用程式端通常不需要改任何一行程式碼，連線字串換掉就完事。
搬遷的實際步驟：
盤點模組依賴：在每台 Redis primary 上執行 MODULE LIST，確認是否使用了 RediSearch、RedisJSON、RedisBloom、RedisTimeSeries 等模組。前三者有 Valkey Bundle 的 BSD 替代品，RedisTimeSeries 則需要另外規劃。
匯出資料：用 redis-cli --rdb dump.rdb 匯出完整的 RDB 快照，或者直接複製 AOF 檔案。Valkey 可以直接載入這些檔案。
部署 Valkey 並載入資料：把匯出的 RDB 或 AOF 檔案放到 Valkey 的資料目錄，啟動 Valkey 即可自動載入。
切換應用程式連線：大多數 Redis 客戶端函式庫（ioredis、redis-py、Jedis、go-redis）不需要更換，只需要把連線位址指向新的 Valkey 實例。部分函式庫已經直接更名或新增了 Valkey 專屬的 client（例如 valkey-py），但 Redis 版本的 client 同樣能正常連線。
驗證功能：重點檢查 Lua script、MULTI/EXEC 交易、Pub/Sub 訂閱和 Cluster 的 failover 行為。這些在協定層面完全相容，但複雜的使用場景值得跑一輪整合測試。
如果是 Cluster 部署，遷移時需要額外注意 slot 分配和節點拓撲。建議先建立一組新的 Valkey Cluster，透過應用層的雙寫（dual-write）策略逐步切換，而不是嘗試就地升級。
什麼情況下該留在 Redis
Valkey 不是在所有場景都優於 Redis。如果已經在使用 Redis Stack（含 RedisTimeSeries、RedisGraph）的完整功能，且這些模組目前在 Valkey 生態系中還沒有成熟的替代品，那麼留在 Redis 並接受 AGPLv3 授權可能是比較務實的選擇。
另外，如果團隊依賴 Redis Inc. 的商業支援和 SLA，Valkey 目前的支援管道主要來自社群和雲端供應商的託管服務，不提供直接的廠商支援合約。
但對大多數使用場景——快取、session store、訊息佇列、排行榜、速率限制——Valkey 已經是更好的選擇。BSD 授權沒有法律灰色地帶，Linux Foundation 的中立治理確保不會再出現單一廠商說改授權就改授權的風險，效能表現也已經超越 Redis OSS。
一個值得長期投入的方向
Valkey 從倉促分支到站穩腳步只花了不到兩年。9.1 版有超過 80 位開發者參與，AWS ElastiCache、Google Cloud Memorystore、Oracle OCI Cache 都已經提供託管服務，生態系的成熟度已經不是實驗性專案的等級。
對於正在評估快取或 in-memory 資料儲存方案的技術團隊，Valkey 是目前最穩健的開源選項——不用擔心授權突然變卦，不用擔心功能被鎖進付費版，社群的開發速度也沒有放緩的跡象。
需要一台穩定的 VPS 來部署 Valkey？NCSE Network 提供搭載 Intel Xeon Gold CPU 和 NVMe SSD 的臺灣本地 VPS 主機，是方電訊機房直連，適合對延遲敏感的快取服務部署。前往 ncse.tw 了解方案細節。
