编译 | 核子可乐、Tina
Redis 的创始人 Salvatore Sanfilippo，更为人熟知的绰号是 Antirez，昨日宣布回归 Redis 社区。
2020 年 Antirez 辞去了 Redis 维护者的职务，此后 1620 天，他再也没有看过源代码、提交消息或任何与 Redis 相关的东西。但现在他注意到 Redis 社区出现了分裂，这让他感到担忧，因此，他考虑重返 Redis 生态系统，修复企业对于 Redis 社区的态度，帮助将后续的开发重点再次放在 Redis 的核心身上。
创始人重返 Redis：
百倍工程师的回归
2020 年，Antirez 在告别帖中表示，他辞去 Redis 开源项目的维护者，是因为希望有更多时间去探索新的领域。虽然他并未明确指出对项目现状的不满，但“处理项目”挤占了太多时间这一表述，间接反映了他想做出改变的心态。
他将 Redis“交给 Redis 社区”，标志着项目治理模式的转变。Redis 公司解释说，这一变革是为了超越传统的“终身仁慈独裁者”（BDFL）模式。
现在，Antirez 突然宣布重返 Redis。在博文中，Antirez 提到最近几年生活并不宽松，他想给女儿创造更好的生活，因此萌生了重返纽约并找份兼职工作的想法。此前，他在一次视频通话中向新任 Redis CEO Rowan Trollope 表达了这个意向，并得到了对方的积极回应。
不过，外界对 Antirez 的回归充满了各种猜测。很多人认为，除了家庭原因，一定还有其他更深层次的动机，比如巨额薪资、私下协议，甚至是对 Redis 更改许可证的不满。
Antirez 本人对此进行了澄清。他表示，是自己主动联系了 Redis，而不是公司挖角。他拿到的薪资也是“常规水平”，并没有获得额外的特殊待遇，但仍然会获得跟以前一样的 Redis 股票期权。
而对于 Redis 切换许可证的决定，他解释说虽然他自己可能会选择别的不同许可证，“毕竟我已经远离项目一线多年了，不太能感受得到业务端的压力”，但总的来讲，他完全可以理解这个决定。
2020 年，Antirez 离开后，Redis 社区风波不断。
Redis 曾以宽松的 BSD 3 条款许可而广受开发者欢迎。然而，从 7.4 版本开始，Redis 转而采用更严格的 RSALv2 和 SSPLv1 双重许可。这一变化引发了社区的广泛关注和争议，部分开发者认为 Redis 正在逐渐“闭源”。
这一变化还导致社区涌现出多个分支，包括 Redict 、以及由 Linux 基金会支持的 Valkey 分支。AWS、Google 和 Oracle 等公司也迅速加入了 Valkey 分支。随着资金充裕的 Valkey 支持者不断壮大，其势头逐渐强劲。
今年 9 月份，Linux 基金会宣布发布 Valkey 8.0 之后，有报告称 Valkey 项目正在逐渐蚕食 Redis 的市场份额。虽然 Redis 仍然是键值存储领域的霸主，使用率高达 67%，但 Valkey 已经引起了广泛关注：63% 的受访者从一开始就了解 Valkey 项目，其中约 8% 的人已经在使用它，而 12% 的人正在使用其他 Redis 替代品。此外，还有 60% 的受访者正在考虑或测试 Valkey。
2024 年，Redis 替代方案一览
上个月，Redis 试图，更是激起了社区维护者们的愤怒。
这些纷争，Antirez 实际上都看在眼里，并在 Hacker News 等平台上有所留言和回应。
因此，Antirez 表示他希望与 Trollope 一道修复企业跟社区的关系，重新引导库的发展方向：
我看到 Redis 社区正在分裂，即使是以纯粹局外人的身份来看，我也对此深感忧心。 所以我想到，也许我可以回归 Redis 生态系统，修复企业对于 Redis 社区的态度，甚至可以帮助将后续的开发重点再次放在 Redis 的核心身上。总之，我可以扮演某种“布道者”的角色——虽然我个人很不喜欢这种称呼。也就是说，我一方面充当企业和社区之间的桥梁，同时也可以开发编程演示、发明和讲解新的模式，兼顾撰写文档、制作视频和博文。这些跨越新旧两个时代的成果既符合我的兴趣，也对 Redis 的未来发展有所助益。
软件界的侠义精神
Antirez 认为，Redis 的成功离不开开源社区的共同努力，依赖的是开源领域的“侠义精神”。
在 Redis 发展的初期，Antirez 为了寻求商业化的可能性，曾探索过多种模式：一种是让它以闭源产品的形式出现，但能够以某种方式帮助用户运行 Redis，另外一种是尝试某种开放核心的方法；还有一种是考虑将新代码的 BSD 许可证推迟六个月，以便为付费用户创造一定的领先优势。
最终，得益于 VMware 和 Redis Labs 的慷慨支持，Antirez 得以全身心地投入到开源社区。
这是 Redis 发展初期的一个故事。当时，Antirez 的工作还没有什么回报，直到有一天，他接到了来自 VMware 的电话。VMware 表示愿意在经济上支持 Redis，并提出希望雇用他。当 Antirez 询问需要为他们做什么时，VMware 方面表示只需 Antirez 继续目前的工作，他们会提供报酬，并希望 Antirez 能在个人网站上注明 Redis 项目得到了 VMware 的赞助。
VMware 以及后来的 Redis Labs，他们做的并不只是付一份工资。如果大家快速浏览一下代码仓库的贡献历史，就会发现位列第二的贡献者是 Oran Agra（来自 Redis），第三位则是 Pieter Noordhuis（来自 VMware）。
Antirez 认为，过去 12 年间，Redis 在 BSD 协议下专注于用户需求的发展取得了巨大的成功。而新的许可证虽然引发了社区的讨论，但并非核心矛盾。实际上，新的许可证解决了几个长期存在的问题：
鼓励开发者为核心代码做出更多贡献，而不是将新功能都塞进模块中。
防止云服务商在不提供回报的情况下，粗暴地复制粘贴 Redis 代码库并出售相关服务。
确保 Redis 核心功能的持续发展，并让全球开发者都能参与其中。
为更多的开发者提供了通过贡献代码获得报酬的机会。
“这是我希望帮助公司达成的目标之一，我也必将为此而努力。我们定会让许可证转换对用户群体和项目功能产生良好影响，至少我自己坚定秉持着这样的理念。”
Redis 的未来方向：
关于 AI、大模型与向量索引
百倍工程师的回归，实际上是社区和技术上的双赢。
Antirez 本人对开发功能越来越感兴趣，并支持将 AI 融入。
Antirez 表示，他每天都会关注 Hacker News，并看到一大帮不喜欢 AI、拒绝接受新发展的技术人员。他发现，许多人甚至不愿意深入体验最新的模型（他特别提到 Claude AI 的表现十分突出），仍然认为这些模型毫无用处，但在他看来，情况完全不是这样。
Antirez 一直对神经网络充满兴趣。他在 2003 年编写了自己的第一个神经网络库，对整个概念的强大和功能的酷炫深感震惊。而到了 2024 年底，他终于看到了该领域爆发出的惊人成果。几年前还像是科幻小说中的桥段，如今已经成为现实。他提到 Claude AI 是他最近最好的推理、编辑和编码助手，借助它，他能够完成比以往更多的工作，生产效率显著提高，成果的质量也远超过去。他还分享了最近的一次经历：他为一家意大利出版商撰写了一篇科幻短篇小说。由于 Claude 对部分内容的批评，他决定重写结尾，最终创作出了更优秀的作品。
Antirez 提到，近期他需要评估使用 8 位量化向量计算点积的速度。他向 Claude 描述了自己特定的基准设计要求，而它两分钟之后就给出了测试方案、加以修改并评估其是否具有实际价值。
近年来，RAG 相关的数据库曾一度风靡一时，而现在我们有了与主流数据库的插件集成方案。Antirez 对此也分享了一些他的新思路，希望能改进目前的向量设计，显然社区对此充满了期待。
总的来说，Antirez 希望通过引入新的向量数据类型，将 Redis 打造成一个高效、灵活的向量搜索引擎，并为开发者提供一个高度可定制的平台，以满足各种各样的 AI 应用需求：
我坚信无论 RAG 有多受欢迎，它一定不会成为主流应用，也不可能是最具未来意义或者实用价值的应用方式——因为模型上下文正变得越来越臃肿，而未来的主流模型必须配备具有线性复杂性的注意力机制。我相信通过学习获得的嵌入仍将存在，而向量搜索则将是 Redis 的核心优势。下此论断的理由如下：首先因为向量索引属于数据结构，特别是慢数据结构，这样的数据结构往往在内存内运行效果更好。第二，则是因为我自认为找到了完美的 API 来加以公开。 在 Redis 项目的设计工作当中，我总会表现出一些自我矛盾的倾向。比如我总是会对某些看起来非常适合项目需求的事物说不（比如 Lua 脚本、哈希字段过期等等，顺带一提，现在它们都成了 Redis 的组成部分），但与此同时，我又会在看似不合时宜的时候将它们添加进来。比如 Lua 脚本功能、Redis 的内部解释器，似乎跟上下文无关的 Pub/Sub 功能，还包括数据流甚至是计算机科学专著中都不存在的合成数据结构（比如排序集）。因为对我来说，判断一项新功能适不适合被引入 Redis 主要考虑两个方面：用例和与内部设计的契合度。对我来说，Redis 更像是做给程序员们的乐高积木，而不是真正的“产品”。 所以最近开始，我觉得排序集可以启发出一种新的数据类型，其中的得分实际就是一个向量。在跟 Rowan 交流回归的同时，我开始编写设计文档，而后着手对这种新型数据结构做概念验证，以 Redis 的方式从头开始重新实现 HNSW（之所以没有选择现成的库，是因为我想一点点做调整）。其实我自己也不确定这项工作什么时候才能完成，目前仍处于编程的早期阶段，但如果提案最终得到大家的认可，也许我会再次开始贡献代码。 我实现的模块（稍后将被合并到核心内，但出于简单起见，现在它还只是个模块）实现了直接操作嵌入的新命令。下面我给大家稍微展示一下： VSIM top_1000_movies_imdb ELE "The Matrix" WITHSCORES 1) "The Matrix" 2) "0.9999999403953552" 3) "Ex Machina" 4) "0.8680362105369568" 5) "Akira" 6) "0.8635441958904266" 7) "District 9" 8) "0.8631418347358704" 9) "The Martian" 10) "0.8608670234680176" 11) "The Bourne Ultimatum" 12) "0.8599717319011688" 13) "The Bourne Supremacy" 14) "0.8591427505016327" 15) "Blade Runner" 16) "0.8585404753684998" 17) "Metropolis" 18) "0.8572960793972015" 19) "Inception" 20) "0.8521313071250916" 这里已经有了 VSIM、VADD、VCARD 等现成的指标，而这就是排序集的概念，但同时还涉及多维得分（也就是嵌入）跟 K-NN 的匹配。当然，除此之外还有很多实现技巧能够进一步提高效率。但毕竟现在这还只是概念验证代码，我还需要再多研究一下。我正在探索如何实现线程、降维、量化等等。说实话，这个过程真的很有趣。 可以看到，这里并没有提到混合搜索——也就是最近关于向量存储的流行词汇。而这也正是我们 Redis 的行事风格：让开发人员发挥作用并自行做出权衡，毕竟只有他们才知道自己正在为什么建模。每个键都有一个向量索引，这样就像程序员使用排序集时做的那样，他们会自行发明出各种有趣的拆分策略、新模式、Lua 脚本、模式以及用例建模所需要的一切。 再有，虽然关联项大多只是一小段字符串或者文档 ID，但我们也完全可以让它变得更复杂，比如带上可以稍后再过滤的元数据（我个人持怀疑态度）。我只是觉得很多用例实际上并不需要复杂的服务器端过滤，采用预分区数据进行建模就可以了。 另一个让我感到兴奋的点就是增加了潜在的 STORE 选项，即将结果存储在排序集内、而非直接将其返回给用户。当然，其中的得分代表相似度。所有这一切将对效率、可扩展性、使用脚本的能力等产生复杂且有趣的影响，我希望在未来几周乃至几个月中通过系列文章与大家分享更多发现和心得。 我觉得可能这些才是真正的重点，毕竟只有新思路才格外让人感到兴奋。
https://antirez.com/news/144
https://news.ycombinator.com/item?id=42378488
会议推荐