2026 年 10 月 26 日，Valkey 发布 9.1.3。对缓存与键值存储团队，这条版本信息的价值不只在补丁本身，而在于它再次确认了 Valkey 的性能路线：把 I/O 线程模型重写，用单机吞吐换取更低的每请求成本。
9.1.3 与同一窗口的维护版本
按 Valkey 官方发布页，9.1.3 于 2026 年 10 月 26 日发布；同一窗口还发布了 9.0.7（10 月 27 日）、8.1.11、8.0.12 与 7.2.15。多条维护线同时获得更新，说明项目仍在对旧版本提供缺陷与安全修复。9.1 线最初于 2026 年 5 月 19 日发布，9.2.0-rc1 已在 9 月 16 日进入候选阶段；对生产团队，9.1.3 是当前稳定线的最新补丁，9.2 则仍在预览。
性能口径：210 万请求/秒
Valkey 项目首页以 9.1 线为口径给出“单机 210 万请求/秒”，并把原因归于重新设计的 I/O 线程模型。这个数字应被理解为特定硬件、特定命令组合与特定客户端并发下的基准结果，而不是任意业务负载的承诺。它真正的含义是：在多核服务器上，Valkey 试图让网络 I/O 与命令执行更好地并行，减少单线程事件循环成为瓶颈的概率。对高并发、低延迟的缓存场景，这比单纯增加客户端连接更有意义。
按数据库粒度的 ACL
9.1 线还提供按数据库粒度的访问控制：通过 ACL 中的 db= 限定用户只能访问指定编号数据库。过去，ACL 主要控制命令与键模式，多租户或共享实例中“同一用户能碰所有库”的问题需要靠部署隔离解决。按库授权让团队可以在一个实例内做更细的权限分层，例如让报表服务只读某个库、让会话服务只写另一个库。对托管服务与内部多团队共享的缓存集群，这是一条实用的隔离手段。
需要提醒的是，逻辑数据库隔离并不等于资源隔离。同一个实例内的库仍共享内存、CPU 与网络；一个库的热键或大 value 仍可能影响其他库。权限收窄能降低误操作与越权读取风险，但不能替代容量规划与实例拆分。
KV 缓存案例：25% 更多请求
Valkey 博客在 10 月 20 日给出一个与 AI 推理相关的案例：把 KV 缓存放到 Valkey 后，同样的两台 GPU 节点服务了多 25% 的请求，回复流式输出速度提升一倍。其逻辑是 GPU 不必在每次请求时重新读取已经处理过的上下文，缓存层承担了重复上下文的重用。这个案例说明 Valkey 的竞争点正在从“替代 Redis 的缓存”扩展到“AI 推理栈的状态层”。
对工程团队，这类收益需要用端到端指标验证：首 token 延迟、每请求 GPU 时间、缓存命中率、内存占用与网络往返。只比较缓存层 QPS 会漏掉真正的成本项。若缓存未命中导致 GPU 重复计算，单机吞吐再高也不能转化为服务能力。
与 Redis 的关系
Valkey 起源于 2024 年 Redis 许可变更后的社区分支，坚持 BSD 许可，并由 Linux Foundation 支持。Redis 后来在 Redis 8 中重新提供 AGPLv3 选项，并把部分原 Stack 模块并入核心，因此两者不是简单的“开源与闭源”对立，而是许可与治理模式不同。对采用方，选择时应核对：客户端兼容性、模块需求、托管服务支持、许可义务与社区活跃度。Valkey 的多条维护线与按月节奏，是判断其可持续性的一个正面信号。
升级建议
先在预发环境把 9.1.3 与当前版本做对照，重点观察 I/O 线程配置、连接数、延迟分位数与内存碎片；检查 ACL 是否使用了 db= 规则，确认客户端连接时选择的数据库与授权一致；对使用集群模式的环境，核对槽位迁移与故障转移流程；把 9.2 的候选版本当作观察项，不纳入近期生产计划。升级前保留回滚包与配置快照，避免把补丁升级变成不可逆变更。
小结
Valkey 9.1.3 于 2026 年 10 月 26 日发布，以单机 210 万请求/秒的 9.1 线性能口径、重写的 I/O 线程模型、db= 按库 ACL 与 KV 缓存提升 25% 请求量的案例为看点，是缓存数据库在性能、权限与 AI 推理场景上的一次持续演进。