今年年中，壹位前谷歌、前亞馬遜的工程師推出了他創作的開源內存數據緩存系統 Dragonfly，用 C/C++ 編寫，基於 BSL 許可（Business Source License）分發。
根據過往的基準測試結果來看， Dragonfly 可能是世界上最快的內存存儲系統，它提供了對 Memcached 和 Redis 協議的支持，但能夠以更高的性能進行查詢，運行時內存消耗也更少。與 Redis 相比，Dragonfly 在典型工作負載下實現了 25 倍的性能提升；單個 Dragonfly 服務器每秒可以處理數百萬個請求；在 5GB 存儲測試中，Dragonfly 所需的內存比 Redis 少 30%。
作為壹個開源軟件，Dragonfly 在短短兩個月獲得了 9.2K GitHub 星，177 個 fork 分支。雖然這些年，湧現了不少類似的 Redis 兼容型內存數據存儲系統，例如 KeyDB、Skytable，但是都沒能像這次這麽“轟動”。畢竟 Redis 誕生了十多年，這時從頭開始設計壹個緩存系統，可以拋棄 歷史 包袱，更好地利用資源。
為回擊新冒頭的 Dragonfly，Redis 的聯合創始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架構師 Yossi Gottlieb、Redis Labs 的性能工程師 Filipe Oliveira 聯合發布了壹篇名為《13 年後，Redis 是否需要新的架構》的文章。
在文章中，他們特地給出了自認更加公平的 Redis 7.0 vs. Dragonfly 基準測試結果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及壹些有關 Redis 架構的觀點和思考，以證明 “為什麽 Redis 的架構仍然是內存實時數據存儲（緩存、數據庫，以及介於兩者之間的所有內容）的最佳架構”。
雖然他們強調 Redis 架構仍然是同類最佳，但也沒法忽視 Dragonfly 這些新軟件提供的壹些新鮮、有趣的想法和技術，Redis 表示其中的壹些甚至有可能在未來進入 Redis（比如已經開始研究的 io_uring 、更現代的 dictionaries、更有策略地使用線程等）。
另外，Redis 指出 Dragonfly 基準測試的比較方法 “不能代表 Redis 在現實世界中的運行方式” 。對此，Reddit 上有網友反駁稱：
還有人表示，這篇文章是 Redis 團隊在有禮貌地否認“Dragonfly 是最快的緩存系統”，但更多網友表示，Redis 發文章進行“回擊”，就已經代表他們的營銷部門輸了：
我們當然壹直在尋求為 Redis 提升性能、擴充功能的創新方向，但這裏我們想聊聊自己的觀點和思考，闡釋 Redis 時至今日為何仍是最出色的實時內存數據存儲（包括緩存、數據庫以及介於二者之間的壹切）方案之壹。
接下來，我們將重點介紹 Redis 對於速度和架構差異的觀點，再以此為基礎做出比較。在文章的最後，我們還會提供基準測試結果、與 Dragonfly 項目的詳盡性能比較信息，歡迎大家自行對比參考。
Dragonfly 基準測試其實是將獨立單進程 Redis 實例（只能使用單壹核心）與多線程 Dragonfly 實例（可以使用虛擬機 / 服務器上的全部可用核心）進行比較。很明顯，這樣的粗暴比較並不能代表 Redis 在現實場景下的運行狀態。作為技術構建者，我們希望更確切地把握自有技術同其他方案間的差異，所以這裏我們做了壹點公平性調整：將具有 40 個分片的 Redis 7.0 集群（可使用其中的大部分實例核心）與 Dragonfly 團隊在基準測試中使用的最大實例類型（AWS c4gn.16xlarge）進行性能比較。
在這輪測試中，我們看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而這還僅僅只用到全部 64 個 vCore 中的 40 個。
在我們看來，每壹位多線程項目的開發者在立項之前，都會根據以往工作中經歷過的痛點來指導架構決策。我們也承認，在多核設備上運行單壹 Redis 進程（這類設備往往提供幾十個核心和數百 GB 內存）確實存在資源無法充分利用的問題。但 Redis 在設計之初也確實沒有考慮到這壹點，而且眾多 Redis 服務商已經拿出了相應的解決方案，借此在市場上占得壹席之地。
Redis 通過運行多個進程（使用 Redis 集群）實現橫向擴展，包括在單壹雲實例背景下也是如此。在 Redis 公司，我們進壹步拓展這個概念並建立起 Redis Enterprise。Redis Enterprise 提供管理層，允許用戶大規模運行 Redis，並默認啟用高可用性、即時故障轉移、數據持久與備份等功能。
下面，我們打算分享幕後使用的壹些原則，向大家介紹我們如何為 Redis 的生產應用設計良好的工程實踐。
通過在每個虛擬機上運行多個 Redis 實例，我們可以：
我們不允許單壹 Redis 進程的大小超過 25 GB（運行 Redis on Flash 時上限為 50 GB）。如此壹來，我們就能：
以橫向擴展的方式靈活運行內存數據存儲，是 Redis 獲得成功的關鍵。下面來看具體原因：
我們仍然欣賞由社區提出的種種有趣思路和技術方案。其中壹部分有望在未來進入 Redis（我們已經開始研究 io_uring、更現代的字典、更豐富的線程使用策略等）。但在可預見的未來，我們不會放棄 Redis 所堅守的無***享、多進程等基本架構原則。這種設計不僅具備最佳性能、可擴展性和彈性，同時也能夠支持內存內實時數據平臺所需要的各類部署架構。
附錄：Redis 7.0 對 Draonfly 基準測試細節
版本：
目標：
客戶端配置：
資源利用與配置優化：
最後，我們還發現 Redis 和 Dragonfly 都不受網絡每秒數據包或傳輸帶寬的限制。我們已經確認在 2 個虛擬機間（分別作為客戶端和服務器，且均使用 c6gn.16xlarge 實例）使用 TCP 傳遞約 300 B 大小的數據包負載時，可以讓每秒數據包傳輸量達到 1000 萬以上、傳輸帶寬超過 30 Gbps。
單 GET 通道延遲低於 1 毫秒：
30 條 GET 通道：
單 SET 通道延遲低於 1 毫秒：
30 條 SET 通道:
用於各變體的 memtier_benchmark 命令：
單 GET 通道延遲低於 1 毫秒
30 條 GET 通道
單 SET 通道延遲低於 1 毫秒
30 條 SET 通道
在本次比較測試中，我們在客戶端（用於運行 memtier_benchmark）和服務器（用於運行 Redis 和 Dragonfly）使用了相同的虛擬機類型，具體規格為：
參考鏈接：
/article/AlF5NIhHdskayl0MTyQG