Redis作者摊上事了：多人要求修改Redis主从复制术语master/slave

作者 | ANTIREZ、小智

近日，Redis 作者在 GitHub 上发起了一个“用其他词汇代替 Redis 的主从复制术语”的 issue。有人认为 Redis 中的术语 master/slave （主人 / 奴隶）冒犯到了别人，要求 Redis 作者 ANTIREZ 修改这个术语，甚至连 ruby on rails 的作者 DHH 都在表态。本文对此 issue 做了简单翻译，以飨读者。

背景介绍

包容性领域的积极分子多次要求 Redis 使用不同于主从的术语，特别是与奴隶制无关的术语。就我个人而言，我认为这种努力不值得，但这是我个人的观点。另一方面，不同的 Twitter 话题，尤其是与 DHH 的交流，以及许多人开始建议不再使用 Redis 的账户，让我思考了一些事情。具体来说，我认为对于愿意使用 Redis 的工程师来说，这可能是一个问题。因为他们认为将其应用于某些工作场所，Redis 中使用的术语可能产生问题。我不想由于我的想法，给 Redis 社区制造麻烦。

与此同时，一旦我开始表现得对这些术语重新命名的可能性更加开放，我开始收到更多人的抱怨，这些人多年来一直为该项目做出贡献，我们不得不做的事情让我们感到恼火。我们不会以任何方式更改系统，这样做的代价太大，而且会产生兼容性问题。

我的想法是在所有这些事情之间找到一个中间地带，因为术语的变化会带来很多问题：

PRs 将不再适用；
我们有一些命令，例如 INFO 和 ROLE，它们用包含从属项的协议进行应答；
源码中出现了 1500 次 slave 术语；
拥有 private trees 并根据需要合并的人会遇到很多问题。

所以这种改变可能会产生很多问题。此外，Twitter 上的许多人不理解 Redis 的向后兼容性文化。Redis 5 现在发布的候选版本与 Redis 发布的第一个稳定版本是向后兼容的。这种文化确保升级操作简单，在客户端没有无用的工作要做等等。这是一件值得考虑的大事。

可能的解决方案

然而，我想发出一个信号，因为在推特上，很多人发起要求改变这个术语。当我处理 Redis 社区时，我不想成为它的国王，我需要为这里的人们服务。然而，一个信号不需要在整个社区中造成许多问题，所以这是我建议做的。

短期变化

首先，我们做以下工作：

更改文档以引用主副本。如果我们选择 master，这在 2018 年不会冒犯任何人 (明年我们再看…)，至少改变的事情会少一些。副本非常常用，并且已经在 Redis 集群中使用；
改 SLAVEOF 为 REPLICAOF。你仍然可以使用 SLAVEOF，但现在有了选择；
请参阅文档内的副本；
将配置指令也从 slaveof 更改为 replicaof；
作为第一步，让所有内部组件在源级别仍然是从属的。现在改变所有这些将是一个大问题，因为我们处于发布候选状态，并且有太多的待处理 PRs。
继续以 slave 回复 INFO 和 ROLE，因为这暂时是一个重大的破坏。

长期变化

在未来的某个时刻，写一个 INFO 的替代品，因为无论如何 INFO 不是 Redis 数据收集的未来...... 它太有限，一次提供太多信息，客户需要解析它。我们将设计一个新命令，在新命令中我们不会引用从属，而是复制到副本。
当我们打算破坏很多东西时，比如包含 RESPv3，也可以将 ROLE 命令更改为输出副本而不是 slave。如果客户端检测到它是 RESPv3 服务器，那么他们现在认为 ROLE 将以不同方式回复，也就是说，它将以“replica”进行应答，而不是“slave”。
首先，由于一些技术原因，我们需要在内部替换很多东西，这样很多 PRs 就不适用了，还要切换变量和函数名。然而，作为一种脱离背景的变化，这是不可接受的，因为它会导致很多问题。我们必须在某个地方进行更大的改变。

我们不会提供第二步的 ETA，我希望社区能理解我们的技术问题。然而，我希望人们能意识到至少有人在听。某些要求改变的人声音洪亮，充满敌意，但我在 Twitter 上看到很多人只是平静地要求看到一些改善。有一件事是肯定的：主从术语在未来不会被使用，所以让我们一起做这个改变，并继续我们的实际工作，即：使 Redis 更好和可用。

我知道这可能看起来很恶心，但我希望这里的大多数评论都是由最近几年在 redis land 做了一些事情的人提供的。人们发送 PRs、打开问题、编写客户端库、大规模使用 Redis 并定期提供提示等等，如果如果您是 Github 的临时用户，在这里跳出来说“改变它!”这只会制造噪音。谢谢。

issue 链接：

https://github.com/antirez/redis/issues/5335