作者 | 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
这只是个例吗？
Redis 目前在 GitHub 上有 3.1 万个赞，1.2 万个 fork，然而在这条 issue 的下面，600 余个 emoji 表态里，有超过 480 个向下的大拇指，100 余个困惑的表情，却只有不到 60 个赞。
类似的事件是个例吗？当然不是。
早在 2014 年，django 也曾发生过类似事件，当时其 issue 的主题是：将 master/slave 出现的地方都改成 leader/follower。底下用户参与的评论不出意外也是一副懵逼脸，Are you serious？
issue 地址：
https://github.com/django/django/pull/2692
笔者又再扒了一下，发现 React 项目下也有人在跟进发起类似的 issue：黑名单（blacklist）太具攻击性！当然，目前还没什么人搭理他。
issue 地址：
https://github.com/facebook/react/issues/13604
除了主从复制的术语，外国程序员们还咬文嚼字过哪些词呢？
Twitter 上一位分不清是高级黑还是太较真的用户发了一条这样的推文，总结了下国外程序员们敏感的技术词汇：
对于这样的事件，中国程序员纷纷表示不能理解：
不就是一个针对计算机的术语么？怎么就冒犯人了？
吃饱了撑的，工作太闲不饱和啊，拉来中国加加班就好了。
没想到白左都进军技术圈了。
事实证明，还是国外的杠精比较厉害。
西方世界已经被政治正确占领了。
InfoQ 观点
Master/Slave 的中文翻译，一开始便避免了英文的奴隶一词，而巧妙地改成了主从复制。从这个角度看，其实国内对于 slave 一词的负面词性也是做了一些处理和规避的。
但是仅仅因为一个词性的问题，就大费周章去做一些牵一发而动全身的修改是否有必要？目前来看需要更加仔细斟酌，如果因为少部分批评者的言论就去修改细节乃至源码，是否会影响到更多未发声 的实际使用人群？
至于威胁如果不改就再也不用的人群，跟国内某些成天抵制这个抵制那个的群体又有何区别？项目开发者的确需要考虑用户的需求与感受，但不应该受用户的各色言论所左右。追求尽善尽美，最终可能既不善也不美。
智慧的 InfoQer 们，你们又是怎么看的？
閱讀更多 InfoQ 的文章
