采访 最近发布了 Valkey 版本 8.1，这标志着自从创建 Redis 分叉以来已经过去一年。Valkey 的联合维护者 Madelyn Olson 正在展望项目稳定后向版本 9 迈进。
由于公司引发争议的收紧许可条款决策，引发了 Redis 内存数据库的分叉，结果导致大量贡献者流失，其中就包括 Olson——AWS 首席工程师和前 Redis 维护者。Olson 现已成为 Valkey 的联合维护者，自那以后，Valkey 已推出多个更新版本，包括 8.0 以及最新的 8.1。
在 Redis 宣布将切换到 GNU Affero General Public License (AGPL) 之前，我们与 Olson 进行了交流。
Valkey 的创建不仅使数据库摆脱了 Redis 指导委员会的控制，还释放出大量因 Redis 开源项目而被压抑的功能需求。
Olson 在今年伦敦举行的 Kubecon EU 活动期间与 The Register 聊天时回忆道：“分叉之后，特别是 8.0 发布后，确实出现了一大波相关功能的需求。”
“另一个以前被 Redis 开源项目老指挥委员会明确阻止的功能，是我们在 8.0 版本中为槽统计构建的可观测性功能。
“槽分布在各个分片上。当进行重平衡时，你需要找出哪些槽最为活跃，然后确保它们得到合理平衡。
“我们想构建一个功能，可以让你轻松迅速地判断哪些槽热度较高，从而知道如何对其进行重平衡。
“这个功能此前曾被屏蔽，但作为新团队的新面孔，我们在 8.0 版本中就把它作为首批构建的功能之一！”
看似是个显而易见的功能，为什么会被阻止？
“归根结底，就是因为有些人不愿为此支付那微乎其微的性能成本……我想这归结于一种哲学上的分歧。”
Olson 认为，Valkey 8.0 以及当前的 8.1 版本在性能上有提升，这些改进不仅轻松弥补了增加可观测性功能所带来的性能开销，而且该功能在性能调优时极为有用。
“我看到的大多数工作负载，”她说道，“瓶颈往往在存储上……比如‘引擎中最多能装下多少数据？’而大多数人并没有达到 CPU 的限制，所以我们还是有一些空闲 CPU 周期来处理额外任务的。
“不过有人认为，与其关注这些额外工作，不如专注于性能成本的降低。所以归根到底还是权衡取舍的问题。”
谈及 Valkey 的初期阶段，Olson 表示：
“最初的六个月非常辛苦，我当时几乎彻底耗尽了精力。”
Olson 指的不仅仅是发布 8.0 版本的工作，还包括围绕该项目构建社区的努力。
她解释道：“我真的不希望它变成一个单一供应商的项目，我们想确保不出现一个私有的小团体掌控一切的情况。
“因此，我们力求更具包容性，增加更多的维护者，邀请更多人加入技术指导委员会……我们努力确保项目不会全部依赖于某一个人。
“我认为这也是避免精疲力竭的最好方式：确保社区中的每个人都在参与工作，并且每个人都感受到自己正在产生影响。”
Olson 的同伴还包括来自 Percona 的首席软件工程师 Ricardo Dias，如今他也是 Valkey 的贡献者。“我的职责，”他说，“是全职参与这个社区项目，帮助构建所需的任何东西——无论是功能开发、Bug 修复，还是其他任何需要做的事。”
尽管 Percona 不计划构建自己的 Valkey 发行版，但公司将为该平台提供支持和专业服务。对许多企业来说，支持是一个非常重要的因素。
Olson 也承认了这一支持因素：“在 Valkey 项目中，我们进行了调研：‘嘿，各位，什么会促使你们转向使用？’很多人回答：‘如果你们能提供五年的支持，那我们就会转移过去。’
“目前的计划是所有版本至少获得三年的支持，我们认为这样可以接受，然后我们会将每个主要版本中最后一个次要版本正式指定为支持五年的版本。”
这就引出了一个问题：究竟会出现 8.2 版本，还是 Valkey 会直接升级到版本 9？
Olson 说道：“目前的想法是，我们会发布一个版本为 9 的大版本，基于一些我们认为较为深远改变的变动。”
对于像 Valkey 和 Redis 这样的项目来说，破坏性更改始终是一个悬而未决的大问题。Olson 解释道：“Valkey 在排队系统中也被广泛应用，你绝不希望这一层出现故障。
“所以我们对版本中引入的内容非常保守，我们甚至会明确表示，在发布重大版本时，我们会尽可能减少可能被视为破坏性的更改。我们通常称之为行为变更，因为严格来说，这并不构成破坏 API。”
客户似乎对这种保守的策略感到满意，尽管 Olson 提到 Valkey 没有收集任何遥测数据，因此团队只能依靠用户和托管服务提供商的反馈。她举了一个例子：有一位用户在生产环境中部署了最新版本，并报告称对更新非常满意。
我们也认为，这位客户能够这么快在生产环境中部署，实属大胆。
Olson 笑着说：“你知道，在科技领域，有时候你得有点勇气！”
