作者 | 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 上一位分不清是高級黑還是太較真的用戶發了一條這樣的推文，總結了下國外程序員們敏感的技術詞彙：

對於這樣的事件，中國程序員紛紛表示不能理解：

不就是一個針對計算機的術語麼？怎麼就冒犯人了？

吃飽了撐的，工作太閒不飽和啊，拉來中國加加班就好了。

沒想到白左都進軍技術圈了。

事實證明，還是國外的槓精比較厲害。

西方世界已經被政治正確佔領了。

InfoQ 觀點

Master/Slave 的中文翻譯，一開始便避免了英文的奴隸一詞，而巧妙地改成了主從複製。從這個角度看，其實國內對於 slave 一詞的負面詞性也是做了一些處理和規避的。

但是僅僅因為一個詞性的問題，就大費周章去做一些牽一髮而動全身的修改是否有必要？目前來看需要更加仔細斟酌，如果因為少部分批評者的言論就去修改細節乃至源碼，是否會影響到更多未發聲

至於威脅如果不改就再也不用的人群，跟國內某些成天抵制這個抵制那個的群體又有何區別？項目開發者的確需要考慮用戶的需求與感受，但不應該受用戶的各色言論所左右。追求盡善盡美，最終可能既不善也不美。

智慧的 InfoQer 們，你們又是怎麼看的？

閱讀更多 InfoQ 的文章

關鍵字: 術語 其他詞彙 NoSQL