一、Redis 博客文章翻譯

二、速度問題

三、架構差異

四、總結

今年年中，一位前谷歌、前亞馬遜的工程師推出了他創作的開源內存數據緩存系統 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 的方式。“在單臺機器上運行集群，只是為了能夠使用超過 1 個 core" 是額外的復雜性，人們只有在別無選擇的情況下才會這樣做，如果競爭者無論有多少個 core 都能 “just works"，那么最好能有更容易的設置。

還有人表示，這篇文章是 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 個。

三、架構差異

1、背景信息

在我們看來，每一位多線程項目的開發者在立項之前，都會根據以往工作中經歷過的痛點來指導架構決策。我們也承認，在多核設備上運行單一 Redis 進程（這類設備往往提供幾十個核心和數百 GB 內存）確實存在資源無法充分利用的問題。但 Redis 在設計之初也確實沒有考慮到這一點，而且眾多 Redis 服務商已經拿出了相應的解決方案，借此在市場上占得一席之地。

Redis 通過運行多個進程（使用 Redis 集群）實現橫向擴展，包括在單一云實例背景下也是如此。在 Redis 公司，我們進一步拓展這個概念并建立起 Redis Enterprise。Redis Enterprise 提供管理層，允許用戶大規模運行 Redis，并默認啟用高可用性、即時故障轉移、數據持久與備份等功能。

下面，我們打算分享幕后使用的一些原則，向大家介紹我們如何為 Redis 的生產應用設計良好的工程實踐。

2、架構設計原則

1）在每個虛擬機上運行多個 Redis 實例

通過在每個虛擬機上運行多個 Redis 實例，我們可以：

使用一套完全無共享的架構實現縱向與橫向線性擴展。與純縱向擴展的多線程架構相比，這套方案能始終提供更好的架構靈活性。

提高復制速度，因為復制操作是跨多個進程并發完成的。

從虛擬機故障中快速恢復。因為新虛擬機的 Redis 實例將同時填充來自多個外部 Redis 實例的數據。

2）將每個 Redis 進程限制為合理的大小

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

在出于復制、快照保存、Append Only File（AOF）重寫等目的進行 Redis 分叉時，既享受邊寫邊復制的好處，又無需承擔繁重的內存開銷。若非如此，我們（或客戶）將需要支付昂貴的資源成本。

為了輕松管理整個集群，我們希望每個 Redis 實例都保持在較小體量，借此加快遷移分片、重新分片、擴展和重新均衡等的執行速度。

3）橫向擴展才是最重要的

以橫向擴展的方式靈活運行內存數據存儲，是 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 基準測試細節

1、結果概述

1）版本

我們使用 Redis 7.0.0，直接通過源碼構建。

Dragonfly 使用的則是構建自 https://github.com/Dragonfly/dragonfly#building-from-source 的 6 月 3 日版源碼（hash=e806e6ccd8c79e002f721a1a5ecb847bd7a06489）。

2）目標

驗證 Dragonfly 公布的結果是否可重現，并確定檢索結果的完整條件（鑒于 memtier_benchmark、操作系統版本等信息有所缺失）。

確定 AWS c6gn.16xlarge 實例上可實現的最佳 OSS Redis 7.0.0 集群性能，并與 Dragonfly 的基準測試結果相比較。

3）客戶端配置

OSS Redis 7.0 解決方案需要大量接入 Redis 集群的開放連接，因為每個 memtier_benchmark 線程都需要連接到所有分片。

OSS Redis 7.0 解決方案在使用兩個 memtier_benchmark 進程時成績最好，而且為了與 Dragonfly 基準相適應，這兩個進程運行在同樣的客戶端虛擬機上。

4）資源利用與配置優化

OSS Redis 集群在 40 個主分片的配置下性能表現最佳，對應的就是虛擬機上有 24 個備用 vCPU。雖然設備資源仍未得到全部利用，但我們發現繼續增加分片數量已經沒有意義，反而會拉低整體性能。我們仍在調查具體原因。

另一方面，Dragonfly 解決方案徹底耗盡了虛擬機性能，所有 64 上 vCPU 均達到了 100% 利用率。

在兩種解決方案中，我們調整了客戶端配置以實現最佳結果。如下所示，我們成功重現了大部分 Dragonfly 基準數據，甚至在 30 通道條件下得出了比項目方更高的測試成績。

本次測試強調與 Dragonfly 測試環境保持一致，如果調整測試環境，Redis 的成績還有望進一步提升。

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

2、分析結果

1）單 GET 通道延遲低于 1 毫秒

OSS Redis：每秒 443 萬次操作，其中延遲平均值與第 50 百分位值均達到亞毫秒級別。平均客戶端延遲為 0.383 毫秒。

Dragonfly 聲稱每秒 400 萬次操作：

我們成功重現至每秒 380 萬次操作，平均客戶端延遲為 0.390 毫秒

Redis 對 Dragonfly——Redis 吞吐量比 Dragonfly 聲稱的結果高出 10%，比我們成功重現的 Dragonfly 結果高 18%。

2）30 條 GET 通道

OSS Redis：每秒 2290 萬次操作，客戶端平均延遲為 2.239 毫秒

Dragonfly 聲稱每秒可達 1500 萬次操作：

我們成功重現了每秒 1590 萬次操作，客戶端平均延遲為 3.99 毫秒

Redis 對 Dragonfly——與 Dragonfly 的重現結果和聲稱結果相比，Redis 分別勝出 43% 和 52%

3）單 SET 通道延遲低于 1 毫秒

OSS Redis：每秒 474 萬次操作，延遲平均值與第 50 百分位值均達到亞毫秒級。客戶端平均延遲為 0.391 毫秒

Dragonfly 聲稱每秒 400 萬次操作：

我們成功重現了每秒 400 萬次操作，客戶端平均延遲為 0.500 毫秒

Redis 對 Dragonfly——與 Dragonfly 的重現結果和聲稱結果相比，Redis 均勝出 19%

4）30 條 SET 通道

OSS Redis：每秒 1985 萬次操作，客戶端平均延遲為 2.879 毫秒

Dragonfly 聲稱每秒 1000 萬次操作：

我們成功重現了每秒 1400 萬次操作，客戶端平均延遲為 4.203 毫秒

Redis 對 Dragonfly——與 Dragonfly 的重現結果和聲稱結果相比，Redis 分別勝出 42% 和 99%

用于各變體的 memtier_benchmark 命令：

1）單 GET 通道延遲低于 1 毫秒

Redis 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

2）30 條 GET 通道

Redis 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

3）單 SET 通道延遲低于 1 毫秒

Redis 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

4）30 條 SET 通道

Redis 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

3、測試設施細節

在本次比較測試中，我們在客戶端（用于運行 memtier_benchmark）和服務器（用于運行 Redis 和 Dragonfly）使用了相同的虛擬機類型，具體規格為：

虛擬機：AWS c6gn.16xlarge

aarch64

ARM Neoverse-N1

每插槽核心數：64

每核心線程數：1

NUMA 節點數：1

核心版本：Arm64 Kernel 5.10

安裝內存：126 GB

參考資料

https://redis.com/blog/redis-architecture-13-years-later/

https://www.reddit.com/r/programming/comments/wiztpx/redis_hits_back_at_dragonfly/