InfoQ

Olson and Söderqvist Discuss Valkey’s Evolution and Future Past Caching Use Cases at OSS EU

6.9内容质量
Olson and Söderqvist Discuss Valkey’s Evolution and Future Past Caching Use Cases at OSS EU

TL;DR · AI 摘要

Olson and Söderqvist Discuss Valkey’s Evolution and Future Past Caching Use Cases at OSS EU - InfoQ InfoQ Homepage News...

核心要点

  • 主题聚焦：Olson and Söderqvist Discuss Valkey’s Evolution
  • 来源：InfoQ，建议结合原文判断细节。
  • AI 分析暂不可用，本条为保底评分与摘要。
#AI#编程#前端#后端#安全
打开原文

Olson 和 Söderqvist 在 OSS EU 上讨论 Valkey 的演变及未来：超越缓存用例 - InfoQ

InfoQ 首页 News Olson 和 Söderqvist 在 OSS EU 上讨论 Valkey 的演变及未来：超越缓存用例

开发

InfoQ 认证高绩效团队计划（在线，11 月 17 日）：为您的团队构建更清晰的运营模型。

Olson 和 Söderqvist 在 OSS EU 上讨论 Valkey 的演变及未来：超越缓存用例

2026年10月9日 3分钟阅读

by

  • Olimpiu Pop

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备播放

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

  • 阅读列表

在从 Redis 分叉超过两年后，Valkey 看起来像是一个年轻但正在成长的项目，旨在获得更多动力。目前有十二位维护者和九位技术指导委员会成员，分布在八家公司（包括 Ericsson、AWS、Apple 和 Percona），并且有多个社区会议参与人数达到一百人。在 Open Source Summit Europe 上，InfoQ 与两位初始开发者进行了交流，以了解该项目的演变和未来方向。

InfoQ：感谢您抽出时间回答我们读者的问题。首先请介绍一下自己。

Olson：我是 Madelyn Olson，我在许可证变更后帮助创建了这个分叉。我在 AWS 工作，并担任 Valkey 技术指导委员会（TSC）成员。在 Valkey 之前，我也是 Redis 的提交者。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辅助预审和主动安全测试则用于在发布前识别问题。

  • 相关赞助商 2026年10月29日，美国东部时间下午1点 从令牌到功能：为AI辅助工程构建成本归属架构 主讲人：Martin Reynolds - Harness首席技术官

InfoQ电子报

每周二发送的InfoQ上周内容摘要。加入超过25万名资深开发者的社区。查看示例

我们保护您的隐私。