为什么 Redis 6 只支持 RESP3 ？

作者：antirez

翻译：Kevin （公众号：中间件小哥）

Redis 5 发布几周后，我开始着手实现 RESP3，经过几天的工作，可以实现这一目标了。 RESP3 是 Redis 将从 Redis 6 开始使用的新的客户端-服务器协议，https://github.com/antirez/resp3 上的规范清楚地说明我们旧协议 RESP2 的这种演进可以如何改进 Redis 生态系统，其中最重要的是，RESP3 比 RESP2 更加“语义化”。例如，它具有映射，集合（元素的无序列表），返回数据的属性（可以使用辅助信息来增强回复）等概念。最终目标是使新的 Redis 客户端为我们减少工作量，也就是说，只需确定一组固定规则，即可将每种回复类型从 RESP3 转换为给定类型的客户端库编程语言。

在 Redis 的未来中，我看到了一些更智能的客户端，更好的处理连接、流水线和状态，并且显然在面向用户方面要简单得多，以至于理想 Redis 客户端就像：

result= redis.call（”GET”，keyname）;

当然最重要的是，你可以构建更高级的抽象，但是最底层应该看起来像这样，并且返回的回复不应要求对特定命令进行临时过滤：RESP3 返回类型应包含足够的信息以返回适当的数据类型，因此 HGETALL 将返回 RESP3“映射”，而 LRANGE 将返回“数组”，而 EXISTS 将返回 RESP3“布尔”。

即使客户端库不是专门为处理它而设计的，新命令也能够按预期工作。在 RESP2 中，该命令可能返回“缺少方法”之类的错误，但后来在客户端库中确实实现了该命令时，返回的类型发生了变化，从而引入了轻微的不兼容性。

但是，尽管新协议是对旧协议的增量改进，它还是会在客户端库侧和在应用层中引入不兼容性。例如，由于 ZSCORE 现在将返回 double 类型，而不是 string 类型，因此应更新应用程序代码，或者客户端库可以实现兼容性选项，该选项将把 RESP3 回复变回其原始 RESP2 类型。

如果不对新协议进行适配，Lua 脚本也将不能正常工作，因为 Lua 还将看到 redis.call（）命令返回的更多语义类型，同样 Lua 将能够返回在 RESP3 中实现的所有新数据类型。

因此，人们对我的决定感到恐惧：我将在 Redis 6 发行时仅支持 RESP3，没有将 Redis 6 服务器切换到 RESP2 的兼容模式，因此您要么升级客户端库并升级应用程序（或使用客户端库向后兼容模式），要么无法切换到 Redis 6。

我这样做是有充分的理由的，我想解释为什么我要做出这个决定，以及如何减轻用户和客户端库作者的问题，让我们从缓解措施开始：

* Redis 6 发行后的 2 年内将完全支持 Redis5，所有关键内容都将移植到 Redis 5，并且补丁程序级别的发行版将一直可用。

* Redis 6 预计将在大约 1 年或一年半内发布，但是 Redis 6 将在大约 1 个月内切换到 RESP3，因此，人们将使用、尝试和处理不稳定的 Redis 版本，该版本长时间使用新协议。与许多其他软件不同，Redis stable 具有大量的临时用户，这既是因为它是 Github 上的默认分支，又因为传统上 Redis stable 从未真正如此不稳定，所以这会带来很多先前的风险。

*我仍然不能 100％确定， 但是 Lua 脚本引擎可能具有兼容模式，以便返回与 Redis 5 相同的类型。但是，默认情况下不会启用兼容性，并且会在调用 Redis 命令之前通过调用特殊的 redis.resp2_compat（）函数，选择启用每个执行的脚本。因此，无论其配置如何，每台 Redis 6 服务器都将表现出相同的行为，就像 Redis 在过去 10 年中一样。

这些是缓解措施，这就是为什么我决定 Redis 6 不同时支持两个版本的原因：

1）也许是完全无用的。如果人们将 Redis 6 切换到 RESP2 模式，他们就会一直停留在过去，在没有 RESP2 支持的情况下等待 Redis 7 推出并打破一切。同时当您使用一个 Redis 6 时，根据配置的方式，你永远不会知道它会回复什么，相同的客户端库可能会为相同的命令返回哈希或数组。

2）没有充分的理由，这需要更多的工作和更多的复杂性（请参阅“1”），许多命令将需要检查旧协议，以查看以哪种格式答复。

3）通过将 Redis 6 的新功能与协议的变更绑定在一起，我们为用户提供了充分的理由进行切换并移植其客户端和应用程序。总有一天一切都会结束，我们可以专注于新事物。否则，我们将拥有一些这样的 Redis 6 用户，这些用户已切换到新服务器以使用新功能，但仍使用旧协议，而且使用 Redis 7 时也会重蹈覆辙。

4）如果有人告诉你改写客户端库是一件很糟糕的事情，那么我可不敢苟同。是需要做一些更改，但是既然我正在实现服务器端，我发现它并不那么糟糕，其实可怕的是，大多数客户端的工作根本没有报酬，而仅仅是因为热情和与他人分享的意愿。我敢打赌，我们很快就会看到 RESP3 的许多实现。

5）RESP3 的设计使客户端可以自动检测它是 RESP2 还是 RESP3，并进行切换，因此新客户端可以同时使用 Redis 6 和 Redis 5 以及之前版本。

我希望它可以阐明我的观点及其背后的原因，同时希望在协议切换期间启用的缓解措施可以使用户相信这不会造成很“严重”的破坏。

更多优质中间件技术资讯/原创/翻译文章/资料/干货，请关注“中间件小哥”公众号！