雖然這些年，涌現(xiàn)了不少類似的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲系統(tǒng)，例如 KeyDB、Skytable，但是都沒能像這次這么“轟動”。畢竟 Redis 誕生了十多年，這時從頭開始設計一個緩存系統(tǒng)，可以拋棄歷史包袱，更好地利用資源。

Redis 回擊

為回擊新冒頭的 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)》的文章。

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

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

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

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

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

“Redis 投入如此多的工程精力來寫這么一篇文章，還對 Reids/Dragonfly 進行了基準測試，這是對 Dragonfly 的極大贊美?！?br>“我很高興 Redis 發(fā)了這篇文章，因此我必須要去了解一下 Dragonfly，它看起來很棒?！?/p>

Redis 博客文章翻譯：

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

幾年之前，KeyDB 就提出了這類方案，而最近亮相的 Dragonfly 則聲稱是速度最快的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲系統(tǒng)。沒錯，這類方案的涌現(xiàn)當然帶來了不少值得關注和討論的有趣技術(shù) / 思路。在 Redis，我們也喜歡迎接挑戰(zhàn)，重新審視 Redis 最初的架構(gòu)設計原則。

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

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

速度問題

Dragonfly 基準測試其實是將獨立單進程 Redis 實例（只能使用單一核心）與多線程 Dragonfly 實例（可以使用虛擬機 / 服務器上的全部可用核心）進行比較。

很明顯，這樣的粗暴比較并不能代表 Redis 在現(xiàn)實場景下的運行狀態(tài)。作為技術(shù)構(gòu)建者，我們希望更確切地把握自有技術(shù)同其他方案間的差異，所以這里我們做了一點公平性調(diào)整：將具有 40 個分片的 Redis 7.0 集群（可使用其中的大部分實例核心）與 Dragonfly 團隊在基準測試中使用的最大實例類型（AWS c4gn.16xlarge）進行性能比較。

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

架構(gòu)差異

背景信息

在我們看來，每一位多線程項目的開發(fā)者在立項之前，都會根據(jù)以往工作中經(jīng)歷過的痛點來指導架構(gòu)決策。

我們也承認，在多核設備上運行單一 Redis 進程（這類設備往往提供幾十個核心和數(shù)百 GB 內(nèi)存）確實存在資源無法充分利用的問題。但 Redis 在設計之初也確實沒有考慮到這一點，而且眾多 Redis 服務商已經(jīng)拿出了相應的解決方案，借此在市場上占得一席之地。

Redis 通過運行多個進程（使用 Redis 集群）實現(xiàn)橫向擴展，包括在單一云實例背景下也是如此。

在 Redis 公司，我們進一步拓展這個概念并建立起 Redis Enterprise。Redis Enterprise 提供管理層，允許用戶大規(guī)模運行 Redis，并默認啟用高可用性、即時故障轉(zhuǎn)移、數(shù)據(jù)持久與備份等功能。

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

架構(gòu)設計原則

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

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

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

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

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

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

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

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

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

橫向擴展才是最重要的

以橫向擴展的方式靈活運行內(nèi)存數(shù)據(jù)存儲，是 Redis 獲得成功的關鍵。

下面來看具體原因：

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

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

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

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

• 貼近 NUMA 架構(gòu)——縱向擴展還要求使用能容納更多核心和大容量 DRAM 的雙插槽服務器；相比之下，Redis 這樣的多處理架構(gòu)其實更適應 NUMA 架構(gòu)，因為其行為特征就接近一種由多個較小節(jié)點組成的網(wǎng)絡。但必須承認，NUMA 跟多線程架構(gòu)之間也有天然沖突。根據(jù)我們在其他多線程項目中的經(jīng)驗，NUMA 可能令內(nèi)存數(shù)據(jù)存儲的性能降低達 80%。

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

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

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

總  結(jié)

我們?nèi)匀恍蕾p由社區(qū)提出的種種有趣思路和技術(shù)方案。

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

但在可預見的未來，我們不會放棄 Redis 所堅守的無共享、多進程等基本架構(gòu)原則。這種設計不僅具備最佳性能、可擴展性和彈性，同時也能夠支持內(nèi)存內(nèi)實時數(shù)據(jù)平臺所需要的各類部署架構(gòu)。

附錄：Redis 7.0 對 Draonfly 基準測試細節(jié)

結(jié)果概述

版本：

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

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

目標：

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

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

客戶端配置：

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

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

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

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

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

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

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

最后，我們還發(fā)現(xiàn) Redis 和 Dragonfly 都不受網(wǎng)絡每秒數(shù)據(jù)包或傳輸帶寬的限制。

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