Redis 身份迷失
每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/
Redis 的问题，也许从来都不是技术问题，而是它已经越来越不知道自己到底是什么了。
最近 Redis 创始人 Salvatore Sanfilippo 提交了一个相当有代表性的 PR：为 Redis 增加一种新的 Array 类型。单看这个补丁，其实并不算特别惊人，甚至从工程角度来说还挺符合 antirez 一贯的风格——实现简洁、设计克制、代码味道很好，甚至还能看出一些 AI 辅助编程已经开始进入底层系统开发的痕迹。但真正值得注意的，并不是这个功能本身，而是它背后所反映出的 Redis 整个项目这些年的演化方向。因为当一个已经拥有 List、Hash、Stream、Sorted Set、JSON、TimeSeries 等大量“类数组结构”的系统，在 2026 年还在认真讨论“我们是不是需要一个新的 Array 类型”时，这件事本身已经比技术细节更说明问题。
antirez 在 PR 里解释新增 Array 的原因时提到，Hash 虽然支持随机访问，但索引需要自己维护，而且无法做范围可见性；List 适合 append 和 trim，但中间元素访问困难；Streams 更偏向 append-only 的事件模型，不适合作为普通数组使用。这些分析当然都没错，但问题在于，Redis 过去十几年几乎一直都在重复这种逻辑：某个数据结构在某种场景下“不够完美”，于是再加一个新的结构去补这个缺口。时间久了以后，Redis 开始逐渐从“少量核心抽象组成的优雅系统”，变成“每个场景都有专门 feature 的超级工具箱”。而这种变化，恰恰也是文章作者真正担心的地方。
作者认为，Redis 今天的状态，本质上是一种“身份迷失”。它原本并不是数据库，至少不是今天人们理解的那种“全能型数据库”。早期 Redis 的定位其实非常明确：一个运行在内存里的远程数据结构服务器（Remote Dictionary Server）。注意这里最关键的词并不是 Database，而是 Dictionary 和 Data Structure。它最初吸引开发者的地方，也根本不是“功能很多”，恰恰相反，是因为它简单得近乎纯粹。
如果回到 2010 到 2012 年那个阶段去看，会发现 Redis 的爆发其实有非常强烈的时代背景。当时整个互联网行业都沉浸在 NoSQL、Web Scale、Bigtable、Dynamo、REST、JSON 这些概念里，开发者刚刚开始从传统关系数据库体系中寻找新的可能性，而 Redis 恰好精准踩中了那个时代对“轻量、高性能、灵活”的全部幻想。尤其是在 memcached 已经成为 Web 基础设施默认组件的背景下，Redis 的出现几乎像是一种降维打击：它保留了 memcached 的简单与高速，但又额外提供了 List、Set、Hash、Sorted Set 等极其实用的数据结构，让很多原本需要自己实现的业务逻辑突然变得异常简单。
更重要的是，Redis 当时的设计哲学高度统一。它的协议 RESP2 简单到开发者一个小时内就能手写客户端；它坚持单线程事件循环，因此所有操作天然原子化，不需要复杂锁机制；它完全以内存为中心，因此性能极高；它使用非阻塞 I/O，因此即使单线程也能同时处理大量连接。这些设计并不是孤立存在的 feature，而是一整套彼此咬合的工程哲学。正因为如此，Redis 当年不仅快，而且“容易理解”。这一点其实比性能更重要，因为大量基础设施最终失败，并不是因为 benchmark 不够漂亮，而是因为系统复杂到普通工程师无法建立稳定心智模型。Redis 早期最大的魅力，恰恰是它让人一眼就知道“它是什么”。
但后来的 Redis，开始越来越不满足于做一个数据结构服务器。它逐渐产生了一种几乎所有成功基础设施都会出现的冲动：既然已经拥有庞大用户群，那为什么不顺便把别人的领域也做掉？于是 MongoDB 火了，Redis 开始支持 JSON；ElasticSearch 火了，Redis 想做全文搜索；Kafka 火了，Redis 推出 Streams；InfluxDB 火了，Redis 增加 Time Series；AI 火了，Redis 官网现在甚至开始把自己定义成 “The Real-Time Context Engine for AI Apps”。这种演化轨迹其实非常典型，因为很多技术产品一旦成功，就会慢慢从“解决一个明确问题”，变成“试图覆盖所有场景”。
问题在于，这种扩张往往会破坏系统最初的内聚性。Redis 原本之所以强大，并不是因为它什么都能做，而是因为它只做少数事情，但做得异常好。可一旦开始进入“万物皆可 Redis”的阶段，系统内部就会不断出现第二系统效应（Second-System Effect）：协议开始变复杂，抽象开始互相污染，模块越来越多，行为越来越难预测，用户理解成本持续上升。文章作者特别点名 RESP3，就是因为它已经不再像 RESP2 那样维持简单 request/response 模型，而是引入了大量 push、订阅、客户端缓存协同等复杂机制。某种意义上，这甚至已经有点荒诞：Redis 本来是 cache，现在却开始需要协议级支持“客户端缓存 Redis”。
这种膨胀不仅发生在技术层面，也发生在商业层面。Redis Inc 在过去几年里的路线变化，其实同样反映出这种身份焦虑。公司最早其实叫 Garantia Data，本质上只是一个做 Redis Hosting 的商业公司，后来不断向 Redis 本体靠拢，最终甚至控制了 Redis 商标，并在 2024 年尝试通过修改许可证来对抗 AWS 与 GCP 的云服务竞争。结果社区强烈反弹，最后又不得不退回 AGPL 三重授权方案。这一整套过程，本质上都说明 Redis 已经不再只是一个工程师热爱的开源项目，而是一个需要面对资本、云厂商、增长压力、销售目标的大型商业资产。而一旦进入这种状态，“功能扩张”几乎会成为不可避免的结果，因为企业必须不断讲新故事：AI、向量数据库、实时上下文引擎、企业级分布式能力……这些东西未必是 Redis 最擅长的，但它必须拥有。
作者最核心的观点，其实并不是“Redis 新功能不好”，而是很多功能虽然存在，却很难真正替代专业系统。真正需要全文搜索的人，大概率还是会选择 ElasticSearch；真正需要高可靠消息系统的人，会选择 Kafka 或 RabbitMQ；真正需要强一致分布式协调的人，会使用 etcd 或 ZooKeeper。因为这些系统背后不仅是 feature，更是一整套围绕特定问题长期演化出来的工程体系。而 Redis 的很多新能力，更像是在原本的内存数据结构服务器之上不断叠加模块，最终既继承了 Redis 原本的限制，又无法完全达到专业系统的成熟度。
Redis-Raft 就是一个典型例子。文章引用了分布式系统研究者 Kyle Kingsbury 对 Redis-Raft 初版的分析，其中包括二十多个严重问题：集群长期不可用、节点崩溃、陈旧读、已提交数据丢失、逻辑错误响应，甚至无限循环。Aphyr 直接评价那个版本“几乎不可用”。这并不意味着 Redis 工程师能力不够，而是因为“做一个高性能缓存”和“做一个强一致分布式数据库”，本来就是两种完全不同的问题域。很多开发者之所以喜欢 Redis，就是因为它不是 etcd；可后来 Redis 又不断想证明自己也能成为 etcd。
文章里还有一个很有意思的例子是 Disque。2015 年 antirez 曾经尝试开发一个专门的消息队列系统，用来解决人们把 Redis 当 MQ 使用的问题。但他自己后来承认，这个项目是在 “astronaut mode” 下开发的，也就是并非来源于真实强需求，而更多是一种“看到别人这么做，于是我也想试试看”的工程冲动。作者认为，这种项目最终往往都会被放弃，因为真正困难的部分从来不是“做出一个能工作的 demo”，而是后面漫长、琐碎、痛苦的生产级问题：持久化、故障恢复、消息顺序、CAP tradeoff、网络分区、高可用一致性等等。而如果缺乏真实业务驱动，维护者通常很难长期投入热情。结果也确实如此：Disque 很快进入 abandonware 状态，后来改写成 Redis Module 后同样多年无人维护。
整篇文章真正有意思的地方，在于它并没有简单地批判 Redis，而是在讨论一种很多成功软件都会面临的命运：当一个系统因为“足够聚焦”而成功之后，它往往会因为“过度扩张”而逐渐失去原本最珍贵的特质。Redis 当年最大的价值，从来不是“它能解决所有问题”，而是“它能非常优雅地解决一小类问题”。但技术世界总会奖励增长、奖励扩张、奖励平台化，于是所有成功系统最终都会面临诱惑：继续做自己，还是成为一切。
而 Valkey 的崛起，其实某种程度上已经给出了市场答案。相比继续追逐新 feature、新 buzzword、新 AI story，Valkey 更关注那些并不性感但真正重要的东西：多线程性能、内存效率、集群稳定性、吞吐优化。它服务的不是“想让 Redis 变成万能数据库”的人，而是那群只想要一个稳定、高效、简单、可靠内存数据结构服务器的开发者。某种意义上，Valkey 并不是在“创新”，而是在努力找回 Redis 当年最初的样子。而文章最后那句“Valkey 的世界里，并不需要新的 Array 类型”，其实也正是在表达这一点：很多时候，一个系统真正成熟的标志，并不是它开始什么都支持，而是它终于知道什么不该支持。