世界上最快的記憶體資料庫橫空出世，比 Redis 快 25 倍，Star 數飆升，殺瘋了！

來源｜ Info ，整理 | 鈺瑩、Tina 回擊就代表輸了？！今年年中，一位前谷歌、前亞馬遜的工程師推出了他創作的開源記憶體數據緩存系統 Dragonfly，用 C/C++ 編寫，基於 BSL 許可（Business Source License）分發。根據過往的基準測試結果來看， Drago ...

來源｜ Info ，整理 | 鈺瑩、Tina

回擊就代表輸了？！

今年年中，一位前谷歌、前亞馬遜的工程師推出了他創作的開源記憶體數據緩存系統 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 誕生了十多年，這時從頭開始設計一個緩存系統，可以拋棄歷史包袱，更好地利用資源。

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 的方式。“在單台機器上運行集群，只是為了能夠使用超過 1 個 core" 是額外的複雜性，人們只有在別無選擇的情況下才會這樣做，如果競爭者無論有多少個 core 都能 “just works"，那麼最好能有更容易的設置。

另外，最近面試整理了 Java 最新、最全的面試題：

https://www.javastack.cn/mst/

還有人表示，這篇文章是 Redis 團隊在有禮貌地否認“Dragonfly 是最快的緩存系統”，但更多網友表示，Redis 發文章進行“回擊”，就已經代表他們的營銷部門輸了：

“Redis 投入如此多的工程精力來寫這麼一篇文章，還對 Reids/Dragonfly 進行了基準測試，這是對 Dragonfly 的極大贊美。”

“我很高興 Redis 發了這篇文章，因此我必須要去瞭解一下 Dragonfly，它看起來很棒。”

Redis 博客文章翻譯：

作為一項基礎性技術，每隔段時間總有人跳出來，想要替 Redis 換套新架構。

幾年之前，KeyDB 就提出了這類方案，而最近亮相的 Dragonfly 則聲稱是速度最快的 Redis 相容型記憶體數據存儲系統。沒錯，這類方案的涌現當然帶來了不少值得關註和討論的有趣技術 / 思路。在 Redis，我們也喜歡迎接挑戰，重新審視 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 實例，我們可以：

使用一套完全無共用的架構實現縱向與橫向線性擴展。與純縱向擴展的多線程架構相比，這套方案能始終提供更好的架構靈活性。
提高複製速度，因為複製操作是跨多個進程併發完成的。
從虛擬機故障中快速恢復。因為新虛擬機的 Redis 實例將同時填充來自多個外部 Redis 實例的數據。

將每個 Redis 進程限製為合理的大小

我們不允許單一 Redis 進程的大小超過 25 GB（運行 Redis on Flash 時上限為 50 GB）。如此一來，我們就能：

在出於複製、快照保存、Append Only File（AOF）重寫等目的進行 Redis 分叉時，既享受邊寫邊複製的好處，又無需承擔繁重的記憶體開銷。若非如此，我們（或客戶）將需要支付昂貴的資源成本。
為了輕鬆管理整個集群，我們希望每個 Redis 實例都保持在較小體量，藉此加快遷移分片、重新分片、擴展和重新均衡等的執行速度。

橫向擴展才是最重要的

以橫向擴展的方式靈活運行記憶體數據存儲，是 Redis 獲得成功的關鍵。

下麵來看具體原因：

更佳彈性——我們在集群中使用的節點越多，整個集群的健壯性就越強。例如，如果您在三節點集群上運行數據集，且其中一個節點發生降級，則代表有三分之一的集群無法運行；但如果是在九節點集群上運行數據集，同樣是其中一個節點發生降級，則只有九分之一的集群無法運行。
易於擴展——在橫向擴展系統當中，向集群添加一個額外節點、並將數據集的一部分遷移到其中要容易得多。與之對應，在縱向擴展系統中，我們只能直接引入一個更大的節點並複製整個數據集……這是個漫長的過程，而且期間隨時有可能鬧出麻煩。
逐步擴展更具成本效益——縱向擴展，尤其是雲環境下的縱向擴展，往往對應高昂的成本。在多數情況下，即使只需要向數據集內添加幾 GB 內容，也需要將實例大小翻倍。
高吞吐——在 Redis，我們看到很多客戶會在小型數據集上運行高吞吐量工作負載，即具有極高的網路帶寬及 / 或每秒數據包（PPS）需求。我們以每秒操作數 100 萬 + 的 1 GB 大小數據集為例，相較於使用單節點 c6gn.16xlarge 集群（128 GB 記憶體、64 個 CPU 加 100 Gbps 傳輸帶寬，每小時使用成本 2.7684 美元），三個 c6gb.xlarge 節點（8 GB 記憶體、4 個 CPU 外加最高 25 Gbps 傳輸帶寬，每小時 0.1786 美元）構成的集群能夠將運行成本拉低 20%，而且健壯性反而更高。既然成本效益出色、彈性更強且吞吐量反超，那橫向擴展無疑就是比縱向擴展更好的選擇。
貼近 NUMA 架構——縱向擴展還要求使用能容納更多核心和大容量 DRAM 的雙插槽伺服器；相比之下，Redis 這樣的多處理架構其實更適應 NUMA 架構，因為其行為特征就接近一種由多個較小節點組成的網路。但必須承認，NUMA 跟多線程架構之間也有天然衝突。根據我們在其他多線程項目中的經驗，NUMA 可能令記憶體數據存儲的性能降低達 80%。
存儲吞吐量限制——AWS EBS 等外部磁碟的擴展速度，顯然不及記憶體和 CPU。事實上，雲服務商會根據所使用設備的類型添加存儲吞吐量限制。因此，避免吞吐量限制、滿足數據高持久性要求的唯一辦法，就是使用橫向擴展——即添加更多節點和更多的配套網路附加磁碟。
臨時磁碟——臨時磁碟是一種將 Redis 運行在 SSD 上的絕佳方式（其中 SSD 用於替代 DRAM，而非充當持久存儲介質），能夠在保持 Redis 極高速度的同時將資料庫成本保持在磁碟級水平。但臨時磁碟也有其上限，一旦逼近這一上限，我們還需要進一步擴展容量——這時候，更好的辦法仍然是添加更多節點、引入更多臨時磁碟。所以，橫向擴展繼續勝出。
商品硬體——最後，我們的很多客戶會在本地數據中心、私有雲甚至是小型邊緣數據中心內運行 Redis。在這類環境中，絕大多數設備記憶體不超過 64 GB、CPU 不超過 8 個，所以唯一可行的擴展方式就只有橫向擴展。

總結

我們仍然欣賞由社區提出的種種有趣思路和技術方案。

其中一部分有望在未來進入 Redis（我們已經開始研究 io_uring、更現代的字典、更豐富的線程使用策略等）。

但在可預見的未來，我們不會放棄 Redis 所堅守的無共用、多進程等基本架構原則。這種設計不僅具備最佳性能、可擴展性和彈性，同時也能夠支持記憶體內實時數據平臺所需要的各類部署架構。

附錄：Redis 7.0 對 Draonfly 基準測試細節

Redis 教程推薦看這裡：https://www.javastack.cn/database/redis/

結果概述

版本：

我們使用 Redis 7.0.0，直接通過源碼構建
Dragonfly 使用的則是構建自 https://github.com/Dragonfly/dragonfly#building-from-source 的 6 月 3 日版源碼（hash=e806e6ccd8c79e002f721a1a5ecb847bd7a06489）

目標：

驗證 Dragonfly 公佈的結果是否可重現，並確定檢索結果的完整條件（鑒於 memtier_benchmark、操作系統版本等信息有所缺失）
確定 AWS c6gn.16xlarge 實例上可實現的最佳 OSS Redis 7.0.0 集群性能，並與 Dragonfly 的基準測試結果相比較

客戶端配置：

OSS Redis 7.0 解決方案需要大量接入 Redis 集群的開放連接，因為每個 memtier_benchmark 線程都需要連接到所有分片
OSS Redis 7.0 解決方案在使用兩個 memtier_benchmark 進程時成績最好，而且為了與 Dragonfly 基準相適應，這兩個進程運行在同樣的客戶端虛擬機上

資源利用與配置優化：

OSS Redis 集群在 40 個主分片的配置下性能表現最佳，對應的就是虛擬機上有 24 個備用 vCPU。雖然設備資源仍未得到全部利用，但我們發現繼續增加分片數量已經沒有意義，反而會拉低整體性能。我們仍在調查具體原因。
另一方面，Dragonfly 解決方案徹底耗盡了虛擬機性能，所有 64 上 vCPU 均達到了 100% 利用率。
在兩種解決方案中，我們調整了客戶端配置以實現最佳結果。如下所示，我們成功重現了大部分 Dragonfly 基準數據，甚至在 30 通道條件下得出了比項目方更高的測試成績。
本次測試強調與 Dragonfly 測試環境保持一致，如果調整測試環境，Redis 的成績還有望進一步提升。

最後，我們還發現 Redis 和 Dragonfly 都不受網路每秒數據包或傳輸帶寬的限制。

我們已經確認在 2 個虛擬機間（分別作為客戶端和伺服器，且均使用 c6gn.16xlarge 實例）使用 TCP 傳遞約 300 B 大小的數據包負載時，可以讓每秒數據包傳輸量達到 1000 萬以上、傳輸帶寬超過 30 Gbps。

分析結果

單 GET 通道延遲低於 1 毫秒：

OSS Redis：每秒 443 萬次操作，其中延遲平均值與第 50 百分位值均達到亞毫秒級別。平均客戶端延遲為 0.383 毫秒。
Dragonfly 聲稱每秒 400 萬次操作：
- 我們成功重現至每秒 380 萬次操作，平均客戶端延遲為 0.390 毫秒
Redis 對 Dragonfly——Redis 吞吐量比 Dragonfly 聲稱的結果高出 10%，比我們成功重現的 Dragonfly 結果高 18%。

30 條 GET 通道：

OSS Redis：每秒 2290 萬次操作，客戶端平均延遲為 2.239 毫秒
Dragonfly 聲稱每秒可達 1500 萬次操作：
- 我們成功重現了每秒 1590 萬次操作，客戶端平均延遲為 3.99 毫秒
Redis 對 Dragonfly——與 Dragonfly 的重現結果和聲稱結果相比，Redis 分別勝出 43% 和 52%

單 SET 通道延遲低於 1 毫秒：

OSS Redis：每秒 474 萬次操作，延遲平均值與第 50 百分位值均達到亞毫秒級。客戶端平均延遲為 0.391 毫秒
Dragonfly 聲稱每秒 400 萬次操作：
- 我們成功重現了每秒 400 萬次操作，客戶端平均延遲為 0.500 毫秒
Redis 對 Dragonfly——與 Dragonfly 的重現結果和聲稱結果相比，Redis 均勝出 19%

30 條 SET 通道:

OSS Redis：每秒 1985 萬次操作，客戶端平均延遲為 2.879 毫秒
Dragonfly 聲稱每秒 1000 萬次操作：
- 我們成功重現了每秒 1400 萬次操作，客戶端平均延遲為 4.203 毫秒
Redis 對 Dragonfly——與 Dragonfly 的重現結果和聲稱結果相比，Redis 分別勝出 42% 和 99%

用於各變體的 memtier_benchmark 命令：

單 GET 通道延遲低於 1 毫秒

Redis:2X: memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram
Dragonfly:memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram

30 條 GET 通道

Redis:2X: memtier_benchmark –ratio 0:1 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram –pipeline 30
Dragonfly:memtier_benchmark –ratio 0:1 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30

單 SET 通道延遲低於 1 毫秒

Redis:2X: memtier_benchmark –ratio 1:0 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram
Dragonfly:memtier_benchmark –ratio 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram

30 條 SET 通道

Redis:2X: memtier_benchmark –ratio 1:0 -t 24 -c 1 –test-time 180 –distinct-client-seed -d 256 –cluster-mode -s 10.3.1.88 –port 30001 –key-maximum 1000000 –hide-histogram –pipeline 30
Dragonfly:memtier_benchmark –ratio 1:0 -t 55 -c 30 -n 200000 –distinct-client-seed -d 256 -s 10.3.1.6 –key-maximum 1000000 –hide-histogram –pipeline 30