作者：antirez
翻譯：Kevin （公衆號：中間件小哥）
Redis 5 發佈幾周後，我開始着手實現 RESP3，經過幾天的工作，可以實現這一目標了。 RESP3 是 Redis 將從 Redis 6 開始使用的新的客戶端-服務器協議，https://github.com/antirez/resp3 上的規範清楚地說明我們舊協議 RESP2 的這種演進可以如何改進 Redis 生態系統，其中最重要的是，RESP3 比 RESP2 更加“語義化”。例如，它具有映射，集合（元素的無序列表），返回數據的屬性（可以使用輔助信息來增強回覆）等概念。最終目標是使新的 Redis 客戶端爲我們減少工作量，也就是說，只需確定一組固定規則，即可將每種回覆類型從 RESP3 轉換爲給定類型的客戶端庫編程語言。
在 Redis 的未來中，我看到了一些更智能的客戶端，更好的處理連接、流水線和狀態，並且顯然在面向用戶方面要簡單得多，以至於理想 Redis 客戶端就像：
result= redis.call（”GET”，keyname）;
當然最重要的是，你可以構建更高級的抽象，但是最底層應該看起來像這樣，並且返回的回覆不應要求對特定命令進行臨時過濾：RESP3 返回類型應包含足夠的信息以返回適當的數據類型，因此 HGETALL 將返回 RESP3“映射”，而 LRANGE 將返回“數組”，而 EXISTS 將返回 RESP3“布爾”。
即使客戶端庫不是專門爲處理它而設計的，新命令也能夠按預期工作。在 RESP2 中，該命令可能返回“缺少方法”之類的錯誤，但後來在客戶端庫中確實實現了該命令時，返回的類型發生了變化，從而引入了輕微的不兼容性。
但是，儘管新協議是對舊協議的增量改進，它還是會在客戶端庫側和在應用層中引入不兼容性。例如，由於 ZSCORE 現在將返回 double 類型，而不是 string 類型，因此應更新應用程序代碼，或者客戶端庫可以實現兼容性選項，該選項將把 RESP3 回覆變回其原始 RESP2 類型。
如果不對新協議進行適配，Lua 腳本也將不能正常工作，因爲 Lua 還將看到 redis.call（）命令返回的更多語義類型，同樣 Lua 將能夠返回在 RESP3 中實現的所有新數據類型。
因此，人們對我的決定感到恐懼：我將在 Redis 6 發行時僅支持 RESP3，沒有將 Redis 6 服務器切換到 RESP2 的兼容模式，因此您要麼升級客戶端庫並升級應用程序（或使用客戶端庫向後兼容模式），要麼無法切換到 Redis 6。
我這樣做是有充分的理由的，我想解釋爲什麼我要做出這個決定，以及如何減輕用戶和客戶端庫作者的問題，讓我們從緩解措施開始：
* Redis 6 發行後的 2 年內將完全支持 Redis5，所有關鍵內容都將移植到 Redis 5，並且補丁程序級別的發行版將一直可用。
* Redis 6 預計將在大約 1 年或一年半內發佈，但是 Redis 6 將在大約 1 個月內切換到 RESP3，因此，人們將使用、嘗試和處理不穩定的 Redis 版本，該版本長時間使用新協議。與許多其他軟件不同，Redis stable 具有大量的臨時用戶，這既是因爲它是 Github 上的默認分支，又因爲傳統上 Redis stable 從未真正如此不穩定，所以這會帶來很多先前的風險。
*我仍然不能 100％確定， 但是 Lua 腳本引擎可能具有兼容模式，以便返回與 Redis 5 相同的類型。但是，默認情況下不會啓用兼容性，並且會在調用 Redis 命令之前通過調用特殊的 redis.resp2_compat（）函數，選擇啓用每個執行的腳本。因此，無論其配置如何，每臺 Redis 6 服務器都將表現出相同的行爲，就像 Redis 在過去 10 年中一樣。
這些是緩解措施，這就是爲什麼我決定 Redis 6 不同時支持兩個版本的原因：
1）也許是完全無用的。如果人們將 Redis 6 切換到 RESP2 模式，他們就會一直停留在過去，在沒有 RESP2 支持的情況下等待 Redis 7 推出並打破一切。同時當您使用一個 Redis 6 時，根據配置的方式，你永遠不會知道它會回覆什麼，相同的客戶端庫可能會爲相同的命令返回哈希或數組。
2）沒有充分的理由，這需要更多的工作和更多的複雜性（請參閱“1”），許多命令將需要檢查舊協議，以查看以哪種格式答覆。
3）通過將 Redis 6 的新功能與協議的變更綁定在一起，我們爲用戶提供了充分的理由進行切換並移植其客戶端和應用程序。總有一天一切都會結束，我們可以專注於新事物。否則，我們將擁有一些這樣的 Redis 6 用戶，這些用戶已切換到新服務器以使用新功能，但仍使用舊協議，而且使用 Redis 7 時也會重蹈覆轍。
4）如果有人告訴你改寫客戶端庫是一件很糟糕的事情，那麼我可不敢苟同。是需要做一些更改，但是既然我正在實現服務器端，我發現它並不那麼糟糕，其實可怕的是，大多數客戶端的工作根本沒有報酬，而僅僅是因爲熱情和與他人分享的意願。我敢打賭，我們很快就會看到 RESP3 的許多實現。
5）RESP3 的設計使客戶端可以自動檢測它是 RESP2 還是 RESP3，並進行切換，因此新客戶端可以同時使用 Redis 6 和 Redis 5 以及之前版本。
我希望它可以闡明我的觀點及其背後的原因，同時希望在協議切換期間啓用的緩解措施可以使用戶相信這不會造成很“嚴重”的破壞。
更多優質中間件技術資訊/原創/翻譯文章/資料/乾貨，請關注“中間件小哥”公衆號！