MUYI · 后端工程师的生产级知识体系

Appearance

Redis 8：Vector Sets 与 Valkey 分叉 ​

Redis 8.x 是缓存领域这几年最大一次周期震荡的产物。2024-03 的 license 变更引发 Valkey 分叉。2025-05 的 8.0 GA 以回归 AGPLv3 收场，同时把 Vector Sets 做成原生数据类型。2026-10 最新已到 8.8。

一句话定位：一场「license 危机 → 分叉 → 回归开源 + 原生 AI 能力」的完整周期样本，也是向量检索下沉到缓存层的代表作。面试价值有二：供应链风险意识（license 如何真实改变选型）与向量检索工程细节（HNSW、量化、内存账）。数据结构基础先看 数据类型与底层编码。

1 历史课：license 变更、Valkey 分叉与 AGPL 回归 ​

时间线先立住：

text
2024-03 ──────► 2024 年内 ──────► 2025-05 ──────► 2026-10
license 变更      Valkey 分叉        Redis 8.0 GA      Redis 8.8
RSALv2/SSPLv1    Linux Foundation  新增 AGPLv3       Valkey 8.1+
双许可，不再      + 云厂商背书       回归开源          双线并行
算 OSI 开源      （BSD-3）

逐段展开：

时间事件
2024-03Redis 宣布新版本改用 RSALv2 / SSPLv1 双许可——两者都不被 OSI 认可为开源，「云厂商免费用 Redis 卖服务」的矛盾正式摊牌
2024 年内Linux Foundation 主持分叉 Valkey（AWS、Google、Oracle 等背书，BSD-3 许可），从 Redis 7.2 起步，当年就发布 8.0 性能大版本，主流云厂商迅速跟进托管
2025-05Redis 8.0 GA：在 RSALv2 / SSPLv1 之外新增 AGPLv3 选项，重新满足 OSI 开源定义，分叉压力缓解
2026-10双线并行：Redis 最新 8.8（8.6 / 8.4 / 8.2 为维护线）；Valkey 8.1+ 持续演进

为什么选型要懂这段（面试加分点）：

  • 供应链风险不是纸面概念。基础软件一次 license 变更，足以让云厂商与大型用户在几周内启动分叉、替换生产组件。Valkey 就是实例；
  • 治理模式之争：Valkey 走基金会中立治理（BSD-3），Redis 走厂商主导 + AGPLv3 开源合规。「谁拥有你的缓存层」在 2024 年是每个架构师都要回答的问题；
  • 回答姿势：背时间线不值钱，值钱的是能答「你们公司为什么留在 Redis / 为什么换 Valkey」这类决策题。理由要落在许可政策、模块依赖、迁移成本三件事上。

2 Redis 8 主线新能力盘点 ​

  • 许可回归：AGPLv3 选项让 Redis 重新进入「只允许 OSI 开源许可」的企业白名单，观望的存量用户开始升级回流；
  • 模块全家桶进发行版：RediSearch、RedisJSON、RedisTimeSeries、RedisBloom 随 8.x 打包进主版本，不再需要单独部署 Redis Stack。检索/时序/概率结构成为「开箱即得」；
  • 执行层性能优化：I/O 与调度层面的持续改进。官方发布了自证基准，具体数字以官方报告口径为准。选型用自己的 workload 复测；
  • 数据类型与命令增强：Hash 字段级 TTL（HEXPIRE 一族）、JSON 能力加厚；
  • Vector Sets（本篇主角）：原生向量数据类型——不是模块、不是插件，redis-server 开箱即用。

版本线速记：

版本定位
8.0（2025-05 GA）AGPLv3 回归 + 模块全家桶 + Vector Sets 内置
8.2 / 8.4维护线
8.6维护线
8.82026-10 最新

生产策略：跟最新维护线，落后两个小版本以上就该排升级计划——8.x 的迭代节奏明显快于 7.x 时代。

3 Vector Sets 深入：VADD/VSIM、HNSW 与内存账 ​

命令形态：

text
VADD s:docs doc-1 <float32 小端二进制，dim*4 字节>     # 添加向量元素
VADD s:docs Q8 doc-2 <blob>                            # 指定量化存储
VSIM s:docs <query-blob> WITHSCORES COUNT 5            # Top-K 相似，分值 0~1 越大越似
VSIM s:docs <blob> WITHSCORES COUNT 10 FILTER '<属性表达式>'  # 带属性过滤（示意）
VCARD / VDIM / VEMBERS        # 基数 / 维度 / 列出元素
VSETATTR / VGETATTR           # 给元素挂 JSON 属性 / 读取属性
VREM / VINFO                  # 删除元素 / 查看内部状态

要点拆解：

  • 元素 = 向量 + 可选属性：属性是 JSON，VSIM 的 FILTER 在候选集上按属性过滤——相当于自带一档轻量「混合检索」；
  • 索引是 HNSW（分层可导航小世界图）：EF 是查询期探索宽度，越大召回越高、延迟越高。调参方向是先定召回目标再压 EF。M 是建图期每节点连接数，越大图越稠密、召回越好、内存越大，通常不轻易动；
  • 量化与内存账：NOQUANT（float32 原值）、Q8（8bit 量化，向量内存约降到 1/4，召回略降）、BINARIZE（1bit，约 1/32，更激进）。入库前还可用 REDUCE 做随机投影降维。

内存账示例（dim=1536，仅向量本体）：

规模NOQUANT（float32）Q8
10 万条1536 × 4B × 100000 ≈ 580MB≈ 150MB
100 万条≈ 5.8GB（该考虑专用向量库了）≈ 1.5GB

（另有 HNSW 图结构与属性开销，实际以 VINFO 与进程 RSS 为准；大规模的分层选型见 B 轨 向量检索选型-pgvector-Redis-Milvus-Qdrant。）

与 RediSearch 向量检索的关系：

维度Vector SetsRediSearch
形态原生类型，开箱即用模块（8.x 起随发行版打包）
数据模型集合：元素 + 向量 + 属性索引 HASH / JSON 文档
检索能力Top-K + 属性 FILTER全文 + 结构化条件 + 向量的组合混合查询
定位轻量语义检索 / 记忆层复杂查询场景的检索引擎

性能口径提醒：Redis 官方基准称 Vector Sets 吞吐约比其对比基线高 27%。发布方是 Redis 自己，负载与基线均为官方选定，把它当参考项而不是结论。关键场景用自己的数据复测。这也是评估一切厂商基准的通用姿势。

典型用法三条：

  • 语义缓存：把 prompt 向量化，VSIM 找高相似历史问答，命中直接返回。省一次 LLM 调用，是 AI 应用里最快见效的用法。与 缓存穿透-击穿-雪崩 讲的防护问题是两回事，别混；
  • 会话记忆（agent memory）：近 N 轮对话向量化入 Set，检索相关记忆注入上下文，随会话过期清理；
  • RAG 热数据层：热知识块放 Redis 做毫秒级检索，全量语料留在专用向量库 / pgvector——分层架构见 B 轨互链。
java
// 语义缓存示意
float[] q = embed(userPrompt);
var hits = vsim("s:qa", q, 5);                 // VSIM Top-K
for (var hit : hits) {
    if (hit.score >= 0.95) return cachedAnswer(hit.element);  // 相似度阈值命中
}
String answer = llm(userPrompt);               // 未命中才调大模型
vadd("s:qa", nextId(), q);                     // VADD 入库，供下次命中
return answer;

边界认知：过滤条件复杂（多维组合、范围查询）、数据量到千万级、需要严格召回验收。这三条出现任意一条，就别让 Vector Sets 硬扛，交给专用向量库，Redis 退回热层。

高可用提醒：Vector Sets 是普通数据类型，随 RDB/AOF 持久化、随主从/集群复制扩散。容量与分片规划沿用 高可用与部署选型-主从哨兵与集群 的账。

4 Valkey 现状与迁移评估 ​

  • 演进现状：8.1+ 持续演进，性能优化、Hash 字段级 TTL 这类能力对齐。基金会治理 + BSD-3 许可，主流云厂商有托管形态；
  • API 兼容度：RESP 协议与主流命令高度兼容，redis-cli 与多数客户端可直连。差异集中在模块命令、INFO 输出、部分配置名，以及新版独有能力（如 Vector Sets）只在 Redis；
  • 生态短板：缺官方时序模块——RedisTimeSeries 没有官方对应物。RediSearch / JSON 依赖社区移植、版本滞后。AI/向量能力上 Redis 8 已先手一个身位；
  • 该选 Valkey 的时刻：纯缓存/会话/计数场景，且组织有「OSI 开源许可」硬约束，或所在云/团队已标准化 Valkey；
  • 不该选的时刻：需要时序模块、RediSearch 级混合查询、Vector Sets，或团队知识栈押在 Redis 8 新特性上。

迁移评估三步：

  1. INFO 与配置 diff 清点差异面（命令、配置项、客户端行为）；
  2. 模块依赖清单——时序/检索是硬阻塞项，出现即一票否决；
  3. 双写或影子读压测，观察兼容性与性能。

经验规律：纯缓存迁移通常顺滑，模块依赖型基本迁不动，向量场景没有迁的意义。

5 选型决策表：三条线 ​

线判据2026 建议
存量 Redis（7.x 及以下）无分叉包袱优先评估升 Redis 8.x：AGPLv3 回归 + 模块包 + Vector Sets，比迁 Valkey 便宜得多
新项目（纯缓存/会话/计数）无特殊模块依赖Redis 8 与 Valkey 都胜任，跟团队与云厂商标准走；许可有硬约束选 Valkey
新项目（AI / 向量场景）有相似检索诉求Redis 8 Vector Sets 起步做热层/中小规模；规模上去上专用向量库；要混合查询用 RediSearch（详见 B 轨选型篇）

收束：license 风险教会我们选型要看治理，Vector Sets 教会我们选型要看路线图。2026 年挑缓存/向量组件，两眼都要睁着。

面试追问链 ​

  • Redis 和 Valkey 什么关系？→ 2024-03 license 变更引发的 Linux Foundation 分叉，BSD-3、基金会治理、API 高度兼容；
  • Redis 8 为什么说「回归开源」？→ 2025-05 起 8.0 在 RSALv2/SSPLv1 之外新增 AGPLv3 选项，重新满足 OSI 定义；
  • Vector Sets 是什么？→ Redis 8 原生内置的向量类型：VADD/VSIM + HNSW 索引 + 可选量化，不是模块；
  • HNSW 的 EF 与 M 分别管什么？→ EF 查询期探索宽度（召回-延迟权衡）；M 建图期每节点连接数（召回-内存权衡）；
  • Q8 / BINARIZE 省多少内存？→ 向量本体约 1/4 与 1/32，代价是召回下降，需按业务精度验收；
  • Vector Sets 与 RediSearch 怎么选？→ 轻量 Top-K + 属性过滤用前者；全文 + 复杂条件组合的混合查询用后者；
  • 官方「吞吐高约 27%」怎么看？→ 厂商自证、自选负载与基线，当参考项不当结论，重要场景自己复测；
  • 什么场景该选 Valkey？→ 纯缓存 + 许可/治理硬约束；时序、检索、向量需求会被生态卡死；
  • 向量规模涨到百万级怎么办？→ Redis 退居热层，全量进专用向量库/pgvector，分层见 B 轨。

面试官视角小结 ​

这道题先筛知识面：能完整讲出 license → 分叉 → AGPL 回归时间线，说明对生态有持续关注。再筛工程深度：VADD/VSIM、HNSW 的 EF/M、量化的内存账答得上来。这说明真摸过向量检索，而不是只会说「Redis 出向量了」。最后筛判断力：对官方基准保持口径质疑，对存量/新项目/AI 三条线给出不同答案。并能说清 Valkey 的边界（纯缓存可以、模块生态不行）。

三个层次都过的候选人，选型时不会把公司带沟里。延伸阅读：数据类型与底层编码、高可用与部署选型-主从哨兵与集群、B 轨 向量检索选型-pgvector-Redis-Milvus-Qdrant。

2026-10 新增（2026 技术栈补全）。