https://mp.weixin.qq.com/s/JyBRaWl3b1k1Q8-3LrukCg

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

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

作為一個(gè)開源軟件，Dragonfly 在短短兩個(gè)月獲得了 9.2K GitHub 星，177 個(gè) fork 分支。雖然這些年，涌現(xiàn)了不少類似的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲(chǔ)系統(tǒng)，例如 KeyDB、Skytable，但是都沒能像這次這么“轟動(dòng)”。畢竟 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)測(cè)試結(jié)果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及一些有關(guān) Redis 架構(gòu)的觀點(diǎn)和思考，以證明 “為什么 Redis 的架構(gòu)仍然是內(nèi)存實(shí)時(shí)數(shù)據(jù)存儲(chǔ)（緩存、數(shù)據(jù)庫(kù)，以及介于兩者之間的所有內(nèi)容）的最佳架構(gòu)”。

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

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

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

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

“Redis 投入如此多的工程精力來(lái)寫這么一篇文章，還對(duì) Reids/Dragonfly 進(jìn)行了基準(zhǔn)測(cè)試，這是對(duì) Dragonfly 的極大贊美。”“我很高興 Redis 發(fā)了這篇文章，因此我必須要去了解一下 Dragonfly，它看起來(lái)很棒。”

Redis 博客文章翻譯：

作為一項(xiàng)基礎(chǔ)性技術(shù)，每隔段時(shí)間總有人跳出來(lái)，想要替 Redis 換套新架構(gòu)。幾年之前，KeyDB 就提出了這類方案，而最近亮相的 Dragonfly 則聲稱是速度最快的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲(chǔ)系統(tǒng)。沒錯(cuò)，這類方案的涌現(xiàn)當(dāng)然帶來(lái)了不少值得關(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ù)存儲(chǔ)（包括緩存、數(shù)據(jù)庫(kù)以及介于二者之間的一切）方案之一。

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

速度問題

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

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

架構(gòu)差異 背景信息

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

架構(gòu)設(shè)計(jì)原則 ?在每個(gè)虛擬機(jī)上運(yùn)行多個(gè) Redis 實(shí)例

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

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

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

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

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

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

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

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

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

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

• 更佳彈性——我們?cè)诩褐惺褂玫墓?jié)點(diǎn)越多，整個(gè)集群的健壯性就越強(qiáng)。例如，如果您在三節(jié)點(diǎn)集群上運(yùn)行數(shù)據(jù)集，且其中一個(gè)節(jié)點(diǎn)發(fā)生降級(jí)，則代表有三分之一的集群無(wú)法運(yùn)行；但如果是在九節(jié)點(diǎn)集群上運(yùn)行數(shù)據(jù)集，同樣是其中一個(gè)節(jié)點(diǎn)發(fā)生降級(jí)，則只有九分之一的集群無(wú)法運(yùn)行。

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

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

• 高吞吐——在 Redis，我們看到很多客戶會(huì)在小型數(shù)據(jù)集上運(yùn)行高吞吐量工作負(fù)載，即具有極高的網(wǎng)絡(luò)帶寬及 / 或每秒數(shù)據(jù)包（PPS）需求。我們以每秒操作數(shù) 100 萬(wàn) + 的 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ò)展無(wú)疑就是比縱向擴(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ù)我們?cè)谄渌嗑€程項(xiàng)目中的經(jīng)驗(yàn)，NUMA 可能令內(nèi)存數(shù)據(jù)存儲(chǔ)的性能降低達(dá) 80%。

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

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

• 商品硬件——最后，我們的很多客戶會(huì)在本地?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ù)方案。其中一部分有望在未來(lái)進(jìn)入 Redis（我們已經(jīng)開始研究 io_uring、更現(xiàn)代的字典、更豐富的線程使用策略等）。但在可預(yù)見的未來(lái)，我們不會(huì)放棄 Redis 所堅(jiān)守的無(wú)共享、多進(jìn)程等基本架構(gòu)原則。這種設(shè)計(jì)不僅具備最佳性能、可擴(kuò)展性和彈性，同時(shí)也能夠支持內(nèi)存內(nèi)實(shí)時(shí)數(shù)據(jù)平臺(tái)所需要的各類部署架構(gòu)。

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

?結(jié)果概述

版本：

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

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

目標(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)測(cè)試結(jié)果相比較

客戶端配置：

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

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

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

• OSS Redis 集群在 40 個(gè)主分片的配置下性能表現(xiàn)最佳，對(duì)應(yīng)的就是虛擬機(jī)上有 24 個(gè)備用 vCPU。雖然設(shè)備資源仍未得到全部利用，但我們發(fā)現(xiàn)繼續(xù)增加分片數(shù)量已經(jīng)沒有意義，反而會(huì)拉低整體性能。我們?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)目方更高的測(cè)試成績(jī)。

• 本次測(cè)試強(qiáng)調(diào)與 Dragonfly 測(cè)試環(huán)境保持一致，如果調(diào)整測(cè)試環(huán)境，Redis 的成績(jī)還有望進(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 萬(wàn)以上、傳輸帶寬超過 30 Gbps。

?分析結(jié)果

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

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

• Dragonfly 聲稱每秒 400 萬(wàn)次操作：

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

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

30 條 GET 通道：

• OSS Redis：每秒 2290 萬(wàn)次操作，客戶端平均延遲為 2.239 毫秒

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

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

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

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

• OSS Redis：每秒 474 萬(wàn)次操作，延遲平均值與第 50 百分位值均達(dá)到亞毫秒級(jí)?？蛻舳似骄舆t為 0.391 毫秒

• Dragonfly 聲稱每秒 400 萬(wàn)次操作：

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

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

30 條 SET 通道:

• OSS Redis：每秒 1985 萬(wàn)次操作，客戶端平均延遲為 2.879 毫秒

• Dragonfly 聲稱每秒 1000 萬(wàn)次操作：

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

• Redis 對(duì) Dragonfly——與 Dragonfly 的重現(xiàn)結(jié)果和聲稱結(jié)果相比，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

測(cè)試設(shè)施細(xì)節(jié)

在本次比較測(cè)試中，我們?cè)诳蛻舳耍ㄓ糜谶\(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/