作者 | 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 們，你們又是怎么看的？

總結

以上是生活随笔為你收集整理的Redis作者摊上事了：多人要求修改Redis主从复制术语master/slave的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。