根據之前的基準測試結果，蜻蜓可能是世界上最快的內存存儲系統。它提供對Memcached和Redis協議的支持，但它可以在運行時以更高的性能和更少的內存消耗進行查詢。與Redis相比，蜻蜓在典型工作負載下實現了25倍的性能提升；壹臺蜻蜓服務器每秒可以處理數百萬個請求；在5GB存儲測試中，蜻蜓需要的內存比Redis少30%。
作為壹個開源軟件，蜻蜓在短短兩個月內獲得了9.2K GitHub star和177個分叉分支。盡管近年來出現了許多類似的Redis兼容內存數據存儲系統，如KeyDB和Skytable，但沒有壹個像這次這樣“轟動壹時”。畢竟，Redis誕生於十多年前。這時，從頭設計壹個緩存系統可以拋棄歷史包袱，更好地利用資源。
為了反擊新崛起的蜻蜓，Redis聯合創始人兼首席技術官Yiftach Shoolman、Redis實驗室首席架構師Yossi Gottlieb和Redis實驗室性能工程師Filipe Oliveira聯合發表了壹篇題為“13之後的Redis是否需要新架構”的文章。
在文章中，他們特別給出了Redis 7.0對比蜻蜓的基準測試結果，比較公平:Redis的吞吐量比蜻蜓高18%-40%，並對Redis的架構提出了壹些看法和思考，以證明“為什麽Redis的架構仍然是內存中實時數據存儲的最佳架構（緩存、數據庫以及介於兩者之間的壹切）”。
盡管他們強調Redis架構仍然是同類產品中最好的，但他們不能忽視蜻蜓提供的壹些新鮮有趣的想法和技術。Redis表示，其中壹些甚至可能在未來進入Redis（例如io_uring、更現代的詞典、更具戰略性的線程使用等。).
此外，Redis指出，蜻蜓基準測試的比較方法“不能代表Redis在現實世界中的工作方式”。對此，有網友在Reddit上反駁稱:
還有人說，這篇文章是Redis團隊禮貌地否認了“蜻蜓是最快的緩存系統”，但更多的網友表示，Redis已經代表他們的營銷部門輸了，他們發了壹篇文章進行“反擊”:
當然，我們壹直在尋找創新的方向來提高Redis的性能並擴展其功能，但在這裏我們想談談自己的觀點和思考，並解釋為什麽Redis仍然是最好的實時內存數據存儲方案之壹（包括緩存、數據庫以及介於兩者之間的壹切）。
接下來，我們將重點討論Redis對速度和架構差異的看法，然後基於此進行比較。在文章的最後，我們還將提供與蜻蜓項目的基準測試結果和詳細的性能比較信息。歡迎大家做出自己的對比和參考。
蜻蜓基準測試實際上比較了壹個獨立的單進程Redis實例（只能使用壹個內核）和壹個多線程蜻蜓實例（可以使用虛擬機/服務器上的所有可用內核）。顯然，這樣粗略的對比並不能代表Redis在真實場景下的運行狀態。作為壹名技術構建者，我們希望更準確地了解自己的技術與其他方案之間的差異，因此在這裏我們做了壹點公平性調整:將具有40個分區（其中大部分可用作實例核心）的Redis 7.0集群的性能與最大實例類型（AWS C4GN）進行比較。16x大小）由蜻蜓團隊在基準測試中使用。
在這壹輪測試中，我們看到Redis的吞吐量比蜻蜓高18%到40%，而這僅用於所有64個vCore中的40個。
在我們看來，每個多線程項目開發人員在設置項目之前，都會根據他在之前的工作中所經歷的痛點來指導架構決策。我們也承認，在多核設備上運行單個Redis進程（此類設備通常提供幾十個內核和數百GB內存）確實存在資源無法充分利用的問題。但是Redis在設計之初並沒有考慮到這壹點，許多Redis服務提供商都提出了相應的解決方案來在市場上獲得壹席之地。
Redis通過運行多個進程（使用Redis集群）進行橫向擴展，包括在單個雲實例的上下文中。在Redis，我們進壹步發展了這壹概念並建立了Redis Enterprise。Redis Enterprise提供了管理層，允許用戶大規模運行Redis，默認情況下，它支持高可用性、即時故障轉移、數據持久化和備份。
下面，我們打算分享壹些幕後使用的原則，並介紹我們如何為Redis的生產和應用設計良好的工程實踐。
通過在每個虛擬機上運行多個Redis實例，我們可以:
我們不允許單個Redis進程的大小超過25 GB（在閃存上運行Redis時上限為50 GB）。這樣，我們可以:
以橫向擴展的方式靈活操作內存數據存儲是Redis成功的關鍵。我們來看看具體原因:
我們仍然欣賞社區提出的各種有趣的想法和技術解決方案。其中壹些有望在未來進入Redis（我們已經開始研究io _ uring、更現代的詞典、更豐富的線程使用策略等。).但在可預見的未來，我們不會放棄Redis所堅持的無* * *享受、多進程等基本架構原則。這種設計不僅具有最佳的性能、可擴展性和靈活性，而且可以支持內存實時數據平臺所需的各種部署架構。
附錄:Draonfly的Redis 7.0基準測試詳情
版本:
目標:
客戶端配置:
資源利用和配置優化；
最後，我們還發現Redis和蜻蜓都不受每秒網絡數據包數或傳輸帶寬的限制。我們已經證實，當使用TCP在兩個虛擬機（分別為客戶端和服務器，並且都使用c6gn.16xlarge實例）之間傳輸約300 B的數據包負載時，每秒的數據包傳輸量可以達到654.38+00百萬個以上，傳輸帶寬可以超過30 Gbps。
單個GET通道延遲小於1毫秒:
30個獲取頻道:
單組通道延遲小於1毫秒:
30組頻道:
每個變量的Memtier_benchmark命令:
單個GET通道延遲小於1毫秒
30獲取頻道
單組通道延遲小於1毫秒
30組頻道
在這個比較測試中，我們在客戶機（用於運行memtier_benchmark）和服務器（用於運行Redis和蜻蜓）上使用了相同的虛擬機類型。具體規格如下:
參考鏈接:
/文章/AlF5NIhHdskayl0MTyQG