LinuxDo 新帖推送

标题: 【国内信息差】And【吃瓜吃瓜】Redis Vs Valkey ，Redis还能继续用吗？！
作者: #秋明
板块: #开发调优
编号: 1355602
帖子: https://linux.do/t/topic/1355602
时间: 2025-12-24 09:54:00
摘要:
原文

  
    
    
    
      【国内信息差】龙头企业已换成ValKey了，你还在傻呵呵用Redis？！ 
  

开发调优
    
  
  
    Redis 风险评估与 Valkey 替代方案

这是为公司写的文档，因为这个信息差我在众多社区没有看到，担心部分佬友也不清楚，一起分享一下新信息。 
。 
国内的字节，阿里云，腾讯云等龙头企业都已经在逐步替换为ValKey 
而且 ValKey更像一个 “升级版真正开源的Redis” ，同时有多个龙头企业 贡献代码，性能这块甚至更强悍 


二编： 感谢各位大佬们一起讨论，让大家对于这个话题的了…
  


新编

前言： 这是为公司写的文档，因为最近（12月）字节和腾讯云将Redis替换为Valkey了 ，这个信息我在众多社区没有看到，担心部分佬友也不清楚，一起分享一下新信息以及原因。
感谢各位大佬们一起讨论，让大家对于这个话题的了解深度更上一层楼

Redis 风险评估与 Valkey 替代方案（更新版）

核心结论（先看结论）：

对绝大多数企业来说——只要不是云厂商、也不是把 Redis 当成对外售卖的 SaaS 服务，当前的 Redis 8.x 仍然可以放心使用。 作为内部业务组件做缓存/会话/分布式锁，不修改源码，许可证不会强制要求开源你的业务系统。
选型上可以简单理解为：

小 KV 基础缓存 + 低并发 + 单实例：优先选 Redis（升级到修复安全漏洞的稳定版本（即8.x版本）。
大 Key 较多 + 高并发（≥ 50 万 QPS）+ 集群规模大：更推荐 Valkey 8.x，性能、稳定性与成本综合优势明显。





一、背景与更新原因

早期版本的报告更偏重“Redis 风险”，在许可证和漏洞层面给出了较为保守的结论。
随着 Redis 8.x 采用三重许可证（AGPLv3 / RSALv2 / SSPLv1），以及社区对条款的实务解读逐渐清晰，现在可以更准确地划定风险边界：


除非你是云厂商 / 把 Redis 打包成收费服务卖给第三方，或大量修改 Redis 源码并以“在线服务”形式对外提供，否则正常使用基本不受限制。


同时，Valkey 生态在近一年快速成熟，性能和兼容性数据也更加充分，需要更新“Redis vs Valkey”的对比与选型建议。


二、Redis 8.x 许可证现状：三重许可证与实际影响
Redis 8.x（2025 年 5 月发布）采用 AGPLv3 / RSALv2 / SSPLv1 三重许可证 模式，用户可以在三者之间选择其一来合规使用。
2.1 三种许可证的核心差异（结合我们的典型用法）




许可证
对“企业内部使用 + 商业缓存”的影响
主要限制关注点




AGPLv3
完全可用，不修改源码时几乎无约束
仅当修改 Redis 源码并通过网络对外提供服务时，才需开源修改部分源码


RSALv2
完全可用，适合企业内部系统
禁止将 Redis 直接作为收费的托管服务 / 缓存服务对外提供


SSPLv1
完全可用，不修改源码时约束有限
若修改源码并对外提供服务，需要开源包括管理层在内的相关代码




对于我们这类 “应用系统” ，Redis 只是系统中的一个组件：

不单独对外售卖 Redis 托管服务。
通常也 不会大幅修改 Redis 源码。

在这种典型场景下，Redis 8.x 的许可证基本不会强制要求开源业务代码，可以放心使用。

2.2 “通过网络提供服务”的真实含义
以 AGPLv3 为例：“通过网络提供服务”指：

把修改过源码的 Redis 部署在服务器上，外部用户直接通过网络使用“这个被你修改过的 Redis 服务本身”。

而我们常见的情况是：

业务系统使用 原版 Redis 二进制或官方容器镜像 作为缓存 / 会话 / 锁组件；
对外提供的是“堆场系统 / 业务系统”的 API，而不是“Redis 访问服务”；

这与“运营一个 Redis 云服务平台”有本质区别。因此：

在不修改 Redis 源码的前提下，我们只要遵守基础条款（保留版权声明等），就可以在商业项目中安心使用 Redis。


三、安全风险：漏洞存在，但可通过“升级 + 运维治理”可控
Redis 近几年确实暴露了一些高危漏洞，但关键在于：

漏洞是否有修复版本可用？
我们是否能在可接受时间内完成升级与验证？

3.1 高危漏洞示例


CVE-2025-62507（CVSS 8.8，高危）

多 ID 场景下，XACKDEL 实现存在 栈缓冲区溢出 风险，在一定条件下可能被利用实现远程代码执行（RCE）。
受影响版本：Redis 8.2.0 及以上；8.2.3 已修复。
临时缓解手段：使用 ACL 禁用 / 限制相关命令。



CVE-2025-48367（CVSS 7.5）

在特定配置下，未认证连接 可以构造重复协议错误，让客户端陷入“饥饿”状态，导致 DoS 风险（服务不可用、请求超时）。
修复版本（NVD 公布）：8.0.3 / 7.4.5 / 7.2.10 / 6.2.19。



历史典型漏洞（已修复）：

Lua 脚本引擎 Use-After-Free（潜伏约 13 年，CVSS 10.0），在未做好认证的公开实例上，攻击者可远程执行任意代码。



3.2 对我们的实际影响与建议
影响本质在于“升级能力”，而不是“用不用 Redis”：

Redis 作为“公共枢纽”（缓存 / 会话 / 锁 / 消息），一旦被打挂或被入侵，影响会波及多个业务模块；
但这些漏洞都有已发布的修复版本，只要：

建立起 版本跟踪与定期升级机制；
避免将 Redis 暴露在公网或不可信网络环境；
开启并收紧认证与 ACL，按“最小权限”使用命令；



就可以把绝大部分安全风险控制在合理范围内。

因此，从安全角度看，Redis 仍然是可控的，不存在“必须抛弃 Redis 才安全”的结论，更多是对运维治理能力的要求。


四、Redis vs Valkey：性能与特性对比（综合最新评测）
基于近期 8.x 版本的实测数据（统一使用如 AWS c7g.4xlarge、redis-benchmark 和 memtier_benchmark 等工具），可得到较清晰的性能轮廓。
4.1 基础性能：小 KV、普通并发场景
在 小 KV（≈1KB）、中等并发（< 10 万 QPS） 的基础缓存场景中：

Redis 8.2.3 与 Valkey 8.0.1 在 QPS 与 P99 延迟差异不大，通常在几％ 到 10％ 左右；
对业务来说，两者在“体感性能”上几乎等价。

示例数据（1KB，小 KV，读写混合）：




场景
Redis 8.2.3
Valkey 8.0.1
差异（Valkey vs Redis）




1KB KV 100% 读
QPS：112 万，P99：0.9ms
QPS：119 万，P99：0.8ms
QPS ↑ 6.2%，延迟 ↓ 11.1%


1KB KV 7:3 读写混合
QPS：106 万，P99：1.0ms
QPS：113 万，P99：0.9ms
QPS ↑ 6.6%，延迟 ↓ 10%




结论： 对于“普通业务低并发 / 单实例缓存”而言，选择 Redis 还是 Valkey，在性能维度上差别不构成决定性因素，更多看生态习惯与团队成熟度。

4.2 大 Key、高并发与极限负载场景
当业务出现以下特征：

大量 大 Key（10KB ~ 100KB）；
单集群或单实例需要支撑 ≥ 50 万 QPS 的高并发；
集群规模 ≥ 100 分片，对拓扑收敛时间与故障切换敏感；

Valkey 在架构与实现层面的优化会拉开与 Redis 的差距。
典型对比数据节选：


大 Key 混合读写（100KB）：

Redis：QPS ≈ 8.2 万，P99 ≈ 15.3ms；
Valkey：QPS ≈ 12.3 万，P99 ≈ 9.8ms；
QPS 提升约 50%，延迟下降约 36%。



高并发连接能力：

Redis：稳定连接数 ≈ 8 万；
Valkey：稳定连接数 ≈ 15 万；



满负载稳定性（CPU 100%）：

Redis：约 4 小时后开始出现 ~0.1% 超时；
Valkey：72 小时压测中未出现超时。



大规模集群拓扑变更收敛时间（100 分片量级）：

Redis（Gossip）：3 ~ 5 分钟；
Valkey（Raft + Gossip）：10 ~ 15 秒。




结论： 在“大 Key + 高并发 + 大集群”场景下，Valkey 在吞吐、延迟、连接数、故障恢复时间等多个指标上都明显优于 Redis 8.x。

4.3 生态与特殊能力


Redis 8.x 优势：

官方工具生态成熟，如 RedisInsight、Redis Stack 等，复杂场景排障体验更好；
一些小众 / 调试类命令兼容度更高。



Valkey 8.x 优势：

BSD 开源许可证，合规边界更简单直接；
原生支持一些面向 AI / 向量检索的能力（在某些版本或发行版中），可减少对 Redis 商业版的依赖；
在大规模集群与高并发场景下，工程化优化更
2 views01:56