來源 ｜ 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
測驗設施細節
在本次比較測驗中，我們在客戶端（用于運行 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/
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/504619.html
標籤：Java