每周跟踪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 开始支持 JSONElasticSearch 火了Redis 想做全文搜索Kafka 火了Redis 推出 StreamsInfluxDB 火了Redis 增加 Time SeriesAI 火了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 storyValkey 更关注那些并不性感但真正重要的东西多线程性能、内存效率、集群稳定性、吞吐优化。它服务的不是“想让 Redis 变成万能数据库”的人而是那群只想要一个稳定、高效、简单、可靠内存数据结构服务器的开发者。某种意义上Valkey 并不是在“创新”而是在努力找回 Redis 当年最初的样子。而文章最后那句“Valkey 的世界里并不需要新的 Array 类型”其实也正是在表达这一点很多时候一个系统真正成熟的标志并不是它开始什么都支持而是它终于知道什么不该支持。