InfoQ 中文 · 2026/10/22 15:33:35
Valkey 8.x 发布：单进程吞吐破百万，Rust 统一客户端底座
Redis 分叉项目 Valkey 在 8.x 版本中通过异步 I/O 线程将单进程吞吐量提升至约 100 万 QPS，并引入内存优化与双通道复制。该项目由 AWS、Apple 等 8 家公司共同治理，正逐步摆脱纯缓存定位，向更通用的基础设施演进。
报道全文原始报道全文
Valkey 作为 Redis 分叉项目，已形成跨企业协作的治理结构，并在 8.x 系列中实现关键性能与运维能力升级。
异步 I/O 线程支持运行时动态调优，单进程吞吐量提升至约 100 万 QPS；引入键嵌入与每槽位字典优化内存占用；TSC 由 8 家公司代表组成，体现多厂商共建模式。
适合后端工程师、SRE/运维工程师、开源基础设施架构师阅读。
从 Redis 分叉两年多后，Valkey 看起来仍是一个年轻但不断成长的项目，并希望获得更大的发展势头。该项目拥有 12 名维护者和 9 名技术指导委员会成员，他们来自 8 家公司，包括 Ericsson、AWS、Apple 和 Percona；项目还举办了多场社区会议，参与者最多达到 100 人。在 Open Source Summit Europe 期间，InfoQ 与该项目的两位早期开发者进行了交流，进一步了解项目的演进与未来。
InfoQ：感谢你们抽出时间回答读者的问题。先请二位介绍一下自己。
Madelyn Olson：我是 Madelyn Olson，在许可证变更后参与创建了这个分叉项目。我就职于 AWS，并担任 Valkey 技术指导委员会（TSC）成员。在 Valkey 之前，我也是 Redis 的 Committer。 Viktor Söderqvist：我是 Viktor Söderqvist，在 Ericsson 从事开源工作，也参与了这个分叉项目的创建。
InfoQ：8.x 系列版本在技术上带来了哪些变化？
Olson：这一系列版本的主题是基础设施建设。异步 I/O 线程将单个进程的吞吐量从每秒约 20 万至 25 万个请求提升到约 100 万个。与此前的 I/O 线程机制不同，现在可以在运行时修改线程配置，使运维人员能够增加核心来应对突发工作负载。8.0 和 8.1 版本还引入了与键嵌入和每槽位字典有关的内存效率优化。 双通道复制缓解了副本同步期间主节点承受的压力。此前，系统会先发送数据集的完整副本，再发送后续的复制变更流，二者按顺序传输。改为并行发送后，可以降低这一过程带来的内存压力。
InfoQ：为什么版本 9 的集群变更很重要？
Olson：集群模式按照槽位在节点之间分配键，但迁移到集群模式此前存在两项重大限制。跨槽位操作要求数据位于同一个分片上，而且集群模式过去不支持编号数据库，而编号数据库是单实例部署中可用的命名空间。加入编号数据库后，消除了部分用户无法迁移到集群模式的一个原因。 原子槽位迁移解决了另一个问题：逐个键迁移数据时，如果操作失败，集群可能处于只完成部分迁移的状态。新方法会预先准备数据，然后再完成切换，因此迁移要么整体生效，要么完全不生效。版本 9 还引入了哈希字段过期功能，它被称为该项目呼声最高的功能之一。受访者以 Mastodon 式部署——多个服务器共用一个集群——为例，说明用户对这些集群变更的需求，同时提醒不要将这种部署方式视为强多租户方案。
InfoQ：GLIDE 客户端库旨在解决什么问题？
Olson 和 Söderqvist：Redis 客户端最初的任务相对简单：与单个节点通信。集群拓扑、TLS、重定向、重连和连接池让客户端行为变得更加复杂，而不同语言的客户端对这些功能的实现并不一致。Glide 最初是 AWS 的一个项目，它将连接和拓扑处理放在共享的 Rust 核心中，再通过特定语言的绑定将其公开。因此，在核心中修复一个 Bug，就能同时修复所有使用该核心的绑定。 团队曾考虑过 WebAssembly，但当时认为采用这种方式还为时过早。Glide 的目的并不是淘汰原生替代方案：对于现有客户端已经能够满足需求的用户，Valkey 仍会继续支持包括 Go 实现在内的其他客户端。
InfoQ：哪些方向可以让 Valkey 超越目前的缓存应用场景？
Olson 和 Söderqvist：一个被提出的方向是同步复制，目标是为并非仅仅是临时性的数据提供持久性保证。另一个方向是分层存储：将热数据保留在内存中，同时把冷数据迁移到 SSD 或其他存储介质。 Olson：分层存储可能需要不止一种策略。体积较小且访问频率较低的键可以移出 DRAM；足够大的对象则可以保留在磁盘上，并直接以流式方式传输到网络。团队正在考虑一种更通用的接口，使其可以支持本地 NVMe 之外的后端，例如 S3 或 Postgres。讨论中认为，Parquet 可能适用于变更数据捕获或点击流输出，而不适合作为动态读取和重写分层数据的格式。采用最终一致性的跨集群双活复制仍是一个长期设想，而不是已经承诺实现的功能。
除了功能开发，该项目也在投入发布和安全相关工作。自动化向后移植旨在缩短为不同版本准备修复所需的时间，而 AI 辅助的预审查和主动安全测试则被用于在发布前发现问题。
原文链接：