Redis 与雄心的代价：当功能蔓延侵蚀身份时

Redis 与雄心的代价：当功能蔓延侵蚀身份时

Redis 的发展轨迹为任何成功的架构组件提供了一个警示故事。它最初是一个精简、目标明确的工具——一个旨在以优雅方式解决特定问题的“远程字典服务器”——如今已演变成一个庞大的功能套件，威胁着要掩盖其原始的价值主张。

当一个工具试图成为所有人的所有工具时，它往往面临成为“第二系统失败”的风险：一个复杂、碎片化的自身版本，失去了最初驱动其被广泛采用的简洁性。

这是 Redis 目前面临的危机。

Redis 最初的卓越之处

在早期阶段（约 2011 年），Redis 并不自称为数据库；它是一个“高级键值存储”和“数据结构服务器”。它的成功并非偶然；它是三个特定设计成就的结果：

  1. 简单的、具有表现力的协议：其线缆协议（wire protocol）直观到可以在一小时内实现，但功能强大到足以支持丰富的数据类型。
  2. 目标明确的架构：通过将单线程、事件驱动模型与内存存储相结合，Redis 保证了原子性并消除了锁的复杂性，使其速度极快且易于理解。
  3. 得体的原语：对 linked-lists、hash-tables 和 sorted-sets 的选择完美契合了 Web 应用最常见的需求——缓存、队列和速率限制。

向“数据库”雄心的转变

在过去的十年中，Redis 从一个实用工具转变为一个功能齐全的数据库。这种转变是由捕捉开发者生态系统中每一个新兴趋势的欲望驱动的。随着新的范式在 Hacker News 和行业内获得关注，Redis 试图将它们作为模块或原生类型进行集成：

  • 文档存储：紧随 MongoDB 的成功，Redis 添加了 JSON 支持。
  • 搜索：紧随 ElasticSearch 的成功，它添加了搜索和查询功能。
  • 事件流：紧随 Kafka 的成功，它引入了 Streams。
  • 强一致性：为了尝试与 ZooKeeper 或 etcd 竞争，它引入了 Redis-Raft。
  • AI 与向量：为了在当前的炒作周期中保持相关性，它将自己定位为“AI 应用的实时上下文引擎”。

这种“宇航员模式”的开发——基于通用趋势而非特定的、紧迫的用户需求来构建功能——往往会导致半成品实现。一个典型的例子是最初的 Redis-Raft 实现，Jepsen 的 Aphyr 发现由于存在许多 bug，包括陈旧读取和丢失更新，它“本质上是无法使用的”。

臃肿与许可协议的代价

这种雄心不仅影响了技术架构；它也渗透到了商业模式中。2024 年从宽松的 BSD 许可转向限制性的三重许可模式（包括 AGPLv3）被许多人视为针对其自身用户的“焦土政策”。

结合企业级代码驱动的 CTA（如“Get a Demo”）以及具有专有感官的模块的激增，该项目已远离其作为社区驱动工具的根源。其结果是一个产品，感觉起来不像是一个手术器械，而更像是一个瑞士军刀，其中一半的刀片都是钝的。

反方观点：与“Postgres”的类比

一些观察者认为这种批评是不公平的。他们指出 PostgreSQL，它成功地集成了 JSONB、向量存储 (pgvector) 和消息队列功能，而没有丢失其身份。

论点是，如果 Postgres 可以成为一个“全能型”数据库，为什么 Redis 不可以？

然而，区别在于原始的承诺。Postgres 是从底层开始构建的、稳健的关联型数据库。Redis 的核心价值在于其作为内存存储的极端简洁与速度。当 Redis 试图成为一个强一致性的分布式锁管理器或全文检索引擎时，它继承了其原始架构的限制，往往导致其既不是一个伟大的缓存，也不是一个伟大的搜索引擎。

结论：Valkey 的崛起

市场对这种偏移的反应是 Valkey 的出现。Valkey 并不追求最新的 AI 炒作词汇或添加新的数组类型，而是专注于“不那么光鲜”的工作：提高多线程性能、内存效率和集群可靠性。

Valkey 代表了对 80% 使用场景的回归——即那些只需要 Redis 在 2011 年时那种快速、可靠的数据结构服务器的用户。通过剥离“成为一切”的雄心，Valkey 旨在重新夺回 Redis 在追求远方时所牺牲的牺牲品。

Sources