Redis 和 Dragonfly 該有危機感了！
微軟開源全新緩存儲存系統 Garnet
近日，微軟正式開源緩存儲存系統 Garnet。據微軟研究院資料庫小組高級首席研究員 Badrish Chandramouli 介紹，Garnet 計畫是從零開始構建而成，且以效能為核心考量（特別是吞吐量中的執行緒可延伸性與更高比例的低延遲水平）。
具體來說，Garnet 具有以下幾大優勢：
據了解，微軟研究院自 2016 年以來一直在研究現代鍵 - 值資料庫架構。2018 年，微軟將一套嵌入式鍵 - 值庫 FASTER 開源之後，其效能超出原有系統幾個數量級，同時專註於簡單的單節點行程內鍵 - 值模型。
從 2021 年開始，根據實際用例的需求，微軟開始構建一套新的遠端緩存儲存方案。其中包含一切必要功能，以作為現有緩存儲存的可行替代選項。當時微軟面臨的挑戰包括保持 / 增強其在早期工作中已經取得的效能優勢，同時考慮如何更好地適應更加現實的普遍網路環境。這項工作的成果就是 Garnet。
在被問及 Garnet 適合部署在哪些場景下時，Chandramouli 表示任何「 使用 Redis、KeyDB 或者 Dragonfly 作為緩存儲存方案的現有應用程式都適合 ，Garnet 能提供更高的吞吐量、更低延遲、透過減少需要托管的緩存儲存分片來降低成本，還可將數據溢位至本地磁盤或 SSD 以緩存超過記憶體大小的數據。此外，Garnet 也適合各種希望借極高效能緩存層提高效能、降低後端儲存伺服器或資料庫成本的新型應用程式。」
API 功能方面，Garnet 支持廣泛的 API，包括原始字串、分析與物件操作。它還提供分片、復制及動態金鑰遷移等功能的集群模式。Gartner 支持客戶端 RESP 事務及用 C# 編寫的伺服器端儲存過程，還允許使用者在原始字串及新物件型別之上設定自訂操作。所有這些均可簡單使用 C# 編寫，因此自訂擴充套件的開發門檻更低。
網路、儲存、集群功能方面，Garnet 使用快速且可插拔的網路層，且支持後續擴充套件，例如配合內核旁路堆疊。它支持傳輸層安全（TLS）通訊協定和各種基本存取控制。Garnet 的儲存層被稱為 Tsavorite，是從 OSS FASTER 中分叉而成，可提供一系列強大的資料庫功能，例如執行緒可延伸性、分層儲存支持（記憶體、SSD 和雲端儲存等）、快速非阻塞檢查點、恢復、持久操作日誌記錄、多鍵事務支持，以及更好的內在管理與重用功能等。此外，Garnet 還支持集群操作模式。
除了單節點執行之外，Garnet 還支持集群模式，允許使用者建立並管理分片和復制部署。Garnet 還支持高效、動態的鍵遷移方案，借此重新均衡各個分片。使用者可以使用標準的 Redis 集群命令來建立並管理 Garnet 集群，各節點則執行 gossip 以共享並演進集群狀態。總的來說，Garnet 的集群模式是一項龐大且仍在發展的功能，微軟表示，更多細節將在後續文章中與大家分享。
Chandramouli 在回復 The Stack 的信件中補充道，「我們也期待大家能將 Garnet 在各類其他現實套用中的表現反饋回來。此外，我們還擁有一套基於 C# 的強大儲存過程模型，使用者可以借此對關註的事務進行自訂。最後，我們將 Garnet 視為面向未來的重要創新工具，包括最佳化磁盤 IO、內核旁路網路以及向量資料庫等套用場景。」
Garnet 有什麽亮點？
雲和邊緣計算的快速增長讓相關應用程式和服務在數據和覆蓋範圍上均有顯著提升。但與此同時，它們也在數據存取、更新與轉換層面提出了效率更高、延遲更低、成本更廉的實際要求。這些應用程式與服務往往需要在儲存互動方面投入大量營運支出，這也使其成為當今最昂貴、最具挑戰性的平台領域之一。以單獨可延伸的遠端行程形式存在的緩存儲存軟體層，能夠有效降低這些成本並提高應用程式效能。這也推動了緩存儲存行業的發展，包括許多大家耳熟能詳的開源系統，例如 Redis、Memcached、KeyDB 以及 Dragonfly。
與僅支持簡單獲取 / 設定介面的傳統遠端緩存儲存不同，現代緩存需要提供豐富的 API 與功能集。它們支持原始字串、Hyperloglog 等分析數據結構，以及排序集和哈希等復雜數據型別。它們還須允許使用者為緩存設定檢查點和恢復功能、建立數據分片、維護復制副本並支持事務與自訂擴充套件。
然而，現有系統在保持系統設計簡單性的同時，往往難以滿足如此豐富的功能需求，包括導致其無法充分利用最新硬體功能（例如多核心、分層儲存、快速網路）。此外，其中許多系統在設計之初，也沒有考慮到可由應用程式開發者輕松擴充套件、或者在不同平台 / 作業系統上良好執行等現實需求。
根據介紹，Garnet 在設計上重新考量了整個緩存儲存堆疊——從網路處獲取封包、到解析和處理資料庫操作、再到執行儲存互動。
下圖為 Garnet 的整體架構，可以看到，Garnet 的網路層繼承了微軟受 ShadowFax 研究啟發所建立的共享記憶體設計。TLS 處理與儲存互動在 IO 完成執行緒上執行，這就避免了常見的執行緒切換開銷。這種方法能夠借 CPU 緩存一致性將數據傳輸至網路，而非基於需要在伺服器上行動資料的傳統 shuffle 設計。
Garnet 計畫整體架構
Garnet 的儲存設計由兩套 Tsavorite 鍵 - 值儲存組成，二者與統一的操作日誌進行繫結。前一套儲存被稱為「主記憶體儲」，針對原始字串操作進行了最佳化，負責管理記憶體以避免垃圾收集。第二套則為可選的「物件儲存」，主要針對復雜物件及自訂數據型別進行最佳化，具體涵蓋排序集、集、哈希、列表和地理空間等流行數據型別。它們被儲存在記憶體堆上（以保證更新更加高效），並以序列化形式存放在磁盤內。未來，微軟還將研究如何透過統一的索引與日誌簡化 Garnet 的系統維護。
Garnet 設計中的一大顯著特點，就是采用了 Tsavorite 儲存 API。該 AIP 用於提供更大、更豐富且可延伸的 RESP API 表面，能夠執行讀取、更新插入、刪除以及原子讀取 - 修改 - 寫入等操作，且全部透過 Garnet 的異步回呼實作以便在每項操作期間的多個點上插入邏輯。儲存 API 模型還確保 Garnet 能夠將對問題的解析與查詢處理，同並行、儲存分層和檢查點等其他儲存功能徹底分開。
此外，Garnet 還進一步增加了對基於雙階段釘選的多鍵事務的支持。使用者可以使用 RESP 客戶端事務（MULTI-EXEC）或使用 C# 中的伺服器端事務儲存過程。
效能表現
微軟研究團隊透過展示比較了 Gartner 與其他領先開源緩存儲存方案間的關鍵效能指標。
首先，團隊預先配置了兩套執行 Linux 系統（Ubuntu 20.04）的 Azure 標準 F72s v2 虛擬機器（每虛擬機器 72 上 vCPU 加 144 GiB 記憶體），且啟用了加速 TCP。其中一套虛擬機器執行各種緩存儲存伺服器，另一套則專門釋出工作負載。這裏微軟使用自己的基準測試工具 Resp.benchmark，統一由它給出效能測試結果。
微軟將 Garnet 與最新開源版本的 Redis（v7.2）、KeyDB（v6.3.4）以及 Dragonfly（v6.2.11）進行了比較。在實驗中，微軟使用了均勻隨機分布的鍵（Garnet 的共享記憶體設計對於非隨機分布的鍵具有更好的效能最佳化效果）。在這些實驗中，數據會被預先載入至每台伺服器上，再嵌入記憶體中。
實驗一：不同數量客戶端會話的吞吐量比較
從大指 GET 操作（每批 4096 條請求）加低負載（8 字節鍵與值）起步，嘗試最大限度減少網路開銷，並逐步增加客戶端會話數量以比較系統效能。從下圖中可以看到，Garnet 表現出的可延伸性超越了 Redis 與 KeyDB，同時實作了比所有三大基線系統更高的吞吐量（y 軸取對數座標）。請註意，雖然 Dragonfly 的擴充套件效能與 Garnet 類似，但前者屬於純記憶體內系統。此外，當資料庫大小（即預載入的鍵數量）明顯超過處理器的緩存大小時（2.56 億個鍵），Garnet 相較於其他系統仍擁有強勁的吞吐量表現。
資料庫大小為（a）1024 個鍵及（b）2.56 億個鍵時，不同數量客戶端會話對應的吞吐量（對數座標）。
實驗二：不同批次大小的吞吐量比較
接下來，使用 GET 操作加固定數量（64）的客戶端會話來改變批次大小。跟之前的實驗一樣，繼續嘗試兩種不同的資料庫大小。如下圖所示，即使不采用分批次處理，Garnet 的效能同樣表現更好；而在采用分批次處理後，即使批次規模很小，Garnet 的效能優勢也在增強。負載大小與實驗一相同，且 y 軸同樣取對數座標。
資料庫大小為（a）1024 個鍵及（b）2.56 億個鍵時，不同批次大小下的吞吐量比較（取對數座標）。
實驗三：不同數量實施意見會話的延遲比較
接下來測試的是各種系統的客戶端延遲。如下圖所示，隨著客戶端會話數量增加，與其他系統相比，Garnet 在各個百分位上的延遲（以微秒為單位）均更低也更加穩定。實驗中，以 GET 操作占 80%、SET 操作占 20% 的混合比例發送操作，且不做分批次處理。
不同客戶端會話數量時，（a）中位數、（b）第 99 百分位與（c）第 99.9 百分位處的延遲水平。
實驗四：不同批次大小的延遲比較
Garnet 的延遲水平針對自適應客戶端的批次與查詢系統進行了最佳化。微軟將批次大小從 1 增加到 64，並在下圖中整理出具有 128 個活動客戶端連線時不同百分位上的延遲水平。從下圖中可以看到，Gartner 的延遲整體較低。與之前的實驗一樣，同樣采用 GET 操作占 80%、SET 操作占 20% 的混合比例。
不同批次大小下，（a）中位數、（b）第 99 百分位以及（c）第 99.9 百分位上的延遲水平。
開發者：Redis 需要進行重大效能最佳化了！
從基準效能圖表來看，GET 命令的吞吐量超過了 Dragonfly 十倍以上。雖然第 50 百分位的延遲水平略高於 Dragonfly，但第 99 百分位上的延遲卻比 Dragonfly 更低。Garnet 和 Dragonfly 在吞吐量和延遲上的表現均遠遠優於 Redis，不少開發者認為，這表明 Redis 可能需要進行重大效能最佳化。
開發者 hipadev23 表示，「Garnet 確實是第一個在低並行與高並行水平上均優於 Redis 的替代方案，這是一項很了不起的成就。」「Redis 可能需要進行重大效能最佳化。」
開發者 mtmk 認為，對於需要直接在微軟 Windows Server 上執行 Redis（或者相容），但又不想依賴於 WSL2 的朋友們來說，Garnet 的出現肯定是個好訊息。以往由 Redis 埠（現處於歸檔狀態）造成的記憶體使用問題（主要是由於記憶體對映檔 AFAIK）將不復存在。
也有不少開發者仍舊堅定地選擇 Redis。Redis 在某些方面對開發者更友好，而且執行時間更長更穩定。對於 Garnet，大家在授權合約、產品定價、更新維護等方面普遍較為擔心。throwaway38375 表示，「Redis 在授權合約或者產品定價方面應該會更穩定，而且它畢竟經歷了數十億小時的生產執行考驗。Redis 也更容易安裝和理解。」Someone 認為，「對於這樣一個微軟研究院推出的計畫，我最擔心的不是授權合約和產品定價，而是缺乏更新（功能、維護甚至是安全更新）」。
By the way：Garnet 是用 C# 開發的
在社群討論中，不少開發者驚訝於 Garnet 計畫居然是用 C# 開發的。
開發者 west0n 表示：「最讓我驚訝的是，Garnet 計畫居然是用 C# 開發的，而 Dragonfly 是用 C++ 開發的，Redis 則是用 C 開發的。」開發者 whimsicalism 更是直言「太意外了，垃圾收集語言 C# 編寫的 Garnet 居然擊敗了 Redis 和 Dragonfly。」
也有開發者對此給出的評價較為中肯，pjmlp 認為「垃圾收集語言跟垃圾收集語言可不一樣，像 C# 和.NET 這些語言其實提供了跟 C++ 相當的所有效能調優選項。」他表示，大家該做的是認真學習，而不是把所有垃圾收集語言都歸為一類，再一棒子打死。
此外，更具體地講，MSIL 和.NET 在設計上也能支持 C++，而 C# 和 F# 等語言也有辦法存取這些功能。即使某些功能未在語言語法層面公開，開發者也可以直接使用 C++/CLI 生成的 MSIL。
對此，你怎麽看呢？歡迎在評論區留下你的觀點。
參考連結 ：
https://www.microsoft.com/en-us/research/blog/introducing-garnet-an-open-source-next-generation-faster-cache-store-for-accelerating-applications-and-services/
https://www.thestack.technology/microsoft-takes-on-redis-with-new-open-source-garnet-cache-store/
https://news.ycombinator.com/item?id=39752504
