Redis 与野心的代价

# charles leifer | Redis 与野心之价 来源: https://charlesleifer.com/blog/redis-and-the-cost-of-ambition/ 2026年5月12日 11:28/redis (https://charlesleifer.com/blog/tags/redis/)thoughts (https://charlesleifer.com/blog/tags/thoughts/)/1 条评论 (https://charlesleifer.com/blog/redis-and-the-cost-of-ambition/#comments) 让我们为自己建造一座数据库 (https://media.charlesleifer.com/blog/photos/Pieter_Bruegel_the_Elder_-_The_Tower_of_Babel_Vienna_-_Google_Art_Project_-_edited.jpg) 他们说：“来吧，我们要建造一座城和一座塔，塔顶通天，为要传扬我们的名，免得我们分散在全地上。” 我最近浏览了 antirez 为 Redis 添加数组类型 (https://github.com/redis/redis/pull/15162) 的补丁。补丁本身并不特别引人注目，除了作为一个例子，展示了 AI 辅助工具如何增强一位才华横溢且品味出众的系统工程师的能力。让我陷入沉思的是 antirez 在拉取请求（pull-request）顶部所写的文字，他在那里解释了引入数组类型的理由： > Hashes（哈希表）提供随机查找，但你必须将索引存储为键，并且没有范围可见性。Lists（列表）提供追加和修剪功能，但中间的内容仍然难以访问。Streams（流）提供仅追加的事件，这是另一种（确实有用的）野兽。 他本还可以提到 Redis 其他类似数组的功能，如原生支持数组的 JSON、时间序列，以及有序集合（sorted-sets），后者在某些情况下也可以表现得像数组一样。如今是 2026 年，Redis 正陷入某种危机，却坐着一个庞大的拉取请求，旨在添加一个新的数组类型。到底发生了什么？ ### 让我们为自己扬名 在过去的十年里，Redis 经历了很多，部分原因是企业 DBaaS 的动态变化，部分原因是“第二系统效应”（second-system effects）： - **许可证**：Redis Inc. 通过 2024 年放弃 BSD (https://github.com/redis/redis/pull/13157) 许可证，对其用户发动了一场焦土政策。当这一举动反噬自身时，他们进行了战略撤退并提供了谈判：三重许可，自选冒险模式，其中 AGPLv3 是唯一的 OSI 选项（AGPL 允许 Redis Inc. 声称自己是开源的，但它与 BSD *非常*不同）。支持 Redis 的风险投资公司本身就是一个有趣的故事。最初名为 Garantia Data，他们基本上只是另一个 NoSQL 云托管服务提供商。他们涉足 Redis 托管，开始自称 Redis Something-or-other，并最终签下 antirez 以确立自身的合法性。几年后，他们接管了商标权，这为后来的“抽毯子”行为（rugpull）铺平了道路。这篇文章及其评论回复的时效性 (https://antirez.com/news/121) 正如你所预期的那样糟糕。 - **臃肿与锁定**：Redis 最初只包含几种有用的数据类型。随着时间的推移，功能集不断增长（而且一直在增长），包含了奇特的数据结构、复杂的有状态系统（如 Streams），以及半专有模块（取决于你运行的版本）。今天当我查看 Redis 的着陆页时，我感到惊讶的是，他们在 2026 年的定位是*AI 应用的实时上下文引擎*。此外，截图中 (https://media.charlesleifer.com/blog/photos/redis-gets-ai.png) 的“免费试用 Redis”和“获取演示”按钮也值得关注。我不确定哪个更令人惊讶——“免费”还是带有企业销售色彩的“演示”行动号召（CTA）。 - **“我们必须告诉你多少次我们是一个 Web 级数据库”**的动态。这体现在 Sentinel、Cluster、Redis-Raft 以及诸如活跃-活跃地理分布®、Redis Flex®、Redis-on-Flash® 等企业功能的故事中，以及其他各种东西。 - **协议**：RESP3 (https://www.youtube.com/watch?v=veMiNQifZcM) 有很多尖锐的边缘，并打破了 RESP2 中请求/响应的基本假设。在我看来，新协议是布鲁克斯（Brooks）经典第二系统失败模式的典型代表。 - **一等客户端缓存支持**。在一种近乎荒谬的还原论中，Redis（最近的缓存）现在需要一个新协议来支持客户端缓存。 我不禁 wondered，亲爱的旧 Redis 怎么了。当我越是思考，一个令人满意的解释开始凝聚，解释了上述所有现象。在我看来，浮现出的画面是一个因野心而失去身份认同的解决方案。 凯撒之死 (https://media.charlesleifer.com/blog/photos/Vincenzo_Camuccini_-_La_morte_di_Cesare.jpg) ### 春天的喜悦与欢乐 我会把时间点定在 2011 年左右……那是许多新思想在 Web 和 Web 相关开发者圈子中流行起来的兴奋时期。当时 NoSQL 正处于其炒作周期的爆发期，*Web 规模*一词还没有被反讽地使用，Bigtable (https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf) 和 Dynamo (https://www.amazon.science/publications/dynamo-amazons-highly-available-key-value-store) 论文仍然被广泛阅读和讨论。与此同时，Ruby on Rails、*优雅*（CRUD 应用的一个理想属性）、Web 2.0、REST 和 JSON 盛行。Redis (https://redis.io/) 完美地捕捉了当时的时代精神，几乎在一夜之间进入了每个人的技术栈中。2011 年末的截图显示，Redis 将自己描述为*高级键值存储*和*数据结构服务器*。值得注意的是，其中缺少*数据库*这个词。 我们 hardly knew ye (https://media.charlesleifer.com/blog/photos/im-1778589606-812.png) 在 Redis 之前，memcached (https://memcached.org/) 是大多数 Web 服务器上安静运行的那一个不可或缺的基础设施组件。在我见过的每一次部署中，Memcached 通常除了缓存之外，还处理各种临时用途，如锁、计数器、速率限制等。所以当 Redis 出现时，当时的故事大概是“比 memcached 好得多”。Redis 的名字，**Re**mote **Di**ctionary **S**erver（远程字典服务器），强调了它是一个快速的内存字典，可以被所有服务使用。除了字节块之外，Redis 还操作一组精心挑选的数据结构（链表、哈希表、集合、有序集合），这极大地扩展了此类服务可以提供的临时用例种类。 我想指出一些我认为 Redis 完美把握的设计考虑因素，这些因素对其最初的成功起到了关键作用： - **协议**：Redis 有线协议的美妙之处在于，它简单到可以在一小时内理解和编码，同时又具有足够的表现力，可以表示多种丰富的数据类型。构建客户端库简单明了，协议感觉*恰到好处*。据 anecdotal 证据，我最受欢迎的博客文章是一篇近十年前写的*编写自己的 Redis* (https://charlesleifer.com/blog/building-a-simple-redis-server-with-python/) 教程，它详细介绍了构建协议和简单服务器的过程。 - **单线程、事件驱动、内存中**：这三者结合在一起，因为它们以非常有目的性的方式组合在一起。通过单线程，所有操作都保证原子性，毫无例外。这消除了一大类复杂性，使 Redis 易于推理。为了使单线程工作，服务器需要使用非阻塞 I/O 实现。对数据本身的操作需要极快。将它们结合起来，你就有了一个快速的键/值存储，可以从单个线程处理大量客户端。 - **数据结构**：基本原语选择得当，适合 Web 应用最常见的需求。缓存？只需使用字符串和过期时间。队列？使用列表。结构化数据？使用哈希。锁、计数器、速率限制、存活检测、监控、排行榜，等等——使用内置数据类型都非常容易。 采用率迅速增长，项目当之无愧地取得了巨大成功。在某个时刻，项目的野心发生了改变。Redis 接过了成为*数据库*的 mantle（职责/外衣）： 你说这是数据库吗 (https://media.charlesleifer.com/blog/photos/im-1778590320-482.png) ### 野心 > 戴着冠冕，手持权杖，高高在上，我坠落的越深；唯有在痛苦中至高无上；这就是野心所发现的喜悦。 一些功能确实是真正有用的补充，例如 5.0 中增加的 `BZPOPMIN`，它允许在有序集合上执行阻塞弹出操作（当将有序集合用作优先级队列时非常好）。另一些则让我觉得非常不 Redis，比如 ACLs。但大多数情况下，似乎有一种让 Redis 成为人人皆宜的万能解决方案的愿望。这些功能的添加紧密跟踪了过去十年里开发者们在 HN（Hacker News）上讨论的“最新热门事物”： - MongoDB 存储 JSON，Redis 应该是一个文档数据库 (https://redis.io/docs/latest/develop/data-types/json/) - ElasticSearch 做全文搜索，Redis 应该是一个搜索引擎 (https://redis.io/docs/latest/develop/ai/search-and-query/) - 图数据库很酷，Redis 应该是一个图数据库 (https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/deprecated-features/graph/)... (实际上，也许不 (https://redis.io/blog/redisgraph-eol/))。 - Kafka 引起了很大关注，让我们成为一个事件流平台 (https://redis.io/docs/latest/develop/data-types/streams/) - ZooKeeper 和其他强一致性数据库很重要。让我们发布它 (https://redis.io/blog/redisraft-new-strong-consistency-deployment-option/)。(Aphyr 的分析应该是必读的 (https://jepsen.io/analyses/redis-raft-1b3fbf6))。 - InfluxDB 很酷。让我们成为一个时间序列数据库 (https://redis.io/docs/latest/develop/data-types/timeseries/) - 如果我们没有 AI 故事 (https://redis.io/docs/latest/develop/data-types/vector-sets/)，我们将站在历史错误的一方。销售 (https://charlesleifer.com/blog/tokens-and-dreams/) 希望昨天就完成这件事。 这种心态的问题有两方面。首先，它忽视了使 Redis 成为每个人技术栈中不可或缺部分的因素。Redis 是简单的，命令是正交且紧密范围的，协议是清晰的，概念上是连贯的。其次，它忽视了这样一个事实：任何认真对待集成全文搜索 / 事件流处理 / 强一致性 KV / 时间序列 / 向量存储的人，都会想要真正的东西，而不是某种半成品的 Redis 模块，该模块继承了 Redis 的所有限制。因为，归根结底，Redis 的高可用性（HA）故事很复杂。持久化故事微妙且存在重要的权衡。协议痛点和客户端碎片化是一个真正的障碍。Redis 并不旨在取代你技术栈中的 Postgres，我认为 ElasticSearch / RabbitMQ / 等等 / 等等同样是任何系统的基础支柱。 以下是 Aphyr 对初始 Redis-Raft 实现分析的引用： > ……我们发现二十一个问题，包括健康集群中长期不可用、八次崩溃、三次陈旧读取、一次中止读取、五个导致已提交更新丢失的 bug、一个无限循环，以及两种逻辑损坏的响应可能发送给客户端的情况。我们测试的第一个版本 (1b3fbf6) 基本上无法使用…… 作为缓存和数据结构服务器的 Redis，与“作为 etcd 的 Redis”或上述任何其他数据库从根本上说是不同的提议。这就是脱节之处。 ### 他听到了号角声，却未引以为戒 当 antirez 在 2015 年宣布 Disque (https://github.com/antirez/disque#readme) 时，我写了一篇短文解释为什么我不会使用它 (https://charlesleifer.com/blog/why-i-won-t-be-switching-to-disque/)。我的推理基于 antirez 的这条评论： > Disque 的设计有点像是在“宇航员模式”下进行的，并不是由我的实际用例触发的，而是更多地回应我看到人们将 Redis 用作消息队列以及与其他消息队列的做法。 我将这一承认解读为预示着一个结果：被遗弃。“宇航员模式”下的项目，作为个人挑战，作为学习练习，是美妙的。然而，如果没有坚实的用例，维护者是否会保持兴趣和专注，以解决人们开始使用后出现的长尾难题？同时还要维护 Redis？高可用消息传递确实很难很好地解决，无论你在 CAP 定理的哪一边进行优化，你都将被迫做出权衡并解决一些难题。 此外，我认为没有人会采用。2015 年有许多成熟的中间件。人们使用 Redis 作为消息中间件，因为他们已经在使用 Redis，而且它足够好且简单。需求并不是一个新的消息中间件，也不是 Redis 成为一个更复杂的消息中间件。该项目误读了人们首先使用 Redis 作为中间件的原因。人们使用 Redis 作为消息中间件，正是因为他们不想使用其他东西。 我相信我的预测成真了——Disque 几乎在宣布后不久就成为了弃用软件，尽管在 GitHub 上有 8K 颗星。后来它被重写为 Redis 模块，但该模块也在过去 7 或 8 年里被遗弃。 我想明确的是，以上讨论不应被视为对 antirez 的直接或间接批评。我对他的才华和品味有着极大的敬意。我在 Redis 开发中看到的主要力量，正如我在开头提到的，是野心。开发者解决复杂问题的野心，成为人人皆宜的野心，Redis 房东（所有者）在 AWS 和 GCP 彻底终结他们之前 (https://valkey.io/) 找到方法提取最大收入的野心。野心本身并没有错。问题在于，当野心导致你忽视最初使你成功的东西时。 Valkey 的存在和采用是市场对这一动态的最终判决。Valkey 没有追逐功能和要点 (https://redis.io/compare/valkey/)，而是投资于改善多线程性能、内存效率、集群可靠性和吞吐量的不 glamorous（华丽/引人注目）的工作。Valkey 的性能基准令人印象深刻，直指那些只需要 2011 年 Redis 随附的功能的 80% 的 Redis 用户。在 Valkey 的世界里，不需要新的数组类型。 ---