Redis 的演进之路：从缓存到 AI 数据库（V1.0至8.4）

最近闲来无事，在重新翻看 redis 书籍和笔记。被这个标题吸引了，所以翻译看看。

原文：The Evolution of Redis: From Cache to AI-Database (V1.0 to 8.4)

 

Peter Zaitsev，我们的创始人之一，在2009年 Redis (Remote DIctionary Server) 刚出现时就对其开始了研究 (参考：https://www.percona.com/blog/looking-at-redis/)，这让我不禁感慨这个项目在十六年间的发展历程------它已从简单的键值存储演变为包含向量搜索的多模型平台。本文将从四个不同时代来梳理这一发展历程。

 

2010 ------ 2015 ------ 2020 ------ 2025

v1.0 v2.6 v3.0 v5.0 v6.0 v7.0 v8.4

 

注：2024年Redis 转为 "source-available" (源码可用)(2025年改为 AGPL)，由此催生了 Valkey------基于v7.2分叉的开源项目，延续BSD许可。本文聚焦 Redis 的技术演进；截至撰稿时，两个项目仍保持高度兼容性。

 

Redis 发展的基石：数据结构服务器时代(v1.0 – v2.8)

核心数据结构的确立(v1.0 – v1.2)

Redis 1.0(2010年) 引入了基础的数据结构：字符串、列表和集合。相较于 Memcached 仅能存储不透明的二进制数据块，Redis 允许在服务器端直接操作这些数据结构。字符串是二进制安全的，可存储任何类型的数据，最大容量高达512MB。列表采用双向链表实现，压入/弹出 (push/pop) 操作的时间复杂度为O(1)，这使得 Redis 非常适合用作任务队列。

持久化机制提供了两种形式：基于时间点备份的RDB快照，以及v1.1引入的 AOF(Append-Only File)，AOF 会记录每一个写操作。这两种模型让用户可以在性能和数据持久性之间进行权衡。

功能扩展(v2.0 – v2.8)

Redis 2.0新增了哈希(一个键内的字段-值对集合)和有序集合——后者或许是最具创新性的结构，它结合了集合的唯一性和数值评分，支持O(log N)复杂度的范围查询，从而实现了实时排行榜和滑动窗口速率限制器。

版本2.2引入了内存高效的编码方式。对于小数据集，使用 "ZipList" (紧凑的连续内存块)替代指针繁多的哈希表，显著降低了内存开销。

一个重大变化发生在v2.6(2012年)，该版本加入了 Lua 脚本。开发者自此可以在服务器上原子性地执行复杂操作，消除了"获取-检查-设置"这类模式所需的网络往返。此版本还标准化了 RESP2 协议，该协议设计为人类可读的且高效的。

 

扩展：分布式系统时代(v3.0 – v5.0)

Redis集群(v3.0)

Redis 3.0(2015年)通过Redis集群实现了水平扩展。它并未采用一致性哈希，而是使用了16,384个

"哈希槽"，每个键通过 slot = CRC16(key) %16384 的取模公式分配槽位。节点/分片拥有这些槽位的子集，使得Redis能够跨多台机器分片数据集，并在部分节点故障时继续运行。

版本3.2新增了"保护模式"作为安全措施，以解决 Redis 实例暴露的问题。如果 Redis 以默认配置启动且未设置密码，它将仅响应来自本地主机的查询。此版本还利用 Sorted Sets 和 Geohashing 引入了地理空间索引。

可扩展性与流处理(v4.0 – v5.0)

Redis 4.0(2017年)引入了API模块，使得诸如 RediSearch、RedisJSON 和 RedisGraph 等扩展成为可能。这些模块可以以原生性能实现新的数据类型和命令。该版本还带来了"惰性删除"(UNLINK命令)，可以在后台线程中删除大键，从而防止阻塞事件。

Redis 5.0(2018年)增加了流------一种仿照 Kafka 设计的仅追加日志。其定义性特性是"消费者组"，支持多个客户端通过确认机制协同处理事件数据，并能自动回收故障消费者的消息。

 

企业级需求：安全与性能时代(v6.0 – v7.4)

访问控制与多线程(v6.0)

Redis 6.0(2020年)超越了单一 AUTH 密码，引入了访问控制列表，支持针对特定命令或键匹配的细粒度用户权限。原生的TLS支持为所有流量提供加密。

通过多线程I/O提升性能。虽然命令执行仍保持单线程(以保持原子性)，但从套接字读取操作和格式化响应的任务移到了后台线程。这解决了高并发环境中出现的I/O瓶颈。

RESP3协议

RESP3通过为映射、集合和双精度浮点数引入原生类型，增强了客户端能力。在 RESP2 中，复杂类型以简单数组返回，客户端需要根据命令上下文解释结果。RESP3 还添加了用于 out-of-band 的"推送"类型，实现了客户端缓存功能——当缓存的键被修改时，Redis 会通知客户端。

架构改进(v7.0)

Redis 7.0(2022年)引入了 "Redis函数"，将 Lua 脚本演进为一等公民的数据库元素，只需加载一次即可被任何客户端调用。这将服务器端逻辑与应用代码解耦。

该版本通过多部分 AOF(Multi-part AOF)从根本上改变了 AOF 持久化机制。以往，AOF 重写需要一个重写缓冲区来捕获并发写入，导致内存激增。Multi-part AOF将 AOF 拆分为一个"基础"文件(快照)和多个由清单跟踪的"增量"文件，从而消除了重写缓冲区。

特性	版本	影响
Redis 集群	3.0	通过哈希槽实现水平扩展
Lua 脚本	2.6	原子性的服务器端操作
API模块	4.0	可扩展的数据类型
访问控制列表	6.0	细粒度的安全控制
多线程 I/O	6.0	后台 I/O 处理
Multi-part AOF	7.0	消除了重写缓冲区的开销

 

人工智能：多模态平台时代(v8.0 – v8.4)

融合平台(v8.0)

Redis 8.0将之前独立的 "Redis Stack" 模块集成到核心中，将 Redis 转变为多模型数据库。"Redis Query Engine"------由 RediSearch 演进而来——使得在一个系统中实现二级索引、全文搜索和向量相似性搜索成为可能。

新的集成数据结构包括：

• JSON：支持 JSONPath 的原生文档存储

• 时间序列：优化的时间戳数据存储

• 向量集合：用于AI语义搜索的高维数据

• 概率结构：布隆过滤器、Count-min sketch、Top-K

通过优化的命令路径和异步I/O线程，性能提升达到87%延迟降低和2倍吞吐量提升。通过同时传输基础和增量数据，复制速度提高了18%。

线程模型的演进

从单线程到多线程的历程代表了架构的精心演进历程：

• v1.0 – v5.0：主线程处理一切——套接字读取、协议解析、命令执行、响应格式化、套接字写入。

• v6.0：I/O线程处理套接字操作和协议格式化，而主线程原子性地执行命令。

• v8.0：对I/O线程进行增量改进。

• v8.4：分配给特定客户端的I/O线程处理完整的读取/解析周期。主线程处理批量已解析的查询并生成回复，然后由I/O线程写回。这在8核系统上带来了高达112%的吞吐量提升。

近期创新(v8.2 – v8.4)

Redis 8.2引入了向量压缩(BF16和FP16类型)，减少了AI嵌入向量的内存占用。CLUSTER SLOT-STATS命令提供了每个槽位的CPU、网络和键数指标。

Redis 8.4新增了 FT.HYBRID 命令，用于 "hybrid search" ------在单个查询中结合全文关键词和语义向量相似性。通过"内联"数值和短字符串，JSON数组的内存效率提升了高达92%。

 

关键趋势与启示

• 超越缓存：Redis 的演进证明，高性能内存系统必须能够超越简单的缓存。随着 RAM 变得更便宜，用户需要复杂的查询能力。

• 开发者体验即战略：Redis 的成功源于它将编程语言的数据结构(列表、集合、哈希)直接映射到数据库。JSON 和向量集合的集成延续了这一模式，以服务于 Web 开发和 AI 应用。

• 单线程限制：虽然单线程简化了 Redis 并提供了确定性行为，但在现代多核 CPU 上最终遇到了性能瓶颈。谨慎的线程演进——将除内存变更之外的所有任务卸载——展示了如何在保持原子性等基本保证的同时实现架构现代化。

 

结论

Redis 从2009年的一个原型演变为世界上最受欢迎的内存数据平台，其驱动力在于对"数据局部性"的追求——将数据存储在符合使用场景的结构中，并将逻辑与数据一起执行。十六年来，其在性能和扩展性等方面持续改进。向量集合和混合搜索的加入，将使其保持深受开发者喜爱的地位，并继续在新的应用场景中保持相关性。