從 Redis 分叉之後：Valkey 的專案現況
Valkey 是在 Redis 授權條款變更後從 Redis 分叉出來的開源專案，至今已超過兩年。根據 InfoQ 在 Open Source Summit Europe 期間的訪談，這個專案目前有十二位 maintainer 與九位技術指導委員會（Technical Steering Committee，TSC）成員，分布在八家公司，包括 Ericsson、AWS、Apple 與 Percona。社區會議參與人數可達一百人。受訪者是兩位最初參與分叉的開發者：任職於 AWS 的 Madelyn Olson，她也是 Valkey TSC 成員與前 Redis committer；以及任職於 Ericsson 的 Viktor Söderqvist。兩人分別從版本功能、客戶端策略與未來方向說明專案演進。
8.x 版本：吞吐量、記憶體效率與複製機制
8.x 系列的主題是底層基礎設施。最明顯的變化是非同步 I/O 執行緒（async I/O threading），讓單一進程的吞吐量從每秒約二十萬至二十五萬次請求，提升到約一百萬次。與舊有的 I/O 執行緒安排不同，執行緒配置可在執行時變更，操作者可增加核心來應付突發工作負載。8.0 與 8.1 也包含記憶體效率工作，涉及 key embedding 與 per-slot dictionary。雙通道複製（dual-channel replication）則處理副本同步期間主節點的壓力：過去完整資料集副本與後續複製變更串流是依序傳送，改為並行傳送後，可降低該過程的記憶體壓力。
9 版本：叢集模式的限制補齊與原子槽遷移
叢集模式把鍵依 slot 分散到不同節點，但過去有兩項明顯限制。第一，跨 slot 操作要求資料位於同一 shard。第二，叢集模式不支援編號資料庫（numbered databases），也就是單實例部署中可用的命名空間。加入編號資料庫後，消除了部分使用者無法遷移到叢集模式的一個原因。原子槽遷移（atomic slot migration）則解決另一個問題：逐鍵搬移資料若中途失敗，可能讓叢集停留在部分遷移狀態；新做法會預先暫存資料再切換，使遷移要麼生效、要麼不生效。版本 9 也引入 hash-field expiration，這是專案最受請求的功能之一。受訪者以 Mastodon 風格部署、也就是多台伺服器共用一個叢集為例，說明叢集變更的需求，但也提醒不要把這種安排視為強多租戶（strong multi-tenancy）。
GLIDE：把連線與拓撲處理收斂到共享核心
GLIDE 客戶端函式庫要解決的是客戶端行為日趨複雜的問題。Redis 客戶端最初任務相對單純：與單一節點通訊。但叢集拓撲、TLS、重定向、重新連線與連線池等機制，讓客戶端行為變得複雜，且不同語言的客戶端實作這些功能時並不一致。Glide 最初是 AWS 的專案，把連線與拓撲處理放進共享的 Rust 核心，再透過各語言的綁定對外提供。如此一來，在核心修復的錯誤，可同時對所有使用該核心的綁定生效。團隊曾考慮 WebAssembly，但當時判斷這個做法還太早。Glide 並不打算消滅原生替代方案：Valkey 仍支援其他客戶端，包括 Go 實作，以滿足需求已被現有方案滿足的使用者。
從快取走向持久性與分層儲存
Valkey 目前的典型用途仍是快取，但受訪者提出幾個可能讓它超越既有場景的方向。一個是同步複製（synchronous replication），目標是為非單純暫時性的資料提供持久性保證。另一個是分層（tiering）：把熱資料留在記憶體，較冷的資料移到 SSD 或其他儲存。Olson 指出，分層可能需要不只一種策略。體積小且不常存取的鍵可移出 DRAM；足夠大的物件則可能留在磁碟上，直接串流到網路。團隊正在考慮更通用的介面，以支援本地 NVMe 以外的後端，例如 S3 或 Postgres。Parquet 曾被討論，可能對變更資料擷取（change-data-capture）或點擊流（clickstream）輸出有用，而不是作為動態讀取與重寫分層資料的格式。跨叢集主動-主動複製（active-active replication）搭配最終一致性，仍是較長期的想法，並非已承諾的實作。
除了功能，專案也投入發布與安全工作。自動回移（automated backporting）旨在縮短跨版本準備修復所需時間；AI 輔助預審與主動安全測試則用於在發布前找出問題。
影響、實務意義與限制
這些演進顯示 Valkey 正試圖從 Redis 的替代品轉向更完整的資料基礎設施。8.x 的吞吐量提升與執行時執行緒調整，對需要應付突發流量的線上服務有直接助益；雙通道複製與記憶體效率工作則關係到副本同步期間的穩定性與資源使用。9 版本的編號資料庫與原子槽遷移，降低叢集模式的採用門檻，尤其對原本因跨 slot 或遷移風險而卻步的部署。hash-field expiration 則回應長期需求，讓單一雜湊結構內的欄位可以獨立過期。
GLIDE 的策略意義在於一致性。當客戶端功能由多語言各自實作時，修補與行為差異會成為維運負擔；把拓撲與連線邏輯集中到 Rust 核心，可讓修正一次到位。不過，這並不代表生態系會收斂到單一客戶端，原生與其他語言實作仍會並存。
分層儲存與同步複製則觸及更根本的定位問題。若 Valkey 要承載非暫時性資料，持久性保證與儲存成本之間的取捨就會成為核心設計議題。分層若能支援 S3 或 Postgres 等後端，將牽動資料格式、延遲與一致性模型；Parquet 在此被定位為輸出格式而非分層資料的動態格式，也顯示團隊對不同工作負載的區分。跨叢集主動-主動複製仍在概念階段，短期內不應視為可用承諾。至於以單一叢集服務多個應用程式的做法，受訪者明確提醒那不等同強多租戶，意味著隔離與資源控制仍需另外設計。
整體而言，Valkey 的發展路徑反映出開源資料基礎設施在分叉後，必須同時處理效能、相容性、治理與安全。十二位 maintainer 與九位 TSC 成員分散在八家公司，說明專案已不是單一廠商主導，但也意味著方向取捨需要更多協調。8.x 與 9 的功能已落地，GLIDE 與分層儲存則處於推進或評估階段；同步複製與跨叢集主動-主動複製屬於更長期構想。對使用者和維運者而言，理解哪些是已可用功能、哪些仍是方向，比單看版本號更重要。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。