Redis 发展简史

Published: at 12:09

Redis，这款在当代软件架构中占据核心地位的内存数据结构存储系统，其发展历程是一部充满创新、应对挑战和社群驱动演进的生动史诗。从其创始人为解决特定业务痛点而进行的早期探索，到如今成为支持大规模、高性能应用的关键组件，Redis 的故事不仅反映了技术的进步，也折射出开源软件发展的动态与复杂性。本报告旨在追溯 Redis 从诞生至今的关键里程碑、核心设计哲学、主要版本迭代、社群互动及其对现代应用架构的深远影响。

起源：源于需求的解决方案

Redis 的诞生，并非源于纯粹的学术研究或某种预设的技术探索，而是为了解决一个迫在眉睫的、非常具体的实际业务问题。这个问题的核心，以及由此催生出的独特设计理念，共同奠定了 Redis 未来发展的基调。

Salvatore “antirez” Sanfilippo 与 LLOOGG 的挑战

Salvatore Sanfilippo，一位在安全领域（他因 hping 工具和著名的 idle scan 攻击而闻名）和嵌入式系统（他是 Jim Tcl 解释器的作者）均有建树的意大利开发者，在运营其初创公司 LLOOGG 时，遇到了一个严峻的技术瓶颈。LLOOGG 是一款实时的网站流量分析产品（或者可以称之为日志分析器），其后端所依赖的 MySQL 数据库，在处理高并发写入请求和快速分析近期产生的大量数据方面，显得力不从心，性能堪忧。

这个在现实世界中遇到的性能难题，成为了 Redis 诞生的直接催化剂。Sanfilippo 意识到，他迫切需要一种新型的内存数据库。这种数据库不仅要能够高效地处理各种复杂的数据结构，尤其重要的是，它要能够快速地执行列表操作，以便能够经济有效地满足 LLOOGG 项目的独特需求。正如他本人后来所述：“在我努力解决我的新产品所面临的可伸缩性问题时，我开始意识到，我真正需要的是一个能够支持复杂数据结构的内存数据库……Redis 就是这样开始的——我先写了一个原型，结果它很好地解决了我们当时面临的问题。”

最初的开发工作始于2009年初。到了同年的6月，Redis 项目已经足够稳定，可以被成功地部署到 LLOOGG 的生产环境中，并成功地取代了原有的 MySQL 系统。这次早期的实际应用，不仅解决了 LLOOGG 当时的燃眉之急，也成为了 Redis 核心设计理念的首次实战验证。

核心设计哲学：速度、简洁与强大的数据结构

Redis 从其诞生之初，就确立了其独特而鲜明的设计哲学，这些核心原则深刻地影响了它的整体架构和功能集合：

早期开发与首次公开发布

据了解，Sanfilippo 最初是使用 Tcl 语言来构建 Redis 的原型的。之后，为了追求更高的执行性能和对系统更精细的控制能力，他选择用 C 语言对其进行了重写。在 LLOOGG 项目内部的应用取得成功之后，Redis 被正式开源。Sanfilippo 当时在著名的技术社区 Hacker News 上分享了 Redis 的测试版本，并因此获得了大量宝贵的早期用户反馈。这些反馈极大地推动了 Redis 的快速迭代和新功能的添加。

值得一提的是，在 VMware 公司最终决定赞助他的全职开发工作之前，Sanfilippo 曾投入了大量的时间，在没有直接经济报酬的情况下，全心全意地进行着 Redis 的开发。这充分体现了他对这个项目的执着追求与巨大投入。

第一节启示与影响

Redis 的诞生故事，揭示了几个非常关键的因素，这些因素不仅塑造了它早期的形态特征，也从某种程度上预示了其未来能够取得巨大成功的轨迹。

首先，问题驱动的创新是 Redis 起源的核心所在。Redis 并非凭空想象的产物，而是为了解决 LLOOGG 当时所面临的那个迫切的、真实存在的系统可伸缩性危机。这种源于实际需求的实用主义出发点，使得 Redis 从一开始就专注于为一些特定的、常见的工作负载提供极致的性能表现。这也直接导致了其在设计上的一些独特选择，例如优先考虑内存的访问速度，以及针对像列表这样的动态数据结构进行高效的处理能力。这与那些试图从一开始就构建一个功能全面的、通用的数据库解决方案的项目的思路，形成了鲜明的对比。Sanfilippo 的目标非常明确，就是要解决 LLOOGG 的具体问题——即如何处理巨大的写入量，并实现快速的实时数据分析，而不是去构建一个试图满足所有需求的通用数据库。

其次，“以简驭繁”的性能策略，鲜明地体现在其单线程核心的设计之上。在多核处理器日益普及的时代背景下，选择单线程的架构似乎有些有悖常理。但这实际上是一个经过深思熟虑的战略决策，其目的是通过大幅减少多线程同步所带来的额外开销，来最大化那些内存密集型操作的执行性能。这一独特的设计选择，再结合上非阻塞的 I/O 模型，使得 Redis 能够为许多常见的操作实现非常高的吞吐量和极低的延迟。这充分证明了，对于某些特定的应用场景来说，原始的多核并行处理能力，并非通往极致速度的唯一途径。传统的那些多线程系统，往往会因为线程上下文切换和各种锁机制而产生不小的性能开销。对于那些因为数据本身就存储在内存中而执行速度已经很快的操作来说，这些额外的开销甚至可能占据了整个执行时间的很大一部分。Redis 的设计，通过在单个线程内部对命令执行进行序列化，巧妙地规避了这一点，它更多地是依靠 RAM 本身的高速度和高效的事件处理机制，来服务于大量并发的客户端连接。

最后，开发者友好性可以说是其能够迅速普及开来的重要催化剂。通过直接向开发者暴露那些他们早已熟悉的基础数据结构，并保证所有操作的原子性，Redis 显著地降低了开发者的认知负担和使用门槛。这种易于理解和易于使用的特性，是其能够迅速获得广泛采用的一个强大驱动力。开发者们可以轻松地将他们应用层面的概念，直接映射到 Redis 所提供的各种数据结构之上，而无需借助复杂的对象关系映射（ORM）工具，或者去学习一套新的查询语言。同时，命令执行的原子性，也极大地简化了客户端应用程序在进行并发管理时的复杂性，使得 Redis 成为了一个富有吸引力且非常高效的开发工具。Sanfilippo 从一开始就明确提出的、要打造一款能够令开发者感到愉悦且易于使用的工具的目标，也直接体现在了这些精心设计的功能和特性之中。

奠定基石与早期成长 (版本 1.x - 2.x)

这一发展阶段，标志着 Redis 从一个最初的、由个人发起的项目，逐步成长为一个功能日益完善的、备受关注的内存数据存储系统。其核心的架构模式在此时得以确立，并且引入了一系列关键的特性。这些特性不仅定义了 Redis 早期的核心能力，也为其后续的辉煌发展奠定了坚实的基础。

深入剖析内存优先、单线程架构

Redis 的架构核心，在于其坚定不移的内存优先的设计哲学，即数据主要被存储在 RAM（随机存取存储器）之中。这是其能够实现令人惊叹的高速性能的基石。然而，这一设计也天然地意味着，Redis 所能存储的数据集的大小，会受到可用 RAM 容量的固有限制。这在进行系统容量规划和成本考量时，是一个需要被优先考虑的关键因素。

其所谓的单线程模型，特指的是其核心命令的执行过程。Redis 利用了一套非常高效的事件循环机制（例如，在 Linux 操作系统上，它通常会使用 epoll；而在像 BSD 或 macOS 这样的操作系统上，则可能会使用 kqueue 等类似的系统调用）来并发地处理来自多个客户端的连接请求。这个事件循环机制，会一次处理一个来自不同客户端的命令，但它只会在某个客户端确实有数据准备就绪时，才会去处理该客户端的请求。通过这种方式，Redis 能够在不为每一个客户端都分配一个独立线程的情况下，高效地管理大量的并发连接。

这种独特的模型带来了许多显著的优势：它极大地简化了 Redis 内部的逻辑实现，因为无需引入那些复杂的多线程锁机制；它天然地保证了单个命令操作的原子性；并且，由于单个 CPU 核心可以持续地处理数据，它通常也能够带来更好的 CPU 缓存利用率。

这种设计主要的权衡之处在于，如果单个命令的执行时间过长，它就可能会阻塞其他所有客户端的请求，因为 Redis 无法利用多个 CPU 核心来并行地加速该命令的执行。然而，对于 Redis 所擅长处理的那些通常耗时极短的内存密集型操作而言，这往往并不会构成真正的性能瓶颈。而且，在后续的版本中，Redis 也引入了一些缓解措施，例如为命令设置超时限制，以及针对某些特定的、可能会比较耗时的操作（比如删除一个非常大的键）引入后台线程来进行处理等。

核心数据结构：构建模块

Redis 从其早期版本开始，就以其在服务器端提供的、内容丰富的内置数据结构而脱颖而出，它远非一个简单的键值对存储系统所能比拟。这些数据结构并不仅仅是一些简单的存储类型，它们各自都附带了一套功能强大且保证原子性执行的命令集，允许开发者能够以非常高效的方式来操作和处理这些数据。

这些内置的数据结构，能够非常直观地映射到我们在日常编程中经常遇到的一些常见范式和用例，这使得开发者们能够轻松地上手并高效地使用 Redis 来解决各种实际问题。

Redis 2.0 (约 2010 年第三季度): 位图、虚拟内存 (早期尝试) 与发布/订阅机制

Redis 2.0 版本的发布，是一个非常重要的里程碑。它不仅引入了多项全新的功能，也对一些现有的机制进行了扩展和改进。

Redis 2.2 (约 2011 年第一季度): 哈希数据类型的引入

在这个版本中，Redis 正式引入了哈希 (Hash) 数据类型（与之相关的命令包括 HSET, HGET, HGETALL 等）。哈希被设计用来高效地存储那些类似于对象的结构（也就是说，在单个键名之下，可以包含多个字段-值对）。与将对象的每个字段都存储为一个独立的顶级键相比，使用哈希数据类型的这种方式，能够显著地减少键的数量，从而降低了键的开销，并提高了内存的使用效率。相关的资料指出：“Redis 哈希是一种用于表示字符串类型的字段和字符串类型的值之间映射关系的数据类型……它非常适合用来表示各种数据对象。”

Redis 2.4 (约 2011 年第四季度): Sentinel 实现高可用性；虚拟内存被弃用

Redis 2.6 (约 2012 年第三季度): Lua 脚本扩展服务器端能力；虚拟内存被移除

Redis 2.8 (约 2013 年末至 2014 年初): 部分重同步 (PSYNC) 与 HyperLogLogs

第二节启示与影响

Redis 1.x 和 2.x 版本的发展历程，清晰地揭示了其核心设计哲学是如何通过不断的实践和迭代，而逐步演化并日趋成熟的。

首先，迭代式的问题解决与特性演进的模式在这一时期表现得淋漓尽致。虚拟内存功能的引入与最终被果断弃用，便是一个非常典型的例子。它充分展示了 Redis 在产品开发上所秉持的务实态度。虚拟内存最初是为了解决 RAM 容量限制这一非常实际的问题而设计的，但当其在实际应用中被证明弊大于利时，项目团队能够果断地调整方向，转而去寻求更优的解决方案（例如，后来在更高版本中推出的集群化方案）。这清楚地表明，Redis 的发展并非一成不变的，而是会根据实际的使用效果和来自社群的宝贵反馈，来进行灵活的调整，并且不惧怕去修正那些在早期阶段所做出的决策。

其次，构建分布式系统基石的意图在这一时期也逐渐显现出来。诸如发布/订阅（Pub/Sub）机制和 Sentinel 高可用性方案等重要特性的加入，表明 Redis 不再仅仅满足于做一个简单的、单点的数据存储系统，而是开始逐渐演变为一个能够促进构建更复杂、更具弹性的分布式应用的关键组件。Pub/Sub 机制提供了原生的消息传递能力，为实现事件驱动的架构和服务之间的解耦提供了有力的支持。而 Sentinel 则直接解决了高可用性这一在生产环境中至关重要的需求，通过自动化的故障转移机制，使得 Redis 更加适用于那些关键任务型的应用场景。这些特性所关注的，并不仅仅是数据存储本身，更是数据和服务在整个分布式环境中的交互方式和可靠性保障。

最后，在核心的简洁性与功能的可扩展性之间寻求一个理想的平衡点，是这一发展时期的另一个重要主题。Lua 脚本功能的引入，是 Redis 向着服务器端可编程性迈出的重要一步。它允许用户通过编写自定义脚本来扩展 Redis 的核心功能，而无需向核心代码中添加大量可能只适用于小众场景的命令。这样做的好处是，既保持了 Redis 主 API 的相对简洁和易用性，又为那些高级用户提供了强大的定制能力。当用户开始广泛地采用 Redis 之后，他们自然会遇到一些需要进行更复杂的原子操作，或者希望能够在数据旁边直接执行一些自定义逻辑的场景。Lua 脚本提供了一种通用的方式来实现这些需求，它不仅能够有效地减少网络往返所带来的延迟，还能够确保一系列操作的原子性执行。这也为后来在更高版本中出现的、更为强大的模块 API 和函数功能埋下了重要的伏笔。

攀登新高峰：集群化、模块化与流处理 (版本 3.x - 5.x)

在这一关键的发展阶段，Redis 显著地走向成熟，并开始着力解决在大规模部署时所面临的各种挑战。它不仅增强了自身的横向可扩展性，还引入了功能强大的新型数据结构，以满足现代应用程序日益增长的复杂需求。

Redis 3.0 (约 2015 年 4 月): Redis Cluster – 原生横向扩展能力

Redis 3.0 版本的发布，标志着一个至关重要的转折点。它正式引入了 Redis Cluster，这是 Redis 的一个原生的分布式实现，它允许数据能够在多个 Redis 节点之间进行自动的分片（sharding）。其主要的设计目标，是实现高性能和良好的线性可伸缩性（理论上，集群可以扩展到多达 1000 个节点，但通常在实际应用中，建议将节点数量控制在百位数级别），同时提供可接受的写操作安全性和系统可用性。

在 Redis Cluster 中，整个键空间被巧妙地划分为了 16384 个哈希槽 (hash slots)。集群中的每一个主节点（master node）都会负责管理这些哈希槽的一个子集。当需要确定某个键应该存储在哪个哈希槽时，Redis Cluster 会计算该键的 CRC16 校验和，然后对 16384 进行取模运算，从而得到其对应的哈希槽编号。这种架构设计的一个显著特点是，它避免了使用中心化的代理节点（proxy）。集群内部采用的是异步复制的机制，并且节点之间会通过一条专门的集群总线 (cluster bus) 进行通信，这条总线主要用于节点之间的发现、故障检测以及配置信息的更新等。

对于连接到 Redis Cluster 的客户端而言，它们通常需要具备一定的集群感知能力。这是因为当客户端尝试访问的某个键恰好位于另一个不同的节点上时，它们可能会收到 MOVED 或 ASK 这样的重定向指令，客户端需要能够正确地处理这些指令，并将请求转发到正确的节点。需要注意的是，在 Redis Cluster 中，多键操作（例如，同时对多个键进行原子性的读写）只有在所有涉及到的键都恰好哈希到同一个哈希槽中的情况下才被支持。为了应对这一限制，并允许用户在某些场景下仍然能够执行涉及多个键的操作，Redis Cluster 引入了哈希标签 (hash tags) 的概念。哈希标签是指键名中用花括号 {...} 包裹起来的那一部分，它可以强制让不同的键（只要它们的花括号部分相同）被分配到同一个哈希槽中。相关的资料概述了 Redis Cluster 的目标和关键的键分布机制：“Redis Cluster 是 Redis 的一个分布式实现……其目标是实现高性能和线性可伸缩性……以及良好的可用性……” 并且也解释了其数据分片方式、集群内部的主从复制模型以及写操作的一致性保障。

Redis 4.0 (约 2017 年 7 月): 模块 API、PSYNC2、LFU 淘汰策略与异步删除

Redis 4.0 版本带来了多项重大的改进，进一步增强了其核心功能和整体性能。

Redis 5.0 (约 2018 年 10 月): Redis Streams – 事件数据处理新范式

Redis 5.0 版本中最引人注目、也是意义最为深远的新特性，无疑是 Redis Streams 的引入（与之相关的命令包括 XADD, XREAD, XREADGROUP 等）。这是一种全新的、功能极其强大的、仅支持追加操作的日志型数据结构，它是专门为了高效地管理和处理高速产生的事件数据而设计的。

在 Redis Stream 中，每一个条目（entry）都有一个唯一的、通常是基于时间的 ID，并且可以包含一个或多个字段-值对（field-value pairs）。Streams 不仅支持对指定范围内的条目进行查询（通过 XRANGE 命令），还支持阻塞式的读取操作（通过 XREAD 命令）。更重要的是，它引入了至关重要的消费者组 (Consumer Groups) 的概念（通过 XGROUP, XREADGROUP, XACK 等命令来实现）。消费者组允许多个不同的客户端协作地从同一个流中消费消息，并且提供了像消息确认（acknowledgment）和待处理条目列表（pending entries list, PEL）等高级机制。这些机制使得 Redis Streams 能够实现比之前基本的 Pub/Sub 模式更为健壮、也更具可扩展性的消息处理能力。其典型的应用场景包括事件溯源（event sourcing）、传感器数据的收集与处理、实时通知系统以及作为高性能的消息队列等。相关的资料明确指出：“Redis Streams 是在 Redis 5.0 版本中引入的一个非常强大的特性，它为实时数据处理和构建事件驱动的架构提供了有力的支持。” 并且也有记录写道：“在2018年10月，Redis 5.0 版本正式发布，它引入了 Redis Stream——这是一种新的数据结构，它允许在单个键名之下，存储带有自动生成的、基于时间的序列号的、包含多个字段和字符串值的条目。”

第三节启示与影响

Redis 从 3.x 版本到 5.x 版本的发展历程，深刻地揭示了其向着更广阔的应用领域进行拓展的雄心壮志和强大能力。

首先，攻克可伸缩性的前沿阵地是这一时期的核心主题。Redis Cluster 的正式推出，直接回应了市场上日益增长的、需要处理超出单个 Redis 实例能力范围的庞大数据集和高并发工作负载的迫切需求。这标志着 Redis 从一个主要被视为单节点解决方案的系统，向着一个真正的分布式系统所迈出的关键性转变。随着 Redis 在业界变得日益普及，越来越多的用户开始触及到垂直扩展（即简单地使用配置更高、内存更大的物理机器）所能带来的性能极限。在这样的背景下，通过数据分片来实现的水平扩展能力，就变得至关重要了。Redis Cluster 为此提供了一个原生的、尽管在配置和管理上可能相对复杂一些的解决方案，它使得 Redis 能够在那些需要更大存储容量和更高吞吐量的应用场景中，与其他分布式数据存储方案展开竞争。

其次，将可扩展性确立为核心信条的理念，鲜明地体现在模块 API 的引入之上。这标志着一个重大的哲学转变，它使得 Redis 不再仅仅是一个封闭的系统，而是开始演变成为一个具有平台化潜力的基础架构。它承认了一个事实，即核心系统不可能（也不应该）去尝试实现所有可以想象到的功能，但它可以为那些需要进行深度、高性能扩展的场景，提供必要的钩子和接口。虽然之前引入的 Lua 脚本功能对于组合现有的 Redis 命令来说非常有用，但模块 API 则更进一步，它允许开发者创建全新的数据类型和底层的操作命令。这为 Redis 开辟了更为广阔的用例前景（例如，通过模块来实现像全文搜索、图数据库功能、甚至是 AI 模型服务等），而又不会因为将这些可能相对小众的功能都内置到核心之中，而让所有的用户都为这种核心的膨胀付出代价。这种机制有效地培育起了一个围绕 Redis 的、专业化的扩展功能生态系统。

最后，通过引入 Streams 来主动适应现代数据处理模式，是 Redis 具有前瞻性眼光的一大体现。Redis Streams 的出现，清晰地认识到了事件驱动架构在现代软件设计中的兴起，以及市场上对于一种比之前基本的 Pub/Sub 模式更为健壮、更具持久性且更易于扩展的消息传递系统的迫切需求。传统的 Pub/Sub 机制，其本质是“即发即弃”的，消息一旦发出，如果没有订阅者立即接收，就可能会丢失。而 Streams 则提供了消息的持久化存储、强大的消费者组管理以及精细的消息确认机制，这使得 Redis 在某些特定的用例中，甚至可以成为像 Kafka 这样的专用消息队列系统的一个可行的替代方案，尤其是在那些既需要低延迟的消息处理，又希望能够与现有的 Redis 数据集进行紧密集成的场景中。这一重要的特性，完美地迎合了像微服务架构、物联网应用以及实时数据分析等新兴的技术趋势。

IV: 迈向企业级：增强的安全性与可编程性 (版本 6.x - 7.x)

在这一关键的发展阶段，Redis 积极地融入了那些对于企业级应用采纳来说至关重要的特性。其重点主要集中在显著增强系统的安全性、提供更为复杂和灵活的可编程性，以及在协议层面进行重要的增强。

Redis 6.0 (约 2020 年 5 月): SSL/TLS 加密、访问控制列表 (ACLs)、RESP3 协议与客户端缓存

Redis 6.0 是一次具有里程碑意义的重大版本升级，它带来了多项针对安全性和性能优化的核心功能。

Redis 7.0 (约 2022 年 4 月): Redis Functions – 服务器端逻辑的再进化

Redis 7.0 版本的核心亮点，无疑是 Redis Functions 的引入。这可以看作是对之前版本中 Lua 脚本功能的又一次重要演进和升华。

第四节启示与影响

Redis 6.x 和 7.x 版本的发展，清晰地展现了其向着满足企业级应用需求而进行的成熟演进，以及对持续提升开发者生产力的高度关注。

首先，向企业级应用的成熟化是这一时期的显著特征。诸如 SSL/TLS 加密和访问控制列表 (ACLs) 这样的重量级功能的加入，并不仅仅是简单的增量改进，更是 Redis 要想在那些具有严格安全和合规性要求的企业环境中被认真对待所必需的关键补充。早期的 Redis 版本，更多地是侧重于极致的性能表现和开发者的易用性。随着其在业界变得日益普及，许多大型组织也开始希望能够采用它，但往往因为其在安全特性方面的缺失而面临一些障碍。原生的 TLS 加密支持和细粒度的访问控制（ACLs）机制，直接解决了这些长期存在的担忧，从而极大地拓宽了 Redis 的适用范围和应用场景。

其次，可编程性的精炼化以适应日益复杂的应用需求，鲜明地体现在 Redis Functions 的推出之上。它代表了对服务器端脚本能力的一次重大改进和提升，有效地解决了之前基于 EVAL/EVALSHA 的脚本模型在操作和开发层面所存在的一些痛点。通过引入 Redis Functions，使得服务器端逻辑的管理变得更易于维护、更具持久性，并且与数据库本身的集成度也更高。虽然 Lua 脚本本身功能已经非常强大，但如果将脚本的管理（例如发送脚本代码或其 SHA 摘要）视为客户端的关注点，那么对于那些逻辑比较复杂的应用来说，这种方式可能会显得有些繁琐。而通过让 Redis 服务器自身来负责存储和复制这些函数，其行为就更像是传统关系型数据库中的存储过程了，从而能够有效地简化服务器端逻辑的部署和后续的维护工作。

最后，对客户端与服务器之间交互的深度优化，通过像 RESP3 协议和客户端缓存这样的新特性得以实现。这清楚地表明，Redis 的关注点已经不仅仅局限于服务器端的处理效率，而是开始着眼于优化整个数据访问的完整路径。这也体现了 Redis 团队对一个重要事实的深刻认知，即网络延迟和数据传输本身，通常也是影响整体应用性能的重要因素。客户端缓存机制允许应用程序能够避免对那些频繁访问的数据进行不必要的网络往返请求，从而能够大幅度地降低访问延迟。而 RESP3 协议所提供的、能够主动向客户端推送缓存失效消息的能力，则使得这种客户端缓存模式变得更加健壮和高效。所有这些，都展示了一种超越 Redis 服务器本身、着眼于整体系统性能优化的宏观视角。

V: 现代纪元：治理、许可风波与未来展望 (版本 8.x 及以后)

这一时期见证了 Redis 治理结构的重大转变、一次引发了广泛争议的许可证变更、来自开发者社群的强烈反应（包括 Valkey 这个重要分支的出现）、Redis 随后为了应对局面而转向三许可证模式的调整，以及在近期版本中所取得的一系列技术进步。

Redis Ltd. (前身为 Redis Labs) 在开发与赞助中的角色

Salvatore Sanfilippo 在其早期进行 Redis 开发工作的过程中，最初曾得到 VMware 公司的赞助，随后又得到了 Pivotal 公司的支持。之后，Redis Labs（该公司于2021年正式更名为 Redis Ltd.）成为了开源 Redis 项目最主要的商业赞助者和实际的管理者。

Redis Ltd. 在为开源的 Redis 核心贡献代码的同时，也开发并提供了一个功能更为增强的商业版本——Redis Enterprise。此外，许多在早期对 Redis 生态系统产生了重要影响的模块，例如 RediSearch、RedisJSON 等，也都是由 Redis Ltd. (或其前身 Redis Labs) 开发的。相关的资料记载：“从2015年到2020年，他（指 Sanfilippo）领导了一个由 Redis Ltd. 赞助的、负责 Redis 项目核心开发的团队。” 并且也明确指出：“Redis Labs 是 Redis 的‘开源之家’和官方赞助商……它同时也是 Redis Enterprise 这个商业产品的提供者。”

许可证的转变：从 BSD 到 RSALv2/SSPLv1 及社群的回应 (2024 年 3 月)

在历史上，Redis 的核心代码一直采用的是 BSD 3-Clause 许可证，这是一种非常宽松的、被广泛接受的开源许可证。然而，在2024年3月，Redis Ltd. 突然宣布，从 Redis 7.4 版本开始，核心的 Redis 项目将转向一种双重许可证的模式：即 Redis Source Available License v2 (RSALv2) 和 Server Side Public License v1 (SSPLv1)。

Redis Ltd. 对此给出的主要理由是，此举旨在阻止那些大型的云服务提供商，通过将 Redis 作为一种托管服务来直接盈利，而不对其核心技术的发展做出相应的贡献，从而希望能够确保 Redis 项目自身的长期可持续发展。

然而，开发者社群对此的反应普遍是负面的。许多人，包括著名的开源促进会 (OSI) 本身，都认为 SSPLv1 并非一个 OSI 批准的、真正意义上的开源许可证。人们普遍担忧这种许可证模式，会对 Redis 的商业使用带来诸多限制，特别是对于那些将 Redis 作为一种服务来提供给其他用户的公司而言。这一举动被一些人视为是对真正开源精神的一种背离。相关的总结写道：“在2024年3月，Redis Labs（即现在的 Redis Ltd.）做出了一个非常有争议的决定，将其原本的 BSD 许可证转换为使用 RSALv2……和 SSPLv1 的双重许可证模式……其宣称的目的是为了阻止那些主要的云服务提供商……在不进行回馈的情况下，就将 Redis 作为一种托管服务来提供。”“社群的反应是迅速且负面的。”

Valkey 分支：一个开源的替代选择 (2024 年 3月/4月)

作为对 Redis 许可证变更的直接回应，一群曾经的 Redis 核心维护者和一些主要的科技公司（包括 AWS、Google Cloud、Oracle、Ericsson 等行业巨头）共同发起了一个名为 Valkey 的新项目。Valkey 项目是基于 Redis 7.2.4 版本的一个分支创建的，并且它选择继续采用原先的 BSD 3-Clause 许可证。

Valkey 项目迅速地成为了 Linux 基金会旗下的一个正式项目，其明确的目标是维护一个真正开源的、由社群驱动的 Redis 替代方案。其核心的理由，是希望能够确保 Redis（或者说，一个与 Redis 高度兼容的系统）能够在一种宽松的开源许可证之下持续可用，并以一种开放的、协作的方式来继续其未来的发展。许多主流的 Linux 发行版，也相继宣布了计划在其官方的软件仓库中，用 Valkey 来替换掉原先的 Redis。

Valkey 项目一经推出，就迅速获得了来自开发者社群的广泛关注和大力支持，并伴随着重要的代码贡献和快速的版本发布（例如 Valkey 8.0, 8.1 等）。它专注于在性能、可靠性和可扩展性等方面进行持续的改进，并且也包含了许多由社群开发的、非常实用的模块，例如搜索功能、JSON 支持以及布隆过滤器等。相关的描述详细记载了 Valkey 的诞生过程：“作为对 Redis OSS 7.2 版本许可证变更的回应，Valkey 这个分支被创建了出来。它代表了维护一个真正开源的基础设施选项，以服务于全球开发者的坚定承诺……这个分支最初是由来自 AWS、Ericsson、Oracle 和 Google 的一群专注的贡献者共同发起的。”

Redis 回归开源之根：采用 AGPLv3 的三许可证模式 (2025 年 5 月，针对 Redis 8.0)

面对来自开发者社群的强烈反应，以及 Valkey 项目的迅速崛起所带来的竞争压力，Redis Ltd. 在2025年5月宣布了一项重大的策略调整：从 Redis 8.0 版本开始，Redis 的开源版本将采用一种包含 RSALv2、SSPLv1 以及 OSI 批准的 GNU Affero General Public License v3 (AGPLv3) 在内的三许可证模式。

此举被广泛视为 Redis Ltd. 试图回应社群的关切，并重新与开源的核心原则进行对齐的一种努力。同时，AGPLv3 这种具有强 कॉपी左 (copyleft) 特性的许可证，仍然为那些希望在不贡献其服务本身源代码的情况下，就将 Redis 作为一种即服务（as-a-service）产品来提供的云服务提供商，设置了一定的障碍。值得注意的是，Redis 的创始人 Salvatore Sanfilippo 于2024年末以布道师和顾问的身份重新回归 Redis Ltd.，这可能在公司做出这一重要的许可证决策过程中，发挥了积极的影响。相关的资料指出：“Redis 已经通过发布 Redis 8 版本，回归到了真正的开源许可模式。该版本在现有的 RSALv2 和 SSPLv1 许可证之外，还额外提供了 AGPLv3……这个许可证选项。” 并且也提到：“Salvatore Sanfilippo 的影响：Redis 的创造者‘antirez’于2024年11月重新加入了公司，并积极倡导采用 AGPLv3 许可证。”

Redis 8.0 (2025 年 5 月): 集成模块、I/O 线程增强与向量集

Redis 8.0 版本的发布，带来了多项非常重要的更新和功能增强：

Salvatore Sanfilippo 的回归及其对 Redis 的愿景

Salvatore Sanfilippo 于2024年11月，以开发者布道师和技术顾问的身份，重新加入了 Redis Ltd. 公司。他的这次回归，被社群中的许多人视为一个非常积极的信号，并且很可能对公司最终决定转向采用 AGPLv3 许可证的决策，产生了积极的影响。他曾公开表达了希望看到 Redis 能够不断发展和进化，特别是在像向量能力这样的新兴领域（例如新引入的向量集功能），并希望能够帮助重塑公司与开发者社群之间的关系的愿望。在他后续发表的博客文章和接受的访谈中，他也深入反思了当前开源软件所面临的各种挑战、与云服务提供商之间的动态关系，以及他本人对 Redis 技术持续演进的热情。在他的一篇博文中，Sanfilippo 写道：“所以我开始思考，也许，终究我还是可以在 Redis 的生态系统中扮演一个有意义的角色。也许我能够帮助重塑公司对待社群的态度。”

第五节启示与影响

Redis 近期的发展历程，特别是围绕着其许可证所发生的一系列变动，为我们理解整个开源软件的生态系统及其未来的发展趋势，提供了非常深刻的视角。

首先，开源项目的可持续性困境是这一系列事件的核心议题。从最初的 BSD 许可证，到后来转向 RSAL/SSPL，再到最终选择采用 AGPLv3 的三许可证模式，以及期间 Valkey 分支的出现，都生动地展示了纯粹的开源理想与维持一个大规模开源项目长期、健康发展的财务现实之间的潜在冲突。这种情况尤其在面临那些大型云服务提供商可能进行的“掠夺式”使用时，显得尤为突出。Redis Ltd. 最初决定转向 RSAL/SSPL 许可证，其主要目的就是为了迫使那些从 Redis 中获益的云服务提供商，能够以某种形式回馈到项目的核心发展之中。然而，来自开发者社群的强烈反对，以及 Valkey 这个重要分支的迅速产生，都清楚地表明了用户对于宽松的、真正的开源许可证的强烈偏好。最终，Redis Ltd. 选择在其许可证选项中加入 AGPLv3，可以看作是一种试图在多方利益之间寻求平衡的折衷方案——它既在一定程度上满足了开源社区对“开放”的定义，同时又通过 AGPLv3 本身的特性，对那些希望提供 Redis 即服务（as-a-service）的云服务提供商施加了一定的义务。这也反映了在更广泛的行业范围内，其他一些知名的开源项目（例如 MongoDB、Elasticsearch 等）也曾面临过类似的挑战，并采取过类似的许可证策略调整。

其次，开发者社群与项目分支的力量不容忽视。Valkey 项目的迅速形成，并很快获得了来自业界主要参与者的大力支持，清楚地表明了：一个强大且积极的开发者社群，尤其是在得到一些具有影响力的支持者（例如大型科技公司）的背书的情况下，当一个项目的管理者被认为其行为偏离了社群的核心利益时，是完全有能力创建出可行的、具有竞争力的替代方案的。这对原始项目的所有者来说，无疑起到了一种强有力的制衡作用。Redis Ltd. 当初的许可证变更，被社群中的很大一部分人视为一种信任的破坏。因此，许多关键的开发者和主要的用户（尤其是那些云服务提供商）迅速地围绕着 Valkey 项目凝聚起来，以确保能够在原始的 BSD 许可证之下，保持项目的连续性和开放性。Linux 基金会对 Valkey 项目的支持，则为其提供了合法性的背书和稳健的治理结构。这充分说明了，“开源”并不仅仅是关乎许可证本身的条款，更关乎社群的控制权、信任的建立以及共同的价值观。

再次，Redis 8.0 版本所进行的战略性功能整合，其意义也十分重大。将像 JSON 支持、全文搜索以及时间序列数据处理这样广受欢迎的、原先作为独立模块提供的功能，直接集成到 Redis 8.0 的核心之中，可以被看作是 Redis Ltd. 为了加强其核心 Redis 产品竞争力的一项重要战略举措。这样做使得 Redis 开箱即用的功能更加丰富，这可能也是为了更有效地与包括 Valkey 在内的各种替代品（Valkey 同样也在积极地整合各种有用的模块）进行竞争，并在其新的许可模式之下，为用户提供更多的附加价值。通过将这些强大的功能直接捆绑到核心产品中，Redis Ltd. 使得其开源的 Redis 产品本身对用户更具吸引力。这也简化了那些以前必须自己去单独寻找、安装和管理这些独立模块的用户的部署和使用过程。同时，这也符合当前数据库技术发展的一个大趋势，即数据库本身变得越来越“多模型化”，并倾向于提供更为丰富和原生的功能支持。而新引入的向量集（Vector Sets）功能，则更是直接瞄准了当前异常蓬勃发展的人工智能和机器学习市场，显示了 Redis 积极拥抱新技术浪潮的决心。

最后，原始创作者的持久影响力在整个事件中也显而易见。Salvatore Sanfilippo 的回归，以及他公开发表的关于开源、社区和 Redis 未来发展的看法，似乎对 Redis Ltd. 公司的决策方向产生了切实可见的影响，特别是在最终决定采用 AGPLv3 许可证，以及更加关注像向量集这样的创新功能方面。这突显了即使在离开项目一段时间之后，一个受人尊敬的创始人，仍然可以凭借其深厚的技术积累和在社区中的崇高声望，行使其重要的道德和技术权威。Sanfilippo 在 Redis 开发者社群中广受尊敬，他的重新参与，以及他对回归 OSI 批准的开源许可证的积极倡导，无论是在 Redis Ltd. 公司内部，还是在广大的开发者社群之中，都具有相当大的分量。他在技术上的持续贡献，例如参与设计和实现新的向量集功能，也充分展示了他持续推动项目创新和发展的强大能力。

表1: Redis 许可演进

时期/版本许可证主要影响/社群反应
初始 (至 7.2.x 版本)BSD 3-Clause非常宽松，极大地促进了 Redis 的广泛采用和社群的早期发展。
Redis 7.4 (2024年3月)双重许可: RSALv2 / SSPLv1虽然源码仍然可用，但这两个许可证均未获得 OSI 的批准，其主要目的是为了限制云服务提供商的“免费”使用。这一变更引发了社群强烈的负面反应，并直接导致了 Valkey 分支的出现。
Redis 8.0 (2025年5月)三重许可: RSALv2 / SSPLv1 / AGPLv3AGPLv3 是一个 OSI 批准的开源许可证，此举被视为 Redis Ltd. 向社群和解并回归开源根基的姿态，但同时也通过 AGPLv3 的特性，对服务提供商保留了一定的限制。

VI: Redis 持久不衰的架构支柱

本节将重新审视并详细阐述在 Redis 整个演进过程中，那些始终定义着其核心特性、并对其巨大成功产生着持久影响的关键架构元素。

数据持久化策略：RDB vs. AOF – 优缺点与适用场景

Redis 提供了两种主要的数据持久化机制，以确保在服务器发生重启或意外故障后，内存中的数据不会完全丢失。同时也允许用户根据他们自身对数据安全性和系统性能的不同需求，在这两种机制之间进行灵活的权衡和选择。

Redis 数据结构的强大功能与多功能性

Redis 的核心竞争力之一，就在于其在服务器端提供的、内容极其丰富的内置数据结构。这些并不仅仅是一些简单的存储类型，它们各自都拥有一套原子性的操作命令，允许开发者能够以非常高效和复杂的方式来处理和操作这些数据。

相关的资料强调：“Redis 所提供的那些复杂的数据结构，为现代应用程序中许多常见的用例，都提供了非常灵活的数据建模方式。” 同时，最新的发布信息也突出了像 JSON、时间序列数据、各种概率性数据结构以及向量集这样的高级功能，已经被成功地集成到了 Redis 8 的核心之中。

Redis 中的事务与原子性

原子性是 Redis 设计理念中一个非常基本且重要的原则。

相关的资料详细解释了 Redis 事务的这些特性：“Redis 事务允许你将多个命令排入队列，然后在通过 EXEC 命令提交时，按顺序地执行它们……其执行是原子性的：事务中的所有命令会作为一个数据块被发送到 Redis。（在入队阶段）它是部分‘要么全做，要么全不做’的：如果某个命令在排队时就失败了（例如语法错误）……那么整个事务都将被丢弃。但是，如果某个命令在运行时发生了错误……Redis 仍然会继续执行队列中其他的命令。”

Redis 配置示例

在实际部署 Redis 时，合理的配置对于性能和安全性至关重要。以下是一个典型的 redis.conf 配置片段，供参考：

# 监听端口
port 6379

# 绑定本地回环地址，提升安全性
bind 127.0.0.1

# 设置访问密码
requirepass yourStrongPassword

# 启用持久化（RDB 快照）
save 900 1
save 300 10
save 60 10000

dir /var/lib/redis

# 限制最大内存用量，超出后采用 LRU 淘汰策略
maxmemory 256mb
maxmemory-policy allkeys-lru

# 开启 AOF 持久化
appendonly yes
appendfsync everysec

# 开启保护模式，防止误操作
protected-mode yes

⚡️ 说明：实际生产环境请根据业务需求调整端口、内存、持久化策略和安全相关配置。

Redis 的影响及其周边生态系统

Redis 的影响力远远不止于其核心功能本身，它已经深刻地改变了现代应用架构的设计模式，并围绕其催生出了一个充满活力、不断壮大的开发者社群和丰富的工具生态系统。

重塑应用架构：超越缓存的边界

尽管缓存是 Redis 最广为人知、也是其首要的应用场景，但其深远的影响力早已远远超出了这一范畴，并已渗透到现代应用架构的多个不同层面：

Redis 通过提供一个快速的、可共享的状态存储，以及高效的、灵活的通信渠道，极大地促进了像微服务这样的现代应用架构模式的普及和发展。相关的资料总结道：“Redis 的发布/订阅功能，允许开发者轻松地实现消息队列……而 Redis Streams……则提供了一个具有持久性且功能更为丰富的消息队列系统。” 同时，这些资料也广泛地涵盖了 Redis 在实时分析、会话管理等多种不同用途中的成功应用。

充满活力的社群：成长、客户端库与工具 (例如 RedisInsight)

Redis 之所以能够取得如此巨大的成功，离不开其背后那个庞大、活跃且富有创造力的开发者社群。

扩展核心功能：第三方及 Redis Ltd. 模块的角色

Redis 4.0 版本引入的模块 API，为 Redis 的功能扩展打开了一扇全新的大门，使其能够超越其内置数据结构和命令集的限制，从而应对更为广泛和复杂的应用场景。

这些形形色色的模块，将 Redis 的核心能力有效地延伸到了像高级搜索、图计算、时间序列分析以及人工智能和机器学习等全新的领域，从而在实际上将 Redis 转变为一个功能更为全面的多模型数据库平台。相关的资料提到：“Redis 模块是 Redis 的一些附加组件，它们能够扩展 Redis 的功能，以覆盖各个不同行业中最流行的那些用例……模块可以由任何人来创建。”

第七节启示与影响

Redis 对现代软件开发所产生的影响，是多维度且极其深远的。

首先，Redis 已经成为了许多现代应用架构模式的赋能者。其卓越的执行速度和灵活的数据结构，使得它在像微服务架构、事件驱动架构以及各种实时数据处理系统这些先进的架构模式中，都扮演着至关重要的关键组件角色。它通常会作为一个快速的数据层，或者一个高效的通信骨干来发挥作用，从而使得这些在理论上看起来很美好的先进架构模式，在实际的工程实践中变得真正可行。例如，微服务架构天然就需要一个能够提供快速共享状态存储和高效服务间通信的机制，而 Redis 恰好能够同时满足这两方面的需求。同样，事件驱动的系统则严重依赖于健壮可靠的消息队列，而 Redis Streams 正好能够很好地满足这一需求。此外，像实时分析、在线排行榜等功能，则直接受益于 Redis 那些经过精心优化的数据结构和其自身的高性能特性。

其次，其生态系统的效应非常显著。针对几乎所有流行的编程语言，都存在着高质量的、易于使用的客户端库，以及像 RedisInsight 这样功能强大的管理和监控工具。这些都极大地降低了开发者采用和使用 Redis 的门槛，为其最终能够取得广泛的成功，做出了巨大的贡献。通过那些开发者们早已熟悉的客户端库，可以轻松地将 Redis 集成到他们现有的技术栈之中，这使得开发团队能够无缝地采用 Redis 来提升其应用的性能和功能。而像 RedisInsight 这样的工具，则简化了对 Redis 实例的操作、调试和数据探索过程，使得 Redis 更易于被更广泛的开发者群体和运维人员所接受和使用。

最后，模块系统作为一种力量倍增器（虽然也曾一度成为争议的焦点），其作用不容小觑。模块系统极大地扩展了 Redis 的核心能力，有效地将其从一个主要的数据结构服务器，转变为一个功能更为全面的多模型数据库平台。然而，值得注意的是，Redis Ltd. 公司对其开发的某些非常流行的模块所采用的许可方式，也一度成为了在核心 Redis 本身许可证发生变更前夕的一个争议焦点。诸如 RediSearch 和 RedisJSON 这样的模块，在 Redis 快速的内存引擎基础之上，添加了全新的数据库范式（例如搜索引擎功能、文档存储功能等），这本身是非常强大的。但是，其中一些由 Redis Ltd. 开发的模块，在被集成到 Redis 8 核心之前，曾一度采用了比核心 Redis 更为严格的许可证（例如，一些旧版模块曾使用过像 RSAL、SSPL 这样的许可证），这在某种程度上也预示了后来核心 Redis 本身的许可证变更趋势，并加剧了当时社群中的一些不安情绪。如今，许多这类曾经作为独立模块提供的强大功能，都已经被整合进了采用新的三许可证模式的 Redis 8 核心之中，这本身也是一个非常重大的转变和发展。

最后总结

Redis 的发展历程，从 Salvatore Sanfilippo 为了解决 LLOOGG 项目的燃眉之急而进行的个人探索，到如今成为支撑全球无数高性能应用的关键基石，充分展现了在实际需求的驱动下，技术创新所能爆发出的巨大能量。其核心设计哲学——以内存为先、追求极致的速度、提供简洁而强大的数据结构、以及始终关注开发者体验——不仅在早期为其赢得了用户的青睐，更在漫长的演进过程中，被证明是其能够保持持久生命力的关键所在。

从最初支持基本的键值存储和列表操作，到后来逐步引入哈希、集合、有序集合等更为丰富的数据结构，再到通过 Sentinel 和 Cluster 机制解决高可用与横向扩展的挑战，Redis 的每一步都紧密围绕着提升性能和满足更广泛应用场景的需求。Lua 脚本的加入，赋予了服务器端一定的可编程性；而模块 API 的出现，则更是将 Redis 提升到了一个可扩展平台的层面，催生了像搜索、JSON 处理、时间序列分析等更为专业的应用能力。Redis Streams 的引入，则使其在事件驱动架构和实时消息处理领域占据了重要的一席之地。

进入近代，Redis 6.x 和 7.x 版本在安全性（如 SSL/TLS 加密、ACLs）、可编程性（如 Redis Functions）以及协议层面（如 RESP3、客户端缓存）的持续增强，使其更加符合企业级应用对稳健性和精细化管理的需求。

然而，开源项目的治理和商业化探索之路，从来都不是一帆风顺的。近期围绕 Redis 许可证所发生的一系列变动——从最初的 BSD 到引发争议的 RSAL/SSPL 双重许可，再到 Valkey 分支的出现，以及最终 Redis Ltd. 选择在 Redis 8.0 中回归到包含 AGPLv3 在内的三许可证模式——深刻地反映了在当前云计算时代，开源项目在维护自身可持续发展与坚持开放共享理念之间所面临的复杂博弈和艰难抉择。这一系列的事件，不仅对 Redis 自身的发展轨迹产生了深远的影响，也为整个开源软件行业如何平衡商业利益与社群期望，提供了极具价值的案例研究。

幸运的是，Redis 8.0 版本的发布，通过将许多 ранее 作为独立模块提供的强大功能直接集成到核心之中，并引入了像向量集这样的前沿特性，再次展现了其强大的技术创新能力和积极拥抱未来的决心。其创始人 Salvatore Sanfilippo 的回归，也为项目的未来发展方向和与社群的关系修复，注入了新的活力和希望。

总而言之，Redis 的故事，是一部关于如何从一个具体的问题出发，通过简洁而强大的设计，不断迭代和演进，并最终成长为一个在各自领域都具有巨大影响力的技术产品的经典传奇。它告诉我们，真正的创新往往源于对实际需求的深刻洞察；一个活跃、开放的社群是技术项目赖以生存和发展的沃土；而在商业化和开源精神之间寻求可持续的平衡，则是每一个成功的开源项目都必须认真思考和勇敢面对的课题。展望未来，无论其治理模式和商业策略如何演变，Redis 凭借其在内存数据处理领域的核心技术优势和不断创新的能力，仍将在未来的数字世界中，继续扮演着不可或缺的关键角色。

上一篇文章
Langchain报告
下一篇文章
MCP协议深度解析：AI能力扩展的标准化接口