当Redis在2024年更改许可协议，用专有的、源代码可用的替代方案取代原本宽松的BSD许可时，这一举动在社区内引发了重大分裂。短短几天内，Linux基金会便推出了Valkey，一个开源分支项目。
尽管Redis随后再次调整方向，在2025年新增了AGPLv3这一开源版权保护许可作为可选项，但对于那些希望使用具有独立治理结构、许可宽松项目的组织而言，Valkey早已走上了属于自己的道路。
在此期间发生了许多变化：Valkey着手降低内存需求，引入了新的集群管理与访问控制功能，近期还开始利用AI智能体协助完成诸如回溯修复等维护工作。
但对于部分Redis用户而言，至少还有一个重大的迁移障碍尚未扫除。
代理访问
对于不熟悉的读者而言，Redis是一种广泛用于缓存及其他对快速访问有硬性要求场景的内存数据存储。许多应用程序在构建时都假定Redis是单一实例，将这些应用迁移到分布式的Valkey Cluster往往意味着需要修改代码，以应对多节点、路由以及某些命令行为差异等问题。商业化的Redis产品以及部分云服务通过在应用与底层集群之间设置代理层来解决这一问题，但那些希望自行运行Valkey的公司一直缺乏类似的选择。
因此，Percona目前正着手填补这一空白，推出了名为Valkey-proxy的开源代理，使现有应用能够连接到Valkey Cluster，而无需重写代码。
Percona是一家开源数据库软件与服务公司，支持包括MySQL、PostgreSQL和MongoDB等多种技术。该公司同时也是Valkey项目的支持者之一，与之并列的还有AWS、谷歌云和甲骨文等云计算巨头。
在布拉格举行的Linux基金会开源峰会欧洲站会议上接受采访时，Percona负责Redis/Valkey生态系统的总经理凯尔·戴维斯表示，在迁移到集群化的Valkey部署之前必须重写应用程序，这是阻碍其更广泛采用的最后几大障碍之一。
"目前确实还没有什么好的开源解决方案来应对这个问题。"
"目前确实还没有什么好的开源解决方案来应对这个问题，所以这里一直存在一个空白，"戴维斯向The New Stack表示。
值得一提的是，市面上确实存在其他代理方案。戴维斯以Envoy为例，但他指出该方案并不能完全理解Valkey协议，其处理连接的方式也意味着它无法支持Valkey的全部功能。
这使得一些公司陷入两难：一方面是围绕单一Redis实例构建的老旧应用程序，另一方面则是随着业务增长所需要的集群化Valkey部署。Valkey-proxy正是为弥合这一分歧而设计的。
"现在我们可以覆盖一整层此前根本没有良好选择的应用，"戴维斯补充道。
"现在我们可以覆盖一整层此前根本没有良好选择的应用。"
Valkey-proxy存在的意义
Percona已在内部完成了Valkey-proxy第一版的开发，但计划是将其纳入Valkey项目，随后向更广泛的社区开放开发工作。
"从那时起，我们将获得来自Percona客户、其他机构客户以及独立开发者的大量贡献，"戴维斯表示。
当被问及AWS等超大规模云服务商是否也可能参与贡献时，戴维斯表示"有这种可能"，但他也补充说这很难预测，因为这些公司往往拥有与自身服务直接绑定的专属工具。
这使得Valkey-proxy对那些自行管理基础设施的组织——包括那些采用本地部署方式的机构——尤为重要。戴维斯表示，潜在用户群体涵盖范围很广，从资源有限的小型公司，到对合规性有严格要求的大型金融服务机构，这些企业可能需要对数据基础设施的运行地点和方式拥有更大的控制权。
此外，该代理方案还可能为Valkey项目提供一个未来逐步添加其他功能的平台。
"填补这一缺失的空白让我们拥有了更大的灵活性，现在我们可以开始以一种不同的方式来做事。"
"它提供了一个解耦层，未来我们可以在此基础上构建其他组件，"戴维斯继续说道。"填补这一缺失的空白让我们拥有了更大的灵活性，现在我们可以开始以一种不同的方式来做事。"
然而就目前而言，重点仍是将该项目交到用户手中。Percona已于9月下旬获得批准，将Valkey-proxy纳入Valkey项目，目前正将代码从私有代码库迁移至公共项目中。
目标是在10月底前将全部源代码公开，随后于12月发布候选版本，并在2027年初实现正式可用。
戴维斯表示，在此期间寻找边缘案例将至关重要，用户将开始针对自身应用测试该代理方案。Freshworks将是最早尝试的用户之一，戴维斯表示该公司已经作为早期用户和设计合作伙伴与Percona就Valkey-proxy展开合作，协助在开发过程中发现问题。
"这将是一个很好的测试案例，"他补充道。
