3月21日，Redis Ltd. 宣布，Redis「記憶體數據儲存（in-memory data store）」計畫將從Redis 7.4版本開始，采用 非免費、原始碼可用 的授權合約。這一訊息不令人滿意，但並不完全出乎意料。
然而， 現在情況有些不同尋常，Redis 的替代品數量眾多 ，對於那些希望繼續使用免費軟體的人來說，至少有四種替代方案（包括現有的 KeyDB 分支和 Linux 基金會新宣布的 Valkey 計畫）。Linux 發行版、使用者和服務提供商會選擇哪個（或哪些）替代品來替換 Redis？
Redis簡史：回到故事最開始的地方
Redis的背景故事頗為復雜。Salvatore Sanfilippo（也被稱為「antirez」）最初是為了一個名為LLOOGG的即時日誌分析應用程式， 將 Redis 用作「一種不同的資料庫」 ，因為MySQL無法滿足他的需求。antirez 沒有建立關系型資料庫，而是將 Redis 設計為一個簡單的字典資料庫 ，該資料庫將鍵值對儲存在記憶體中——它的名字是「遠端字典伺服器（remote dictionary server）」的縮寫。
當然，隨著時間的推移，Redis 已經成熟並積累了更多功能。Redis 作為 NoSQL 運動的一部份迅速流行起來，antirez 在2010年被 VMware 聘用從事 Redis 的開發工作。2013年，他轉到了VMware 的衍生公司 Pivotal，並繼續從事該計畫的工作。
彼時，Redis 的受歡迎程度與日俱增，包括 Twitter 和 Pinterest 等知名公司都在使用它，並開始在 Linux 發行版中出現。它被打包進 Ubuntu 12.04（2012年4月）版本、Fedora 18（2013年1月）版本以及其他版本。2013年9月，Amazon Web Services（AWS）的 ElastiCache 服務增加了對Redis的支持，這既借勢於 Redis 的普及度，又提升了 Redis 的知名度。
2013年初，一家名為 Garantia Data 的初創公司開始提供Redis服務，將自己定位為「開源Redis」的更好替代品。2013年11月，Garantia 完成了第一輪融資，並考慮將公司名稱更改為 RedisDB。然而，在 antirez 的反對下，該公司於2014年初將名稱改為 Redis Labs。2015年，antirez 加入 Redis Labs，擔任開源開發負責人，直到2020年離職。
2018年，Redis Labs 對其提供核心資料庫的附加模組采用了新的授權合約。該公司選擇使用經過修改的 Apache License 2.0 版本，並增加了一個名為 Commons Clause 的條款，該條款限制銷售軟體或收取服務費用。做出這種轉變的理由是，雲提供商透過銷售基於他們未開發的開原始碼的服務來「利用開源社群」。當時，該公司 承諾 Redis「是 BSD 協定，並將永遠是 BSD 協定」 。
Redis Labs 並非唯一一家開始嘗試使用限制性授權合約的公司 ，尤其是獲得風險投資支持的資料庫公司，它們開始嘗試采用新的授權合約，確保能夠獨家銷售使用該軟體的服務。MariaDB 在2016年為名為 MaxScale 的產品建立了商業原始碼授權合約（BSL），而 MongoDB 則在2018年底推出了伺服器端公眾授權條款（SSPL）。最終，Redis Labs 為其模組采用了 SSPL 和自身 Redis 原始碼可用授權合約（RSAL）的雙授權合約方案。
2021年中，Redis 公司從名稱中去掉了「Labs」。在宣布名稱變更時，Redis 再次承諾將堅持開源，並表示公司名稱的更改「不會影響開源Redis的授權合約，該協定一直是 BSD 授權合約，並將繼續是 BSD 授權合約」。
該公司還建立了一種治理模型，將 Redis 的「架構、設計或理念」等重大決策權交給社群的「核心團隊」，人們期望該團隊的職責包括管理 Redis 本身的授權合約。雖然 Redis 的網站上已不再有治理頁面的連結，但該頁面仍可在網站「網際網路檔案館」的 Wayback Machine 上找到。頁面上列出了五位核心團隊成員，其中三位來自 Redis（Yossi Gotlieb、Oran Agra和Itamar Haber），另外兩位分別是來自阿裏巴巴的趙釗（Zhao Zhao）和來自 AWS 的 Madelyn Olson。
3月20日，Redis 宣布「所有未來的 Redis 版本都將使用原始碼可用授權合約」，具體來說是SSPL 和 RSAL。 Redis CEO Rowan Trollope 寫道，維持 BSD 授權合約現在「與我們成功推動Redis未來版本發展的能力相悖」。所謂「未來版本」指的是 Redis 7.4 及以後的版本。公告中的常見問題解答（FAQ）指出，根據公司的安全政策，安全修補程式將在原始三條款 BSD 授權合約下反向移植到以前的版本。
雲與開源之戰
使用限制性授權合約（如 SSPL 和 Redis 的 RSAL）的支持者試圖將此次事件定位為 AWS 等大型雲廠商與開源之間的戰鬥，其中使用限制是唯一合乎邏輯的選擇，而雲廠商是唯一的輸家。2019年，Redis Labs 時任 CEO Ofer Bengal 被引述稱，Redis 為 Redis 模組采用原始碼可用授權合約後，存在「許多不同的觀點」，但為了與雲提供商競爭，這是必要的。
「有些人譴責這種‘授權合約變更’。但在最初的爭議平息之後——尤其是一些其他公司提出類似概念之後——社群現在理解到， 原始的開源概念必須得到修正，因為它已不再適合當下時代 。在這個時代，雲公司利用其壟斷力量采用任何成功的開源計畫，而不為其做出任何貢獻。」
在3月20日的公告中，Redis 現任 CEO Trollope 寫道，「雲服務提供商只能在與 Redis（Redis程式碼的維護者）達成授權條款後，才能交付 Redis 7.4」，但「對於 Redis 開發者社群來說，情況沒有任何改變，他們將繼續在雙重授權下享受寬松的授權」。
使用「寬松授權」這一說法具有誤導性。Redis 能夠為7.4及後續版本采用非免費授權方案，是因為外部開發者在寬松的 BSD 授權下授予了他們的貢獻。SSPL 和 RSAL 的條款與開源社群中「寬松」一詞的常見用法不太符合。
此外，雲廠商未對Redis儲存庫做出送出（commit）貢獻的說法也站不住腳。
改變分銷模式
因此，很明顯，程式碼貢獻並不是（變更開源協定的）關鍵因素。Redis 是一家由風險投資支持的公司，自2011年以來經過多輪融資，已經籌集了超過3.5億美元的資金。該公司及其投資者似乎認為，他們可以安全地脫離開源，以嘗試獲得更多的收入。
如果他們有理由相信這是可行的，那麽 MongoDB 的情況或許能夠提供一些指導。 該公司在2017年上市，一年多後轉向了 SSPL。此後不久，主要的 Linux 發行版停止打包 MongoDB，因為該資料庫不再符合它們授權標準。但當時，MongoDB 已經瞄準了一個平台模型，該模型將鼓勵開發人員（及其雇主）使用MongoDB和輔助產品並為其付費。分發 MongoDB 的原始碼可用版本可以被視為一種 Loss Leader 策略（又稱賒本定價），以吸引他們打賭「不關心」開源的開發者。
正如 Redmonk 創始人 Stephen O'Grady 在2017年所寫的那樣：
「隨著越來越多的開發者開始主張對技術選擇和方向的控制權，即使在專有替代方案在技術上更優越的情況下，開源軟體的易用性也賦予了它巨大的市場優勢。在 即時下載的充足選項 A 和 理論上更優越的、但需要透過銷售人員才能獲得的選項 B 之間做出選擇，實際上並不是一個真正的選擇。」
但是，Grady 指出， 開源「通常不如基於服務的替代方案方便」，如果方便性的優先級更高，那麽開源就顯出短板了。 尤其是當像 MongoDB 這樣的供應商從專有供應商那裏學到「釘選客戶對業務有好處」時。
這對業務有好處嗎？MongoDB 的業務持續增長，客戶不斷增加，並在上一個財年實作了16.8億美元的收入。這一增幅超過 30%，其 Atlas 資料庫服務收入也增長了30%以上，這表明許多公司寧願付費使用服務，也不願嘗試自行托管。盡管如此，該公司仍然處於虧損狀態——同期虧損超3.45億美元。
但是，投資者可能更關心股價而不是實際利潤。該公司上市時的股價約為每股33美元，但現在已超過每股350美元。如果Redis能產生類似的結果，投資者可能會很高興。
雨後春筍般湧現的分支和替代品
正如 Redmonk 創始人 O'Grady 去年所寫的那樣，風險投資支持的供應商似乎已達成共識，他們可以脫離開源。特別是如果他們沒有「受到其他商業利益、基金會和其他感興趣的行業參與者的積極反對」。在這方面，Redis 可能誤判了行業情緒。
去年 Hashicorp 為其計畫采用 BSL 時，Terraform 計畫的分支在幾天內就出現了，並被 Linux 基金會以 OpenTofu 的名稱接納。3月28日，該基金會宣布支持 Valkey（Redis 7.2.4的直接分支），亞馬遜網路服務（AWS）、谷歌雲、甲骨文、易利信和 Snap 等公司都是該計畫的支持者。
Redis 授權證變更後幾天，Valkey 分支就出現了。 開發者Olson寫道，她和「一些前Redis貢獻者」已經開始使用一個原始的三條款 BSD 授權證來開發一個分支，並暫時命名為「placeholderkv」。Olson、Zhao、Viktor Söderqvist和Ping Xie被列為維護者。據 Olson說，這並不是 AWS 的 Redis 分支，而是「我試圖保持與社群的連續性」。KeyDB 也曾被考慮過，但它已經偏離到「缺少社群習慣使用的很多功能」的程度。
2019年出現的 KeyDB 分支，其建立主要是由於技術原因，而非授權原因。該計畫自稱是「比 Redis 更快的替代方案」，由 John Sully 和 Ben Schermel 建立。他們想要一個多執行緒版本，但未能說服Redis維護者朝這個方向發展。Sully 和 Schermel 創辦了一家同名公司 KeyDB，提供專有企業版。2022年，KeyDB 被 Snap 公司收購後，整個程式碼庫完全在三條款 BSD 授權證下開源。
KeyDB 作為直接替代方案的問題是，自從分支以來，它就沒有跟上 Redis 的步伐，它仍然缺少Redis 7 中的許多功能。Sully 表示，他幾乎沒有時間處理「不直接影響 Snap 」的問題，盡管該計畫「當然歡迎外部幫助，如果有社群興趣幫助，我們當然可以指定其他維護者」。3月22日，Sully 更新了另一個問題，表示他正在討論「可能」增加維護者，以使 KeyDB 更接近 Redis 7。目前尚不清楚 Valkey 是否會取代 KeyDB，但 Snap 公司的參與使得這一可能性在長期內看起來很大。
SourceHut 的創始人和 CEODrew DeVault，也建立了一個名為 Redict 的分支，該分支基於Redis 7.2.4，但選擇使用 LGPLv3 授權證。在他的公告貼文中，他表示選擇這種授權證是「經過深思熟慮的，平衡了許多考慮因素」。DeVault 希望選擇一個既是具備 copyleft（著佐權，無論是否進行修改，任何人都可以重新分發軟體，但必須同時保留軟體所具有的自由特性）又「盡可能易於使用者遵守」的授權證，並簡化與 Redis 相容的模組或用於在Redis中執行操作的 Lua 外掛程式整合。他還指出，Redict 將不會有貢獻者授權合約（CLA），但會要求貢獻者使用開發人員起源證書來驗證其貢獻。盡管他與 SourceHut 有關聯，但 DeVault 選擇在 Codeberg 上托管Redict，以「為熟悉 Redis 的 GitHub 社群的使用者提供舒適和熟悉的使用體驗」。
另一個值得一提的競爭者是微軟在3月18日宣布推出的 Garnet。根據公告，Garnet 自2021年以來一直由微軟研究院開發，它是一種遠端緩存儲存，可以緩存和管理與 Redis 相同型別的數據，旨在與Redis序列化協定相容。Garnet 使用 MIT授權證，使用 .NET C# 編寫，並不能直接替換Redis。然而，其 API 相容性頁面聲稱，它可以被視為一個「足夠接近的起點」，可以「無需修改即可與許多 Redis 客戶端一起使用」。盡管如此，並非所有Redis客戶端都與Garnet完全相容。例如，有使用者嘗試將 NodeJS 應用程式切換到 Garnet，但發現 Redis 的 FLUSHALL 命令目前尚不支持。目前在計畫的路線圖中，可以看到「添加對缺失 API 的支持」的功能建議。
對替代方案的考量
在 Linux 發行版面對不得不清理的亂局之際，Neal Gompa 在 Fedora 開發列表上發起討論，指出了授權證變更以及從 Fedora 中移除 Redis 的必要性。Jonathan Wright 回應說，KeyDB可能是一個替代方案；在授權證變更之前，他一直在「松散地打包」這個計畫。然而，他後來表示，對於那些希望替換Redis後續版本的人來說，KeyDB 將是一個「倒退並引發頭痛」的選擇。盡管如此，他在3月23日寫道，他已經準備好測試 Fedora 以及 EPEL 8 和9 的構建版本。
Valkey 宣布後不久，Wright 寫道，他將在標記版本釋出後盡快進行打包。他還表示，「預計Valkey 在大多數地方將成為 Redis 的‘事實上的’替代方案」。
Gompa 還在 openSUSE 的 Factory 討論列表上提出了這個問題。Dominique Leuenberger 在回復中列出了 18 個依賴 Tumbleweed 中 redis 軟體包的軟體包。最初的討論提到了 Redict 和 KeyDB 作為可能的替代品，但 Valkey 尚未公布。
對於社群發行版來說，尋找 Redis 的替代品並非唯一問題。 Jacob Michalskie 指出了 openSUSE 計畫中使用的多個服務也將需要 Redis 的替代品，其中包括用於 code.opensuse.org 的 Pagure 程式碼托管軟體（Fedora 也建立並使用了該軟體），以及 Discourse 論壇軟體。
Debian 貢獻者 Guillem Jover 為 KeyDB 送出了軟體包請求（RFP），作為潛在的 Redis 替代品。Jover 表示，他不確定自己是否能夠獨自承擔維護工作，但很樂意幫忙。在與 Jover 的電子信件交流中，他告訴我，他的公司已經從 Redis 6 遷移到 KeyDB，並且「過渡非常順利」。據Jover 稱，「與 Redis 7 相比，KeyDB 可能在某些功能上有所欠缺，但我們既沒有註意到我們缺少任何功能，也沒有覺得我們錯過了什麽。」
Jover 表示，現在判斷新的分支會否繼續得到維護還為時尚早，而且 Redict 的 LGPLv3 授權「也可能對生態系造成問題」。在 Valkey 宣布之後的一封後續電子信件中，他說：「我認為我們會進一步為 Debian 打包 KeyDB，如果它失敗了，至少可以隨時從那裏移除或過渡。」
前進之路
當然，現在預測這些分支中哪一個或多個會獲得顯著的吸重力還為時過早——但看起來Valkey很可能成為一個可靠的替代方案。擁有廣泛社群和行業支持的快速分支的可能性，應該讓那些期望在放棄開源後就能夠一帆風順的廠商停下來三思。
作者丨 Joe Brockmeier 編譯丨onehunnit
來源丨 lwn.net/SubscriberLink/966631/6bf2063136effa1e/
*本文為dbaplus社群編譯整理，如需轉載請取得授權並標明出處！ 歡迎廣大技術人員投稿，投稿信箱：[email protected]
活動推薦
2024 XCOPS智慧運維管理人年會·廣州站將於5月24日舉辦 ，深究大模型、AI Agent等新興技術如何落地於運維領域，賦能企業智慧運維水平提升，構建全面運維自治能力！ 碼上報名，享早鳥優惠。
