八年前，Redis还是开发者手里那把趁手的瑞士军刀。哈希、列表、字符串，几个基础数据类型就能把缓存、队列、计数器的事全办了。如今打开它的官网，映入眼帘的标语是"AI应用实时上下文引擎"——旁边并列着"免费试用"和"预约演示"两个按钮。一个开源项目走到这一步，中间发生了什么？
最近，Redis创始人antirez提交了一个补丁，要给Redis增加原生数组类型。他在PR里写得很实在：哈希能随机查，但得存索引；列表能追加裁剪，中间元素却难触及；流是只读事件，完全是另一回事。这话没提的是，Redis其实早就有JSON、时序数据、有序集合这些"类数组"能力。2026年的Redis正陷入危机，却还在接收一个庞大的新功能PR，这本身就值得琢磨。
过去十年，Redis被两股力量拉扯变形。一是企业DBaaS的商业逻辑，二是典型的"第二系统效应"。
许可证风波是最痛的伤疤。2024年，Redis Inc把BSD协议撤了，搞了场焦土政策。舆论炸锅后，他们退了一步，推出三选一许可：AGPLv3作为唯一的OSI认证选项。AGPL确实能让Redis Inc继续自称"开源"，但和BSD的自由度天差地别。这家VC撑腰的公司原本叫Garantia Data，做NoSQL云托管起家，蹭上Redis热度后改名、签约antirez背书，最终拿下商标权——为后来的翻脸埋下伏笔。
功能膨胀和锁定策略同步推进。Redis从几个实用数据类型，一路膨胀到 exotic 数据结构、复杂有状态系统（流）、半专有模块。官网2026年的定位说明了一切：它不再是你熟悉的那个内存数据库，而是AI应用的实时上下文引擎。
架构层面的反复同样消耗信任。Sentinel、Cluster、Redis-Raft，再加上企业级的主动-主动地理分布、Redis Flex、Redis-on-Flash——"多少次我们才能说清自己是web-scale数据库"的焦虑，写满了这些产品路线图。
协议层面，RESP3的棱角比想象中更锋利。它打破了RESP2的请求-应答基本假设，在我看來正是Fred Brooks预言的那种"第二系统综合症"——过度设计、过度通用、过度复杂。
antirez的数组补丁本身是个小注脚，却像一面镜子：AI辅助工具确实能放大优秀系统工程师的能力，但工具救不了战略迷航。Redis的故事提醒我们，开源项目的危机往往不在技术本身，而在野心与代价的失衡。
热门跟贴