比Redis快25倍 Star數(shù)飆升 Dragonfly可能是最快的內(nèi)存數(shù)據(jù)庫

一、Redis 博客文章翻譯

二、速度問題

三、架構(gòu)差異

四、總結(jié)

今年年中，一位前谷歌、前亞馬遜的工程師推出了他創(chuàng)作的開源內(nèi)存數(shù)據(jù)緩存系統(tǒng) Dragonfly，用 C/C++ 編寫，基于 BSL 許可（Business Source License）分發(fā)。

根據(jù)過往的基準(zhǔn)測試結(jié)果來看， Dragonfly 可能是世界上最快的內(nèi)存存儲系統(tǒng)，它提供了對 Memcached 和 Redis 協(xié)議的支持，但能夠以更高的性能進(jìn)行查詢，運(yùn)行時(shí)內(nèi)存消耗也更少。與 Redis 相比，Dragonfly 在典型工作負(fù)載下實(shí)現(xiàn)了 25 倍的性能提升；單個(gè) Dragonfly 服務(wù)器每秒可以處理數(shù)百萬個(gè)請求；在 5GB 存儲測試中，Dragonfly 所需的內(nèi)存比 Redis 少 30%。

作為一個(gè)開源軟件，Dragonfly 在短短兩個(gè)月獲得了 9.2K GitHub 星，177 個(gè) fork 分支。雖然這些年，涌現(xiàn)了不少類似的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲系統(tǒng)，例如 KeyDB、Skytable，但是都沒能像這次這么“轟動”。畢竟 Redis 誕生了十多年，這時(shí)從頭開始設(shè)計(jì)一個(gè)緩存系統(tǒng)，可以拋棄歷史包袱，更好地利用資源。

為回?fù)粜旅邦^的 Dragonfly，Redis 的聯(lián)合創(chuàng)始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架構(gòu)師 Yossi Gottlieb、Redis Labs 的性能工程師 Filipe Oliveira 聯(lián)合發(fā)布了一篇名為《13 年后，Redis 是否需要新的架構(gòu)》的文章。

在文章中，他們特地給出了自認(rèn)更加公平的 Redis 7.0 vs. Dragonfly 基準(zhǔn)測試結(jié)果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及一些有關(guān) Redis 架構(gòu)的觀點(diǎn)和思考，以證明 “為什么 Redis 的架構(gòu)仍然是內(nèi)存實(shí)時(shí)數(shù)據(jù)存儲（緩存、數(shù)據(jù)庫，以及介于兩者之間的所有內(nèi)容）的最佳架構(gòu)”。

雖然他們強(qiáng)調(diào) Redis 架構(gòu)仍然是同類最佳，但也沒法忽視 Dragonfly 這些新軟件提供的一些新鮮、有趣的想法和技術(shù)，Redis 表示其中的一些甚至有可能在未來進(jìn)入 Redis（比如已經(jīng)開始研究的 io_uring 、更現(xiàn)代的 dictionaries、更有策略地使用線程等）。

另外，Redis 指出 Dragonfly 基準(zhǔn)測試的比較方法 “不能代表 Redis 在現(xiàn)實(shí)世界中的運(yùn)行方式” 。對此，Reddit 上有網(wǎng)友反駁稱：

它絕對代表了現(xiàn)實(shí)世界中普通用戶運(yùn)行 Redis 的方式?！霸趩闻_機(jī)器上運(yùn)行集群，只是為了能夠使用超過 1 個(gè) core" 是額外的復(fù)雜性，人們只有在別無選擇的情況下才會這樣做，如果競爭者無論有多少個(gè) core 都能 “just works"，那么最好能有更容易的設(shè)置。

還有人表示，這篇文章是 Redis 團(tuán)隊(duì)在有禮貌地否認(rèn)“Dragonfly 是最快的緩存系統(tǒng)”，但更多網(wǎng)友表示，Redis 發(fā)文章進(jìn)行“回?fù)簟?，就已?jīng)代表他們的營銷部門輸了：

“Redis 投入如此多的工程精力來寫這么一篇文章，還對 Reids/Dragonfly 進(jìn)行了基準(zhǔn)測試，這是對 Dragonfly 的極大贊美?！薄拔液芨吲d Redis 發(fā)了這篇文章，因此我必須要去了解一下 Dragonfly，它看起來很棒。”

一、Redis 博客文章翻譯

作為一項(xiàng)基礎(chǔ)性技術(shù)，每隔段時(shí)間總有人跳出來，想要替 Redis 換套新架構(gòu)。 幾年之前，KeyDB 就提出了這類方案，而最近亮相的 Dragonfly 則聲稱是速度最快的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲系統(tǒng)。沒錯(cuò)，這類方案的涌現(xiàn)當(dāng)然帶來了不少值得關(guān)注和討論的有趣技術(shù) / 思路。在 Redis，我們也喜歡迎接挑戰(zhàn)，重新審視 Redis 最初的架構(gòu)設(shè)計(jì)原則。

我們當(dāng)然一直在尋求為 Redis 提升性能、擴(kuò)充功能的創(chuàng)新方向，但這里我們想聊聊自己的觀點(diǎn)和思考，闡釋 Redis 時(shí)至今日為何仍是最出色的實(shí)時(shí)內(nèi)存數(shù)據(jù)存儲（包括緩存、數(shù)據(jù)庫以及介于二者之間的一切）方案之一。

接下來，我們將重點(diǎn)介紹 Redis 對于速度和架構(gòu)差異的觀點(diǎn)，再以此為基礎(chǔ)做出比較。在文章的最后，我們還會提供基準(zhǔn)測試結(jié)果、與 Dragonfly 項(xiàng)目的詳盡性能比較信息，歡迎大家自行對比參考。

二、速度問題

Dragonfly 基準(zhǔn)測試其實(shí)是將獨(dú)立單進(jìn)程 Redis 實(shí)例（只能使用單一核心）與多線程 Dragonfly 實(shí)例（可以使用虛擬機(jī) / 服務(wù)器上的全部可用核心）進(jìn)行比較。很明顯，這樣的粗暴比較并不能代表 Redis 在現(xiàn)實(shí)場景下的運(yùn)行狀態(tài)。作為技術(shù)構(gòu)建者，我們希望更確切地把握自有技術(shù)同其他方案間的差異，所以這里我們做了一點(diǎn)公平性調(diào)整：將具有 40 個(gè)分片的 Redis 7.0 集群（可使用其中的大部分實(shí)例核心）與 Dragonfly 團(tuán)隊(duì)在基準(zhǔn)測試中使用的最大實(shí)例類型（AWS c4gn.16xlarge）進(jìn)行性能比較。

在這輪測試中，我們看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而這還僅僅只用到全部 64 個(gè) vCore 中的 40 個(gè)。

三、架構(gòu)差異

1、背景信息

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

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

下面，我們打算分享幕后使用的一些原則，向大家介紹我們?nèi)绾螢?Redis 的生產(chǎn)應(yīng)用設(shè)計(jì)良好的工程實(shí)踐。

2、架構(gòu)設(shè)計(jì)原則

1）在每個(gè)虛擬機(jī)上運(yùn)行多個(gè) Redis 實(shí)例

通過在每個(gè)虛擬機(jī)上運(yùn)行多個(gè) Redis 實(shí)例，我們可以：

使用一套完全無共享的架構(gòu)實(shí)現(xiàn)縱向與橫向線性擴(kuò)展。與純縱向擴(kuò)展的多線程架構(gòu)相比，這套方案能始終提供更好的架構(gòu)靈活性。

提高復(fù)制速度，因?yàn)閺?fù)制操作是跨多個(gè)進(jìn)程并發(fā)完成的。

從虛擬機(jī)故障中快速恢復(fù)。因?yàn)樾绿摂M機(jī)的 Redis 實(shí)例將同時(shí)填充來自多個(gè)外部 Redis 實(shí)例的數(shù)據(jù)。

2）將每個(gè) Redis 進(jìn)程限制為合理的大小

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

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

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

3）橫向擴(kuò)展才是最重要的

以橫向擴(kuò)展的方式靈活運(yùn)行內(nèi)存數(shù)據(jù)存儲，是 Redis 獲得成功的關(guān)鍵。下面來看具體原因：

更佳彈性

我們在集群中使用的節(jié)點(diǎn)越多，整個(gè)集群的健壯性就越強(qiáng)。例如，如果您在三節(jié)點(diǎn)集群上運(yùn)行數(shù)據(jù)集，且其中一個(gè)節(jié)點(diǎn)發(fā)生降級，則代表有三分之一的集群無法運(yùn)行；但如果是在九節(jié)點(diǎn)集群上運(yùn)行數(shù)據(jù)集，同樣是其中一個(gè)節(jié)點(diǎn)發(fā)生降級，則只有九分之一的集群無法運(yùn)行。

易于擴(kuò)展

在橫向擴(kuò)展系統(tǒng)當(dāng)中，向集群添加一個(gè)額外節(jié)點(diǎn)、并將數(shù)據(jù)集的一部分遷移到其中要容易得多。與之對應(yīng)，在縱向擴(kuò)展系統(tǒng)中，我們只能直接引入一個(gè)更大的節(jié)點(diǎn)并復(fù)制整個(gè)數(shù)據(jù)集……這是個(gè)漫長的過程，而且期間隨時(shí)有可能鬧出麻煩。

逐步擴(kuò)展更具成本效益

縱向擴(kuò)展，尤其是云環(huán)境下的縱向擴(kuò)展，往往對應(yīng)高昂的成本。在多數(shù)情況下，即使只需要向數(shù)據(jù)集內(nèi)添加幾 GB 內(nèi)容，也需要將實(shí)例大小翻倍。

高吞吐

在 Redis，我們看到很多客戶會在小型數(shù)據(jù)集上運(yùn)行高吞吐量工作負(fù)載，即具有極高的網(wǎng)絡(luò)帶寬及 / 或每秒數(shù)據(jù)包（PPS）需求。我們以每秒操作數(shù) 100 萬 + 的 1 GB 大小數(shù)據(jù)集為例，相較于使用單節(jié)點(diǎn) c6gn.16xlarge 集群（128 GB 內(nèi)存、64 個(gè) CPU 加 100 Gbps 傳輸帶寬，每小時(shí)使用成本 2.7684 美元），三個(gè) c6gb.xlarge 節(jié)點(diǎn)（8 GB 內(nèi)存、4 個(gè) CPU 外加最高 25 Gbps 傳輸帶寬，每小時(shí) 0.1786 美元）構(gòu)成的集群能夠?qū)⑦\(yùn)行成本拉低 20%，而且健壯性反而更高。既然成本效益出色、彈性更強(qiáng)且吞吐量反超，那橫向擴(kuò)展無疑就是比縱向擴(kuò)展更好的選擇。

貼近 NUMA 架構(gòu)

縱向擴(kuò)展還要求使用能容納更多核心和大容量 DRAM 的雙插槽服務(wù)器；相比之下，Redis 這樣的多處理架構(gòu)其實(shí)更適應(yīng) NUMA 架構(gòu)，因?yàn)槠湫袨樘卣骶徒咏环N由多個(gè)較小節(jié)點(diǎn)組成的網(wǎng)絡(luò)。但必須承認(rèn)，NUMA 跟多線程架構(gòu)之間也有天然沖突。根據(jù)我們在其他多線程項(xiàng)目中的經(jīng)驗(yàn)，NUMA 可能令內(nèi)存數(shù)據(jù)存儲的性能降低達(dá) 80%。

存儲吞吐量限制

AWS EBS 等外部磁盤的擴(kuò)展速度，顯然不及內(nèi)存和 CPU。事實(shí)上，云服務(wù)商會根據(jù)所使用設(shè)備的類型添加存儲吞吐量限制。因此，避免吞吐量限制、滿足數(shù)據(jù)高持久性要求的唯一辦法，就是使用橫向擴(kuò)展——即添加更多節(jié)點(diǎn)和更多的配套網(wǎng)絡(luò)附加磁盤。

臨時(shí)磁盤

臨時(shí)磁盤是一種將 Redis 運(yùn)行在 SSD 上的絕佳方式（其中 SSD 用于替代 DRAM，而非充當(dāng)持久存儲介質(zhì)），能夠在保持 Redis 極高速度的同時(shí)將數(shù)據(jù)庫成本保持在磁盤級水平。但臨時(shí)磁盤也有其上限，一旦逼近這一上限，我們還需要進(jìn)一步擴(kuò)展容量——這時(shí)候，更好的辦法仍然是添加更多節(jié)點(diǎn)、引入更多臨時(shí)磁盤。所以，橫向擴(kuò)展繼續(xù)勝出。

商品硬件

最后，我們的很多客戶會在本地?cái)?shù)據(jù)中心、私有云甚至是小型邊緣數(shù)據(jù)中心內(nèi)運(yùn)行 Redis。在這類環(huán)境中，絕大多數(shù)設(shè)備內(nèi)存不超過 64 GB、CPU 不超過 8 個(gè)，所以唯一可行的擴(kuò)展方式就只有橫向擴(kuò)展。

四、總結(jié)

我們?nèi)匀恍蕾p由社區(qū)提出的種種有趣思路和技術(shù)方案。其中一部分有望在未來進(jìn)入 Redis（我們已經(jīng)開始研究 io_uring、更現(xiàn)代的字典、更豐富的線程使用策略等）。但在可預(yù)見的未來，我們不會放棄 Redis 所堅(jiān)守的無共享、多進(jìn)程等基本架構(gòu)原則。這種設(shè)計(jì)不僅具備最佳性能、可擴(kuò)展性和彈性，同時(shí)也能夠支持內(nèi)存內(nèi)實(shí)時(shí)數(shù)據(jù)平臺所需要的各類部署架構(gòu)。

附錄：Redis 7.0 對 Draonfly 基準(zhǔn)測試細(xì)節(jié)

1、結(jié)果概述

1）版本

我們使用 Redis 7.0.0，直接通過源碼構(gòu)建。

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

2）目標(biāo)

驗(yàn)證 Dragonfly 公布的結(jié)果是否可重現(xiàn)，并確定檢索結(jié)果的完整條件（鑒于 memtier_benchmark、操作系統(tǒng)版本等信息有所缺失）。

確定 AWS c6gn.16xlarge 實(shí)例上可實(shí)現(xiàn)的最佳 OSS Redis 7.0.0 集群性能，并與 Dragonfly 的基準(zhǔn)測試結(jié)果相比較。

3）客戶端配置

OSS Redis 7.0 解決方案需要大量接入 Redis 集群的開放連接，因?yàn)槊總€(gè) memtier_benchmark 線程都需要連接到所有分片。

OSS Redis 7.0 解決方案在使用兩個(gè) memtier_benchmark 進(jìn)程時(shí)成績最好，而且為了與 Dragonfly 基準(zhǔn)相適應(yīng)，這兩個(gè)進(jìn)程運(yùn)行在同樣的客戶端虛擬機(jī)上。

4）資源利用與配置優(yōu)化

OSS Redis 集群在 40 個(gè)主分片的配置下性能表現(xiàn)最佳，對應(yīng)的就是虛擬機(jī)上有 24 個(gè)備用 vCPU。雖然設(shè)備資源仍未得到全部利用，但我們發(fā)現(xiàn)繼續(xù)增加分片數(shù)量已經(jīng)沒有意義，反而會拉低整體性能。我們?nèi)栽谡{(diào)查具體原因。

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

在兩種解決方案中，我們調(diào)整了客戶端配置以實(shí)現(xiàn)最佳結(jié)果。如下所示，我們成功重現(xiàn)了大部分 Dragonfly 基準(zhǔn)數(shù)據(jù)，甚至在 30 通道條件下得出了比項(xiàng)目方更高的測試成績。

本次測試強(qiáng)調(diào)與 Dragonfly 測試環(huán)境保持一致，如果調(diào)整測試環(huán)境，Redis 的成績還有望進(jìn)一步提升。

最后，我們還發(fā)現(xiàn) Redis 和 Dragonfly 都不受網(wǎng)絡(luò)每秒數(shù)據(jù)包或傳輸帶寬的限制。我們已經(jīng)確認(rèn)在 2 個(gè)虛擬機(jī)間（分別作為客戶端和服務(wù)器，且均使用 c6gn.16xlarge 實(shí)例）使用 TCP 傳遞約 300 B 大小的數(shù)據(jù)包負(fù)載時(shí)，可以讓每秒數(shù)據(jù)包傳輸量達(dá)到 1000 萬以上、傳輸帶寬超過 30 Gbps。

2、分析結(jié)果

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

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

Dragonfly 聲稱每秒 400 萬次操作：

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

Redis 對 Dragonfly——Redis 吞吐量比 Dragonfly 聲稱的結(jié)果高出 10%，比我們成功重現(xiàn)的 Dragonfly 結(jié)果高 18%。

2）30 條 GET 通道

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

Dragonfly 聲稱每秒可達(dá) 1500 萬次操作：

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

Redis 對 Dragonfly——與 Dragonfly 的重現(xiàn)結(jié)果和聲稱結(jié)果相比，Redis 分別勝出 43% 和 52%

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

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

Dragonfly 聲稱每秒 400 萬次操作：

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

Redis 對 Dragonfly——與 Dragonfly 的重現(xiàn)結(jié)果和聲稱結(jié)果相比，Redis 均勝出 19%

4）30 條 SET 通道

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

Dragonfly 聲稱每秒 1000 萬次操作：

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

Redis 對 Dragonfly——與 Dragonfly 的重現(xiàn)結(jié)果和聲稱結(jié)果相比，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、測試設(shè)施細(xì)節(jié)

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

虛擬機(jī)：AWS c6gn.16xlarge

aarch64

ARM Neoverse-N1

每插槽核心數(shù)：64

每核心線程數(shù)：1

NUMA 節(jié)點(diǎn)數(shù)：1

核心版本：Arm64 Kernel 5.10

安裝內(nèi)存：126 GB

參考資料

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

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