Redis 把许可换回开源、Valkey 另起一摊：缓存这层要不要换

先把我的结论摆在前面：绝大多数在内部跑一套缓存的系统，今年不用为 Redis 这一轮许可来回折腾。 真正需要停下来看一眼的，是那些把缓存打包进交付物、或者直接以服务形式给客户用的。分界线不是版本号，也不是许可的名字，而是「你到底在不在对外交付」这一条。下面先说发生了什么（只留跟你有关的部分），再回答它对你手上那套系统意味着什么，最后给跟/不跟各自的条件。

一句前提先讲清楚：这台机器上我取不到各家原文正文，所以下面这些只按多个来源交叉印证到的事实说，细节以官方为准；而且我对许可条款的解读全是工程口径的判断，不是法律意见，落到具体项目请让法务定。

发生了什么（只留跟你有关的部分）

拆开就三件事。

• 2024 年，Redis 把许可证从原来的开源口径改成 RSALv2 + SSPLv1 双许可（两者任选其一）。这是那波「Redis 是不是不当开源用了」争论的起点，也是 Valkey 出现的原因。
• 2025 年，Redis 8.0（2025 年 5 月前后发布的那一版）在双许可之外，又把 AGPLv3 作为可选项加了进来，等于在口径上重新回到了「开源」。但要看清一点：SSPL 那条并没有放弃，它还是并列的选项之一。也就是说这一版同时给了你 AGPLv3、RSALv2、SSPLv1 几条路。
• 另一摊 Valkey：它是从 Redis 7.x 那条线分出去的项目，交给 Linux 基金会托管，几家主要云厂商在背后支持，走 BSD 系许可，并且跟 Redis 的协议和数据格式保持兼容。

能力面上还有一条会混进来的信息：公开报道里 Redis 8.x 主打的方向之一，是把向量集合塞进缓存这一层——让缓存顺手也能做向量检索。这条跟许可无关，但它会改变「要不要换」的成本账：如果你本来就打算在缓存层做点检索的活，换不换就不只是许可问题，还牵到功能取舍。这里单独提醒一句：「缓存顺手做向量检索」是一个功能决策，跟「许可换没换」是两本账，别因为看到「回到开源」这个新闻点，就顺带把一次功能升级也排进今年的变更窗口。

最该分清的一件事：自用，还是对外交付

这类许可来回，对使用方真正要紧的区分只有一个：你是在自己系统里跑一个缓存，还是把它打包交付出去、或作为服务提供给别人。 这两种形态，要看的条款根本不是一套。

我的工程理解是这样（不是法律意见）：

• BSD 系（Valkey 走的这条）：对分发基本不设什么门槛，你把带它的东西发出去，通常只要保留版权声明即可。这也是「另起一摊」在合规上最省心的一点。
• AGPL 这一类：工程上常被提到的一点是，它把「通过网络对外提供服务」也纳入考量，而不只是「发了二进制给客户」才算。至于你的形态到底算不算触发，是法务要逐条判的事，我不下结论——但如果你压根不对外提供服务，这条的适用面就窄得多。
• SSPL：常见理解是它冲着「把软件本身当作服务对外卖」去的。Redis 保留了它，所以如果你选了含 SSPL 的那条路，又正好在做「把缓存当服务交付」这类事，就得认真看一眼。

对号入座地讲：个人开发者、企业内网自部署、不上公网拿去售卖——这几类里，上面这些条款的触发面大多落在你运维边界的内侧；而把它当产品随包发给客户、或以托管形式提供给第三方，才是需要逐条去对的场景。别把后者的焦虑，套到前者身上。

给你两个够用的自查问题，不用读条款原文也能先归类：其一，客户会不会拿到一个能直接跑起来的 Redis/Valkey 实例或镜像？其二，你对外签的东西里，有没有把「提供这块缓存」本身写成一项交付内容？两问都答否，你大概率就在「内部自用」这一档；只要有一问答是，就值得把对应那一格的条款摆到法务面前让他们定，而不是自己在工程群里猜。

你的处境对应哪一条

你的处境	要不要为许可操心	先看哪一条
内部系统跑缓存，不对公网售卖	基本不用管	看运维和兼容性，别先看许可
自建平台给客户用，缓存藏在平台里不单独交付	要看一眼	你这种形态算不算「对外提供服务」
把 Redis/Valkey 打进交付包、随产品发给客户	要看	分发包里带不带许可义务
用云厂商托管的缓存实例	基本不用管	看服务商协议与锁定，而非开源许可
只是想把 Valkey 纳进技术选型对比	不用为许可也能做	先看命令/协议兼容，不先看条款

这张表的读法：右列从上往下才逐渐从「运维问题」变成「许可问题」。多数人在第一行，却替第四、第五行的场景操心。

跟不跟：各自的条件

先说不跟（维持现状、别动）的情形：

1. 纯内部缓存，用的是读写、过期、分布式锁、计数器这一类常规能力——换不换对你没有功能上的差别，许可也管不到你。
2. 你用的是托管服务，底层到底是 Redis 还是别的、什么许可，是服务商要操心的，你只看服务等级和数据导出。
3. 迁移本身有成本，而缓存往往是横向依赖：它一动，牵的是一圈服务而不是单个应用（这类横向层的归属我放在微服务架构拆解里说过）。当许可带给你的只是「口径变了一个名字」这种不确定性，而动手的代价是整条链路重测时，不动是更稳的判断。

再说该评估换 Valkey 的情形：

1. 你本来就在多个缓存实现/多厂商之间留了兼容层，切换的成本已经被摊薄，那顺手评估一下没有额外负担。
2. 你要做对外交付，且不想花精力去逐条判断自己算不算触发某个条款——注意，理由是「懒得背这份不确定性」，而不是「确定现在的用法有问题」。为了一个用不上的法务争论去背评估成本，不划算。
3. 你看重 Linux 基金会中立托管 + 多家云厂商背书这个治理结构，不希望这一层的走向绑定在单一厂商的商业决策上。

真要评估兼容性，别假设「协议兼容」就等于「无脑替换」。Redis 和 Valkey 的兼容说的是命令与协议这一层，稳妥的做法是先把你代码里真正调用到的命令列出来，再在目标版本上过一遍——这套「先盘命令面、再下结论」的习惯，和我整理 MySQL 命令速查 时是同一个思路：清单之外的一律不臆测，清单之内的逐条验。除命令外还有几处最容易在切换当晚才暴露：客户端库的初始化参数和连接语义、持久化文件（RDB/AOF 这类）在两边是否互读、以及你依赖的过期淘汰策略和任何扩展模块。性能数字我不给结论，那得拿你自己的负载在预发上量。

一句收尾

Redis 换回开源、Valkey 另起一摊，对厂商是路线之争，对你其实只是一次「要不要改这一处依赖」的判断。分界线从头到尾就一条：自用还是对外交付。 前者今年大概率可以什么都不做；后者值得评估，但评估的落点是治理结构和交付形态，不是被新闻带着换版本号。手上在跑、又不对外售卖的那套——先看兼容，别看许可。