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

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 社区时,我不想成为它的国王,我需要为这里的人们服务。然而,一个信号不需要在整个社区中造成许多问题,所以这是我建议做的。

短期变化

首先,我们做以下工作:

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

长期变化

  1. 在未来的某个时刻,写一个 INFO 的替代品,因为无论如何 INFO 不是 Redis 数据收集的未来...... 它太有限,一次提供太多信息,客户需要解析它。我们将设计一个新命令,在新命令中我们不会引用从属,而是复制到副本。
  2. 当我们打算破坏很多东西时,比如包含 RESPv3,也可以将 ROLE 命令更改为输出副本而不是 slave。如果客户端检测到它是 RESPv3 服务器,那么他们现在认为 ROLE 将以不同方式回复,也就是说,它将以“replica”进行应答,而不是“slave”。
  3. 首先,由于一些技术原因,我们需要在内部替换很多东西,这样很多 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 上一位分不清是高级黑还是太较真的用户发了一条这样的推文,总结了下国外程序员们敏感的技术词汇:

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


对于这样的事件,中国程序员纷纷表示不能理解:

不就是一个针对计算机的术语么?怎么就冒犯人了?
吃饱了撑的,工作太闲不饱和啊,拉来中国加加班就好了。
没想到白左都进军技术圈了。
事实证明,还是国外的杠精比较厉害。
西方世界已经被政治正确占领了。

InfoQ 观点

Master/Slave 的中文翻译,一开始便避免了英文的奴隶一词,而巧妙地改成了主从复制。从这个角度看,其实国内对于 slave 一词的负面词性也是做了一些处理和规避的。

但是仅仅因为一个词性的问题,就大费周章去做一些牵一发而动全身的修改是否有必要?目前来看需要更加仔细斟酌,如果因为少部分批评者的言论就去修改细节乃至源码,是否会影响到更多未发声

的实际使用人群?

至于威胁如果不改就再也不用的人群,跟国内某些成天抵制这个抵制那个的群体又有何区别?项目开发者的确需要考虑用户的需求与感受,但不应该受用户的各色言论所左右。追求尽善尽美,最终可能既不善也不美。


智慧的 InfoQer 们,你们又是怎么看的?


分享到:


相關文章: