Redis8.0 新特性深度解析

1. 摘要

Redis 8.0 的发布标志着其发展历程中的一个重要里程碑，不仅带来了显著的性能提升和功能扩展，更体现了平台战略层面的重新定位。此版本最引人注目的变化包括：将先前独立的 Redis Stack 功能（如 JSON、时间序列、概率数据结构及查询引擎）整合进核心，统一命名为 Redis Open Source；引入全新的 Vector Set 数据结构（目前处于 Beta 阶段），显著增强了其在人工智能（AI）和机器学习（ML）领域，特别是向量相似性搜索方面的能力 ；实施了超过 30 项性能优化，涵盖命令延迟、吞吐量、复制效率和查询处理能力等多个维度 ；以及在许可模式上做出的重大调整，在保留原有 RSALv2 和 SSPLv1 的基础上，增加了 OSI 批准的 AGPLv3 选项 。

这些变化共同指向一个更强大、更统一、更适应现代应用需求的 Redis 平台。性能的飞跃，尤其是通过新的 I/O 线程模型和优化的复制机制实现的吞吐量翻倍和延迟降低，巩固了 Redis 在高性能场景下的领先地位 。新数据结构和查询引擎的增强，特别是针对向量数据的优化，显示了 Redis 进军 AI 基础设施市场的决心，旨在超越传统缓存角色，成为 GenAI 应用的关键组件 。平台的统一简化了开发者的使用体验，降低了采用高级功能的门槛 。而 AGPLv3 许可的引入，则是在经历了先前许可变更引发的社区争议后，试图重建与开源社区信任关系的关键一步 。总体而言，Redis 8.0 不仅仅是一次版本升级，更是一次战略性的整合与拓展，旨在为开发者提供一个功能更全面、性能更卓越、许可模式更灵活的实时数据平台。

2. Redis 8.0：统一且战略性重新定位的平台

Redis 8.0 的发布伴随着两个核心层面的战略调整：产品线的整合与许可模式的演进。这两者紧密相连，共同塑造了 Redis 作为一个统一平台的全新形象。

2.1 从社区版与 Stack 到 Redis Open Source

Redis 8.0 一个根本性的变化是将之前的 Redis Community Edition（社区版）和包含高级功能的 Redis Stack 整合为一个单一的发行版，并将其命名为 “Redis Open Source” 。这一整合意味着之前作为独立模块提供的诸多高级功能，如 RedisJSON、RedisTimeSeries、RediSearch（现为 Redis Query Engine 的一部分）以及多种概率数据结构（Bloom filter, Cuckoo filter, Count-min sketch, Top-K, t-digest），现在都已成为 Redis 8.0 核心的组成部分，包含在所有二进制发行版中 。因此，独立的 Redis 模块（如 RedisJSON、RediSearch 等）对于 Redis 8.0 及以上版本来说已不再需要，并被标记为弃用 。

此举背后的主要动因是为了解决先前双轨模式带来的问题。Redis Stack 的存在虽然保护了 Redis Labs 的商业创新，但也割裂了开发者的体验，并可能减缓了核心 Redis 本身的演进速度 。通过将这些高级功能融入核心，Redis 旨在提供一个更加内聚和一致的开发体验，让所有用户都能直接使用最先进的功能，从而加速基于 Redis 的应用开发与创新 5。这种统一使得开发者无需再纠结于不同版本之间的功能差异，简化了技术选型和部署流程。

2.2 许可演进：引入 AGPLv3

与平台统一相伴的是 Redis 许可策略的重大调整。在 2024 年 3 月将许可变更为 RSALv2 和 SSPLv1 双许可模式后，Redis Labs 因该变更（特别是 SSPLv1 被 OSI 认定为非开源许可）而面临了广泛的社区批评和用户流失，甚至催生了 Valkey 和 Redict 等重要的开源分支。Redis Labs 官方也承认这一变更损害了与社区的关系 。

为了应对这一局面并试图修复社区关系，Redis 8.0 在保留 RSALv2 和 SSPLv1 的同时，新增了 GNU Affero General Public License version (AGPLv3) 作为第三个许可选项 1。AGPLv3 是一个被 OSI 批准的、广受认可的强 Copyleft 开源许可。提供 AGPLv3 选项，被视为 Redis 向开源社区示好、重建信任的重要举措，它为用户提供了一个明确的、符合主流开源定义的许可选择 。这一变化也恰逢 Redis 的最初创建者 Salvatore Sanfilippo (antirez) 重新加入 Redis 。

这种产品整合与许可调整是相互关联的战略行动。通过将强大的功能整合到核心产品中，提升了 Redis Open Source 本身的吸引力 。同时，提供 AGPLv3 许可直接回应了社区对 SSPL 的核心批评 ，并提供了一个许多开源支持者熟悉的许可模式，这可能有助于减缓用户流向 Valkey 等分支的趋势，因为许可问题是这些分支产生的重要原因之一 。

然而，值得注意的是，Redis 8.0 并非完全回归到之前的 BSD 许可模式。RSALv2 和 SSPLv1 的保留表明，Redis Labs 仍然希望对某些形式的商业利用（尤其是大型云服务提供商将其作为服务提供而不回馈社区的行为）设置一定的壁垒 。这种三许可并存的模式，反映了一种试图在保护商业利益、推动技术创新和维系开源社区关系之间寻求平衡的务实策略，而非一次彻底的哲学转变。

此外，Salvatore Sanfilippo 的回归及其主导开发的 Vector Set 功能 ，为 Redis 8.0 的发布及其战略方向（尤其是在 AI 领域）增添了显著的技术权威性和社区认可度。这有助于提升 Redis 8.0 的技术吸引力，并部分抵消因许可风波带来的负面影响。

3. 核心功能深度解析：扩展能力边界

Redis 8.0 不仅在平台战略和性能上进行了革新，更在核心功能层面引入了多项重要扩展，显著拓宽了其应用场景，特别是面向 AI、实时分析和复杂数据建模等领域。

3.1 Vector Set (Beta)：向量相似性搜索（VSS）的新范式

Redis 8.0 最受瞩目的新特性之一是由 Salvatore Sanfilippo 设计并引入的 Vector Set 数据结构 。该功能目前处于 Beta 测试阶段 。Vector Set 的设计灵感来源于 Redis 经典的 Sorted Set 2，但其核心目标是存储和查询高维向量嵌入（vector embeddings），这对于现代 AI 应用中的语义搜索、推荐系统、大型语言模型（LLM）应用等至关重要 。

与 Sorted Set 将元素与一个数值分数（score）关联不同，Vector Set 将字符串元素与一个向量相关联 14。其核心操作包括：

• VADD: 向 Vector Set 中添加一个元素及其对应的向量 。可以指定向量维度、向量值（支持 FP32 二进制或浮点数列表），以及可选的构建参数（如 HNSW 图的 M 和 EF_CONSTRUCTION）和属性 。
• VSIM: 查找与给定查询向量或集合内已有元素向量最相似的若干个元素 16。支持返回相似度得分 (WITHSCORES)，限制返回数量 (COUNT)，并可通过 FILTER 选项进行属性过滤 。
• 其他辅助命令：VREM (删除元素), VCARD (获取元素数量), VDIM (获取向量维度), VEMB (获取元素的近似向量), VSETATTR (设置或替换元素属性), VRANDMEMBER (随机获取元素) 等 。

Vector Set 还内建了一些高级特性：

• 量化 (Quantization): 默认情况下，向量会被量化为 8 位整数 (Q8) 以节省内存并加速计算，同时对召回率影响较小。用户也可以在首次添加元素时选择不量化 (NOQUANT) 或使用二进制量化 (BIN) 以在精度和资源消耗之间做进一步权衡 。
• 维度降低 (Dimensionality Reduction): VADD 命令支持 REDUCE 选项，可通过随机投影技术在插入时降低向量维度，适用于处理超高维向量且可接受一定精度损失的场景 。
• 属性过滤 (Attribute Filtering): 允许为 Vector Set 中的元素关联 JSON 格式的属性（通过 VADD 或 VSETATTR），并在 VSIM 查询时使用简单的表达式（如 .year > 1950 &&.price < 100）进行过滤，实现了向量相似性搜索与标量属性过滤的结合 。
• 多线程查询: VSIM 命令默认会利用后台线程执行搜索计算，以避免阻塞主线程，可以通过 NOTHREAD 选项禁用 。

Vector Set 的引入为 Redis 提供了第二种进行向量搜索的方式。它与 Redis Query Engine（原 RediSearch）提供的向量搜索功能是互补的 。Vector Set 提供了一种更底层、更接近 Redis 原生数据结构的操作方式，API 风格简洁，可能更适合主要聚焦于向量相似性计算，而不需要复杂全文检索或混合查询能力的场景 。相比之下，Redis Query Engine 则提供了更全面的搜索和查询能力，支持对 Hash 和 JSON 数据创建二级索引，执行包括向量搜索、全文搜索、地理空间查询、数值范围查询在内的复杂、可扩展的查询 。

重要提示： Vector Set 目前仍处于 Beta 阶段 1。这意味着其 API 和功能在未来的版本中可能会发生变化甚至不兼容的改动。虽然具体的限制未在文档中详述，但用户在生产环境中使用时应保持谨慎，并关注其后续发展。

表 1: Redis 8.0 中新增集成数据结构概览

数据结构	主要应用场景	关键特性/命令示例
Vector Set	AI/ML, 向量相似性搜索, 语义搜索, 推荐系统	VADD, VSIM, VREM, VCARD. 支持量化, 维度降低, 属性过滤.
JSON	存储、查询和操作 JSON 文档, 灵活的会话管理	JSON.SET, JSON.GET, JSON.DEL, JSON.TYPE, JSON.OBJLEN, JSON.ARRAPPEND, JSON.NUMINCRBY. 支持 JSONPath 查询和原子更新.
Time Series	IoT 数据, 系统遥测, 金融数据, 实时指标监控	TS.CREATE, TS.ADD, TS.GET, TS.RANGE, TS.MGET. 支持按时间范围查询, 聚合, 降采样/压缩规则, 基于标签的二级索引.
Bloom Filter	高效判断元素是否存在于大数据集/流中 (可能误判)	概率性成员检查, 内存高效. (通常命令如 BF.ADD, BF.EXISTS)
Cuckoo Filter	类似 Bloom Filter, 支持元素删除	概率性成员检查, 支持删除, 内存高效. (通常命令如 CF.ADD, CF.EXISTS, CF.DEL)
Count-Min Sketch	估算大数据流中元素的频率	频率估计, 内存高效. (通常命令如 CMS.INCRBY, CMS.QUERY)
Top-K	识别大数据流中频率最高的 K 个元素	Top-K 元素识别, 内存高效. (通常命令如 TOPK.ADD, TOPK.LIST)
t-digest	估算数据流中数值的分位数或累积分布	分位数查询 (如中位数, P99), 内存高效. (通常命令如 TDIGEST.ADD, TDIGEST.CDF, TDIGEST.QUANTILE)

表 2: Redis 8.0 中向量搜索方法比较

方法	主要机制	关键特性	API 风格	成熟度
Vector Set	原生数据结构	量化 (Q8/BIN/None), 维度降低 (REDUCE), 属性过滤 (FILTER), 多线程 VSIM	类 Set 命令 (V*)	Beta
Redis Query Engine	二级索引 (on Hash/JSON)	向量搜索 (HNSW/FLAT), 混合查询 (向量+文本/标签/数值), 可扩展性 (水平/垂直)	查询语言 (FT.*)	GA (引擎内)

这种双重向量搜索能力为开发者提供了选择：对于需要简单、轻量级、原生数据结构操作的 VSS 场景，Vector Set (Beta) 是一个值得关注的新选项；而对于需要更复杂查询能力、混合搜索以及在大型数据集上进行索引和查询的场景，功能更全面、更成熟的 Redis Query Engine 可能是更合适的选择。开发者需要根据具体需求、对 Beta 功能的接受程度以及对 API 风格的偏好来做出决策。

3.2 原生 JSON 支持：灵活的数据建模

Redis 8.0 将原生 JSON 支持整合到了核心 1。这意味着用户可以将 JSON 文档直接存储为 Redis 的键值，并使用一系列 JSON.* 命令对其进行高效、原子化的操作 。这与之前将 JSON 序列化为字符串存储在 Redis String 类型中的做法形成了对比。后者不仅效率较低（需要客户端进行序列化/反序列化），而且无法原子地更新 JSON 文档的内部结构，容易在并发场景下导致数据丢失或不一致 。

Redis 8.0 的原生 JSON 支持提供了以下核心能力：

• 存储与检索: 使用 JSON.SET 存储 JSON 值（字符串、数字、布尔、数组、对象、null），使用 JSON.GET 检索整个文档或部分内容 。

• JSONPath 查询: 支持标准的 JSONPath 语法，允许用户精确地选择和定位 JSON 文档内部的元素，无论是单个值、对象还是数组元素 。例如，JSON.GET mydoc $.users.name 可以获取 users 数组第一个元素的 name 字段。

• 原子更新:

  提供多种原子操作命令，用于修改 JSON 文档内部的值，而无需读取整个文档到客户端。例如：

  • JSON.NUMINCRBY: 原子地增加 JSON 中的数值 。
  • JSON.ARRAPPEND: 向 JSON 数组末尾追加元素 。
  • JSON.ARRINSERT: 在 JSON 数组指定位置插入元素 。
  • JSON.OBJSET (隐式通过 JSON.SET 实现部分更新): 更新对象中的字段值。
  • JSON.DEL 或 JSON.FORGET: 删除 JSON 文档中的元素 。

• 类型和结构查询: JSON.TYPE 获取路径下值的类型，JSON.OBJLEN 获取对象包含的 key 数量，JSON.ARRLEN 获取数组长度，JSON.OBJKEYS 获取对象的所有 key 等 。

原生 JSON 支持极大地增强了 Redis 处理半结构化数据的能力。一个典型的应用场景是更丰富的会话管理 。开发者可以将复杂的会话状态（如用户信息、购物车内容、访问历史、用户偏好设置等）存储为单个 JSON 文档，并能够高效地读取或更新会话中的特定部分，而无需传输和处理整个会话数据。结合 Redis Query Engine 的索引能力（见 4.4 节），还可以实现对活动会话的实时搜索和分析 。此外，由于 JSON 是 Web 和微服务领域广泛使用的数据交换格式，原生支持也简化了 Redis 与各种应用和编程语言的集成 。

3.3 集成的时间序列数据处理

Redis 8.0 将时间序列（Time Series）功能作为内置数据结构提供 1。这为处理带有时间戳的数据流提供了专门优化，适用于物联网（IoT）传感器数据、系统遥测、金融市场价格、实时监控指标等场景 。

其核心特性包括：

• 高效存储: 采用优化的内存结构（如内存块链表）和压缩算法（如 Gorilla 压缩）来存储时间戳和数值对，以减少内存占用 。
• 高性能读写: 专为高吞吐量的数据注入（ingestion）和低延迟的范围查询而设计 。
• 灵活查询:
  • TS.ADD: 添加一个或多个时间戳-值样本到时间序列 。
  • TS.GET: 获取最新的样本 。
  • TS.RANGE / TS.REVRANGE: 按指定时间范围（开始时间、结束时间）正向或反向查询样本 。
  • TS.MRANGE / TS.MREVRANGE: 对满足特定标签过滤器的多个时间序列进行范围查询 。
• 聚合查询: 支持在查询时对指定时间窗口（bucket）内的数据进行聚合计算，聚合函数包括 avg, sum, min, max, range, count, first, last, std.p, std.s, var.p, var.s, twa (时间加权平均) 等 。这使得在不获取原始数据的情况下就能进行统计分析。
• 数据生命周期管理:
  • RETENTION: 可为每个时间序列配置最大保留期（以毫秒为单位），过期数据会被自动删除 。
  • Compaction (Downsampling): 可以设置压缩规则，将旧的原始数据按指定时间间隔和聚合函数自动聚合存储到另一个（或同一）时间序列中，从而在保留历史趋势的同时减少存储空间占用 。
• 二级索引 (Labels): 每个时间序列可以关联一组标签（键值对），如 sensor_id=2, area_id=32。这些标签会被自动索引，允许用户在查询时（如使用 TS.MRANGE）通过标签过滤器 (FILTER) 来选择目标时间序列，而无需知道确切的 key 名称 。这对于监控和分析场景至关重要。

相比使用 Redis 的其他数据结构（如 Sorted Sets 或 Streams）来模拟时间序列，原生的 Time Series 类型在内存效率（特别是对于数值数据）和查询性能（尤其是聚合和范围查询）方面通常具有显著优势 。其内置的保留策略、压缩规则和标签索引功能也大大简化了时间序列数据的管理和分析流程。此外，它还提供了与 Grafana、Prometheus、Telegraf 等流行监控和可视化工具的集成方案 。

3.4 用于效率的概率数据结构

除了早已存在的 HyperLogLog，Redis 8.0 还将五种新的概率数据结构（Probabilistic Data Structures）整合进核心 。这些数据结构包括：Bloom Filter、Cuckoo Filter、Count-Min Sketch、Top-K 和 t-digest。

它们共同的设计目标是：在处理大规模数据集或高速数据流时，以牺牲一定的精确性为代价，来换取极高的内存效率和计算速度 。对于很多场景，“足够好”的近似答案比精确但缓慢或资源消耗巨大的答案更有价值。

各种概率数据结构的主要用途如下 ：

• Bloom Filter & Cuckoo Filter: 用于高效地判断一个元素是否“可能”存在于一个集合中。它们会有一定的假阳性率（即可能误报一个不存在的元素存在），但绝不会有假阴性（即如果它报告元素不存在，则该元素一定不存在）。Cuckoo Filter 相较于 Bloom Filter 的一个优点是支持元素删除。它们常用于缓存穿透防护、网络路由、唯一用户计数等场景。
• Count-Min Sketch: 用于估算数据流中各个元素的出现频率。对于高频元素，其估计通常比较准确，但对于低频元素可能会有高估。适用于需要快速了解热门项目或检测频率异常的场景。
• Top-K: 用于找出数据流中出现频率最高的 K 个元素。它并不保证完全精确，但能在有限的内存下快速识别出主要的“重击者”（heavy hitters）。
• t-digest: 用于在线估算数据流中数值的累积分布函数（CDF）或分位数（Quantile）。例如，可以快速估算中位数、P99 值，或者小于某个阈值的数值占比。适用于实时性能监控、SLA 追踪等。

将这些概率数据结构内置到 Redis 中，使得开发者可以方便地利用它们来构建内存占用小、响应速度快的近似计算应用，而无需引入外部库或自行实现复杂的算法。

3.5 新的实用工具命令：增强 Hash 操作

为了提升开发者处理 Hash 数据类型的便利性和效率，Redis 8.0 引入了三个新的 Hash 命令 1。这些命令是对 Redis 7.4 中引入的 Hash 字段过期 等功能的进一步补充。

• HGETDEL key FIELDS numfields field [field...]:

  原子地获取一个或多个指定字段的值，并在获取后将这些字段从 Hash 中删除

  1

  。如果删除了最后一个字段，该 Hash 键本身也会被删除。这简化了常见的“获取并移除”模式，例如处理任务队列中的项目。

  • 示例：HGETDEL myhash FIELDS 2 field1 field3 返回 field1 和 field3 的值（如果存在），然后将它们从 myhash 中删除 29。

• HGETEX key FIELDS numfields field [field...]:

  获取一个或多个指定字段的值，并可以选择性地为这些获取的字段设置或更新过期时间（TTL）

  1 。可以使用 EX (秒), PX (毫秒), EXAT (秒级时间戳), PXAT (毫秒级时间戳) 来设置 TTL，或使用 PERSIST 移除 TTL。这对于需要临时访问并延长某些字段生命周期的场景很有用。

  • 示例：HGETEX myhash EX 60 FIELDS 1 field1 返回 field1 的值，并将其 TTL 设置为 60 秒 。

• HSETEX key [FNX | FXX] FIELDS numfields field value [field value...]:

  设置一个或多个字段的值，并同时为这些字段设置过期时间

  1。它结合了 HSET 和 EXPIRE (或相关变种) 的功能。可选参数包括： FNX (仅当所有字段都不存在时才设置), FXX (仅当所有字段都存在时才设置), 以及设置 TTL 的选项 ( EX , PX , EXAT , PXAT) 或 KEEPTTL (保留字段现有的 TTL)。

  • 示例：HSETEX myhash EX 3600 FIELDS 2 user:id 123 status active 设置 user:id 为 123，status 为 active，并让这两个字段在 3600 秒后过期 。

这些新命令通过将常见的复合操作（如 get-then-delete, set-with-expire）封装为单个原子命令，减少了客户端与服务器之间的网络往返次数，简化了应用逻辑，并保证了操作的原子性，避免了使用 Lua 脚本或面临竞态条件的需要。

4. 性能革命：更快、更可扩展

Redis 8.0 在性能方面实现了显著的飞跃，号称是“史上性能提升最多的 Redis 版本” 。这些提升体现在延迟、吞吐量、资源利用率以及查询能力等多个方面，旨在巩固 Redis 在高性能数据处理领域的领先地位。

4.1 全面的延迟降低

Redis 8.0 包含了超过 30 项针对性能和资源利用率的优化 1。这些优化深入到 Redis 的核心代码路径，旨在减少 CPU 周期消耗、内存分配以及优化常用代码（如回复处理、数据结构操作）的数据访问模式，使 Redis 更加 CPU 高效和缓存友好 。

根据 Redis Labs 公布的基准测试结果（对比 Redis 7.2.5），Redis 8.0 在大量命令上实现了显著的延迟降低 。在一项包含 149 个测试的基准中，有 90 个命令的 p50（中位数）延迟有所降低，降低幅度从 5.4% 到惊人的 87.4% 不等，中位降低幅度为 16.7% 2。

这些改进覆盖了许多被广泛使用的命令，例如 ZADD 的中位数延迟降低高达 36%，SMEMBERS 降低达 28% 。考虑到 SET/SETEX 被 70% 的数据库使用，ZADD 被 30% 的数据库使用 ，这意味着绝大多数 Redis 用户在升级到 8.0 后都能体验到性能提升。

除了中位数延迟，尾部延迟（如 p99）也得到了改善 32。这表明 Redis 8.0 的命令执行不仅更快，而且性能更加稳定和可预测。

4.2 通过异步 I/O 线程提升吞吐量

虽然 Redis 从 6.0 版本开始就支持 I/O 线程来处理客户端请求（包括套接字读写和命令解析），但之前的实现未能充分发挥其潜力 。Redis 8.0 引入了全新的异步 I/O 线程实现，旨在更好地利用多核 CPU 资源，大幅提升吞吐量 。

新的工作机制如下 ：

1. 主线程（Main Thread）负责接收新连接，并将客户端分配给特定的 I/O 线程。
2. I/O 线程负责从客户端套接字读取数据并解析命令。
3. 当 I/O 线程完成读取和解析后，它会通知主线程。
4. 主线程从 I/O 线程接收已解析的命令，执行这些命令，并生成回复。
5. 主线程将生成的回复交给相应的 I/O 线程。
6. I/O 线程负责将回复写入客户端套接字。

这种模型将网络 I/O 和命令解析的负担从主线程分担出去，使得主线程能更专注于执行命令逻辑，从而在多核环境下提高整体处理能力。

用户可以通过设置 io-threads 配置参数来启用和配置新的 I/O 线程模型，其默认值为 1（即不启用额外 I/O 线程） 。根据 Redis Labs 在多核 Intel CPU 上的测试，当 io-threads 设置为 8 时，测得的吞吐量提升幅度在 37% 到 112% 之间（具体取决于执行的命令组合），最高可达原先的 2 倍 。

启用 I/O 线程是提升 Redis 在高并发、网络密集型负载下性能的关键手段。不过，需要注意的是，命令执行本身仍然主要由主线程负责，因此 CPU 密集型命令的性能提升可能不如 I/O 密集型命令那样显著。同时，启用多线程也意味着需要关注多线程环境下的资源竞争和同步开销，尽管 Redis 的设计旨在最小化这些开销 。

4.3 优化的复制机制

Redis 8.0 对集群中的全量同步（full synchronization）复制机制进行了重大改进，使其更加高效和健壮 。

在之前的版本中，当副本（replica）需要从主节点（primary）进行全量同步时，过程大致分为两步 ：

1. 主节点生成 RDB 快照并传输给副本。在此期间，主节点需要缓冲所有新执行的写命令。
2. RDB 传输完成后，主节点将缓冲期间积累的写命令流式传输给副本。

这种方式的主要问题在于第二步：如果 RDB 传输时间较长或期间主节点写入压力很大，主节点上用于缓冲写命令的内存（replication buffer）可能会急剧增长，甚至达到上限，导致复制失败并需要重试 。

Redis 8.0 引入的新机制采用了不同的策略 ：在复制开始时，主节点会同时启动两个流：

1. 一个流用于传输 RDB 快照数据。
2. 另一个流用于实时传输在 RDB 生成和传输期间发生的新写命令。

这意味着副本在接收 RDB 数据的同时，也在接收增量更新。第二阶段不再需要等待第一阶段完成，并且增量更新的缓冲压力在主节点和副本之间得到了分担。

这种新机制带来了三个主要优势 ：

1. 更高的主节点写入吞吐量: 在全量同步期间，主节点可以维持更高的平均写入速率（测试中提高了 7.5%）。
2. 更低的内存消耗: 主节点上峰值复制缓冲区的内存占用显著降低（测试中降低了 35%），减少了因内存不足导致复制失败的风险。
3. 更快的同步时间: 整个全量同步过程耗时更短（测试中缩短了 18%）。

这些改进使得 Redis 集群在节点加入、故障恢复或进行维护操作时的复制过程更快、更稳定，对生产环境的干扰更小。

4.4 Redis Query Engine：增强的可扩展性与处理能力

Redis 8.0 将 Redis Query Engine（查询引擎，源自 RediSearch）的两种关键扩展能力带到了 Redis Open Source 版本，而这些能力以前仅在 Redis Cloud 和 Redis Software (企业版) 中提供 2。这极大地提升了开源版本处理复杂查询和大规模索引数据的能力。

两种新的扩展维度是 ：

1. 水平扩展 (Horizontal Scaling): 查询引擎现在支持在 Redis Cluster 模式下运行。这意味着可以在集群的多个分片（shard）上创建和查询索引。索引数据会分布在各个分片上，允许管理非常庞大的数据集。查询请求会被路由到所有相关的分片并行执行，然后聚合结果。这使得可以通过增加 Redis 节点/进程来扩展索引容量和读写吞吐量。
2. 垂直扩展 (Vertical Scaling): 查询引擎可以利用节点内的多线程来并行处理查询任务。通过增加分配给查询处理的计算资源（可能是通过配置内部线程池大小等方式，具体机制未详述），可以显著提升单个节点的查询吞吐量，据称最高可达 16 倍 。

这些扩展能力对于需要高性能查询的应用场景至关重要，尤其是向量相似性搜索 (VSS)。Redis Labs 声称，凭借这些增强，Redis 8.0 成为了“最快的向量数据库” 。其公布的性能指标包括 ：

• 高向量插入率: 在十亿级别向量规模下，对于要求召回率 >= 95% 的索引配置，可持续每秒 66,000 次向量插入（实时索引）。对于精度要求较低的配置，插入率可达每秒 160,000 次。吞吐量可以通过增加服务器数量进一步提升。
• 低查询延迟: 在十亿向量规模、50 个并发查询下，对于 Top 100 近邻搜索，达到 90% 召回率的中位数延迟（含 RTT）为 200 毫秒，达到 95% 召回率的中位数延迟（含 RTT）为 1.3 秒。

除了向量搜索，查询引擎还支持对存储在 Hash 和 JSON 数据结构中的数据创建二级索引 。这使得可以进行超越简单 Key 查找的复杂查询，包括全文搜索（支持词干提取、模糊匹配）、精确匹配查询、数值范围查询、地理空间查询以及基于标签的过滤等 。

查询引擎的这些扩展，使得 Redis Open Source 8.0 不仅能处理简单的键值操作，还能作为一个强大的、可扩展的实时查询平台，用于构建复杂的搜索、分析和 AI 应用。将这些原本属于企业级的功能下放到开源版本，无疑极大地增强了 Redis Open Source 的竞争力。

表 3: Redis 8.0 关键性能改进摘要

改进领域	报告指标
命令延迟 (p50)	降低 5.4% - 87.4% (对比 7.2.5, 涉及 90 个命令)	2
吞吐量 (启用 I/O 线程)	最高提升 112% (达 2 倍 ops/sec, io-threads=8, 多核 CPU)
复制速度 (全量同步)	时间缩短 18%
复制缓冲区内存 (主节点峰值)	降低 35%
主节点复制期间写入速率	平均提高 7.5%
查询引擎处理能力 (垂直扩展)	最高提升 16 倍
向量插入速率 (1B 规模)	66k/s (>=95% 精度) - 160k/s (较低精度)
向量查询延迟 (1B 规模, p50)	200ms (90% 精度, Top100) - 1.3s (95% 精度, Top100) (含 RTT, 50 并发)

这些性能指标展示了 Redis 8.0 在多个维度上的显著进步。核心操作延迟的降低提供了普适性的性能基础，而 I/O 线程、复制优化和查询引擎扩展则针对性地解决了高并发、大规模数据和复杂查询场景下的瓶颈，共同构成了 Redis 8.0 的性能革命。

5. 对开发与运维的影响

Redis 8.0 的诸多新特性和架构变化，对应用程序的开发流程以及 Redis 实例的运维管理都将产生重要影响。

5.1 升级路径与配置变更

从旧版本升级到 Redis 8.0 需要注意，Redis 8.0 废弃了之前的 Redis 和 Redis Stack 版本 。这意味着用户需要规划从现有版本（如 7.x 或更早版本，或独立的 Redis Stack）迁移到统一的 Redis Open Source 8.0。

关键的配置变更和注意事项包括：

• 启用 I/O 线程: 新的异步 I/O 线程模型默认不启用 (io-threads 默认为 1)。为了利用多核 CPU 提升吞吐量，运维人员需要在配置文件 (redis.conf) 中显式设置 io-threads 为大于 1 的值（例如 4 或 8，取决于 CPU 核数和负载特性）。
• redis-full.conf: Redis 8.0 提供了一个新的示例配置文件 redis-full.conf 1。这个文件旨在加载 Redis 及其所有集成的组件（JSON, Time Series, Search, Vector Set 等），并包含了与这些新组件相关的配置参数。如果用户希望使用这些高级功能，可能需要参考或使用这个配置文件，或者将相关配置项添加到标准的 redis.conf 中。
• 新数据结构相关配置: 新引入的数据结构（如 Vector Set, Time Series, JSON）以及查询引擎本身可能带有新的配置参数（例如控制内存使用、索引行为、后台任务等），运维人员需要熟悉并根据需要进行调整 。
• 客户端库兼容性: 应用程序使用的 Redis 客户端库可能需要升级到支持 Redis 8.0 的版本，以便能够使用新的命令和数据结构。例如，Jedis 库发布了 5.1.0 版本以支持 Redis 8.0，但也包含了一些破坏性变更，如移除了已废弃的 Graph 模块支持 39。开发者需要检查所用客户端库的发布说明，确保兼容性并进行必要的代码调整。
• 运维考量: 新的 I/O 线程模型意味着 Redis 进程的行为可能与以往不同。运维团队可能需要重新评估服务器的 CPU 资源分配策略，并监控新的线程相关指标（如 1 M04 发布说明中提到的 INFO Threads 部分）来理解性能表现和潜在瓶颈 。

5.2 利用新特性构建现代应用

Redis 8.0 提供的丰富功能为开发者构建更强大、更智能的应用打开了新的可能性：

• AI 与机器学习:

  这是 Redis 8.0 的重点发力方向。

  • 向量相似性搜索 (VSS): 利用 Vector Set (Beta) 或 Redis Query Engine，开发者可以轻松实现语义搜索、图像/音频识别、推荐系统、问答系统等 。例如，将文本或产品描述转换为向量嵌入存储，然后快速找到语义上相似的内容。
  • 语义缓存 (Semantic Caching): 通过 VSS 缓存 LLM 的查询和响应对。当用户提出相似问题时，可以直接从 Redis 检索缓存的答案，从而减少对昂贵 LLM 服务的调用（据称可节省 >30% 调用成本），并提高响应速度 。
  • LLM 记忆与 Agentic Memory: Redis 可用作 LLM 应用的短期和长期记忆存储，存储对话历史、用户偏好、上下文信息等，以实现个性化交互和支持更复杂的 AI Agent 推理 。
  • 特征存储 (Feature Store): Redis 的低延迟特性使其适合作为在线特征存储，为机器学习模型提供实时特征数据，实现毫秒级预测 。

• 实时分析与监控:

  • 时间序列数据: 内置的 Time Series 数据结构是处理 IoT 传感器数据、应用指标、金融行情等的理想选择。开发者可以利用其高效的存储、查询和聚合能力，构建实时仪表盘、异常检测系统和趋势分析应用 。

• 复杂会话管理:

  • 原生 JSON: 使用 JSON 类型存储结构化的会话数据，可以更灵活地表示用户状态，并原子地更新会话中的特定部分 。
  • 可搜索会话: 结合 Query Engine 对 Hash 或 JSON 创建索引，可以实现对活动会话的实时搜索和分析 。例如，实时查询“所有购物车中包含某商品的用户会话”或“过去一小时内访问过特定页面的活跃用户”，为运营决策提供实时洞察 。

• 高效流处理与大数据集分析:

  • 概率数据结构: 利用 Bloom Filter 进行高效去重，使用 Count-Min Sketch 估算热门项目，通过 Top-K 追踪排行榜，借助 t-digest 分析延迟分布等，都可以在资源受限的情况下实现快速近似计算 。

这些新功能的整合，使得 Redis 不再仅仅是一个简单的缓存或键值存储。它演变成了一个多模型数据库平台，能够在单一系统中处理更多样化的数据和负载类型，从而简化应用架构，提高开发效率。开发者可以根据具体需求，选择最适合的数据结构和查询方式来解决问题，无论是构建 AI 应用、实时分析系统还是功能丰富的 Web 服务。

5.3 通过 ACL 更新增强安全性

Redis 8.0 在访问控制列表（ACL）方面也进行了更新，以适应新增加的功能模块，提供了更细粒度的安全控制 。

主要的更新包括 ：

• 新增 ACL 类别: 为新集成的数据结构和功能引入了专门的 ACL 类别，包括 @search (用于查询引擎命令), @json, @timeseries, @bloom, @cuckoo, @cms, @topk, @tdigest。这允许管理员精确地控制哪些用户可以执行与这些特定功能相关的命令。
• 现有类别扩展: 与新功能相关的命令也被添加到了现有的通用 ACL 类别中，如 @read 和 @write。例如，JSON.GET 会被归入 @read 和 @json 类别，而 JSON.SET 会被归入 @write 和 @json 类别。这确保了向后兼容性，并允许使用更粗粒度的权限控制。

ACL 机制允许管理员定义用户、用户可以执行的命令、以及用户可以访问的键模式。通过这些更新，Redis 8.0 使得管理员能够更精确地限制对新增高级功能的访问，遵循最小权限原则，从而更好地保护数据安全和完整性 。

6. 结论

Redis 8.0 不容置疑地是 Redis 发展史上的一个分水岭版本。它不仅带来了令人印象深刻的性能提升，更重要的是，它标志着 Redis 从一个高性能缓存和键值存储，向一个功能更全面、模型更多样化的实时数据平台的战略转型。

关键成果与意义总结：

1. 性能新高度： 通过底层的延迟优化、创新的异步 I/O 线程模型以及更高效的复制机制，Redis 8.0 在吞吐量和延迟方面均实现了显著突破，进一步巩固了其在速度方面的核心优势 。
2. 功能整合与扩展： 将原 Redis Stack 的核心功能（JSON, Time Series, Probabilistic, Query Engine）融入 Redis Open Source，并引入了专为 AI 设计的 Vector Set (Beta)，极大地扩展了 Redis 的原生能力，降低了开发者使用高级功能的门槛 。
3. AI 领域的战略布局： 对向量搜索能力的重点投入（通过 Vector Set 和 Query Engine 增强）以及相关性能指标的宣传，清晰地表明 Redis 意图在快速增长的 AI/ML 基础设施市场中占据重要地位，为 GenAI 应用提供核心数据支持 。
4. 统一的开发者体验： “Redis Open Source” 的单一发行版简化了技术选型和部署，为所有用户提供了完整的功能集 。
5. 与开源社区的和解尝试： 引入 AGPLv3 许可选项是对先前许可变更引发争议的直接回应，是试图重建社区信任、提供明确开源路径的关键一步，尽管其长期效果仍有待观察 。

未来展望与考量：

Redis 8.0 的发布是 Redis Labs 在面临市场竞争（来自专业数据库和云服务商）、社区压力（来自开源分支）以及技术浪潮（AI 的兴起）等多重因素下做出的重要战略调整。它试图通过技术创新和许可策略的改变，重新赢得开发者和市场的青睐。

对于技术决策者而言，Redis 8.0 提供了一个更强大的平台，尤其是在需要低延迟、高吞吐量，并结合复杂数据模型（如 JSON、时间序列、向量）的应用场景下。其增强的查询和扩展能力，使得 Redis 在某些场景下可以承担更多核心数据存储和处理的任务，而不仅仅是作为缓存层。

然而，其成功与否不仅取决于技术本身的优越性，也取决于社区对其许可策略调整的接受程度，以及与 Valkey 等分支的长期竞争格局。Vector Set 作为 Beta 功能的成熟度和稳定性也将是未来关注的重点。

总体而言，Redis 8.0 为开发者和运维团队提供了一个极具吸引力的升级选项，它更快、功能更丰富，并朝着更统一、更开放的方向迈出了重要一步。它代表了 Redis 对未来数据处理需求的深刻理解和积极响应，预示着 Redis 将在现代应用架构中扮演更加核心和多元化的角色。