萬萬沒想到，Redis多線程版本居然比原生版本快那麼多

若是我告訴您有一個 Redis 的分支版本，它的性能比原生的 Redis 快 5 倍，並且延遲卻下降近 5 倍，你會不會想了解一下這個項目？而若是您再也不須要哨兵節點而且您的副本能夠接受讀取和寫入，這將有可能使分片數量減小 10 倍，這樣對你的吸引力是否是更大了呢？

我說的這個分支版本，它實際上是 Redis 的一個分叉版本，名叫 KeyDB 。KeyDB 是 Redis 開源的多線程分叉版本。本文咱們將提供最新的基準測試結果，並討論更強大的 KeyDB 實例如何減小集羣大小以及簡化堆棧。同時咱們還將討論了多線程體系結構，並演練了如何利用它實現性能的提高。

爲何要取個新名字，爲何要作 Redis 的分叉？

憑藉着咱們不受限制的代碼庫開發能力，KeyDB 可以在短期內取得長足的進步，而且所走的道路將在將來幾個月內破壞整個數據庫格局。

關於爲何首先搞一個 Redis 分叉的緣由，這是由於 KeyDB 和 Redis 在如何發展方面有不一樣的理念。咱們認爲易用性、高性能和「內置動力」的方法是創造良好用戶體驗的最佳方法。儘管咱們很是尊重 Redis 維護者，但咱們認爲 Redis 的方法過於注重代碼的簡單性，而以犧牲用戶的便利性爲代價。這致使常常須要藉助外部組件和方案來解決不少常見問題。

因爲存在乎見分歧，所以適合 KeyDB 的功能可能不適用於 Redis。而作一個新的分叉版本能夠容許咱們探索這一新的開發路徑並實現可能永遠不會成爲 Redis 一部分的功能。KeyDB 將與上游的 Redis 代碼變動保持同步，在適用的狀況下，咱們還給 Redis 提交錯誤修復和改進。咱們但願這兩個項目可以繼續發展並相互學習。

最新基準數據

KeyDB 於今年3月推出，儘管咱們的性能有所提升，但咱們仍然但願它能更快地發展。咱們最新的基準測試數據顯示，KeyDB的單個實例的每秒操做數（圖範圍爲53-5.49）比Redis（v5）的單個實例多5倍以上，而延遲（圖形範圍爲4.6-5.1）近5倍：

多線程的優點

增長 KeyDB 的單個實例/節點的功能能夠減小分片的須要，而且能夠大大減小數據移動的數量。您可能會問，與在單個節點上多線程化相比，在羣集中運行許多Redis 節點是否能夠得到比單線程多線程更多的吞吐量？您能夠像 Redis 同樣對 KeyDB 進行分片，這對數據庫進行水平擴展頗有意義。可是，若是您能夠選擇增長馬力而不購買第二輛車，那爲何不呢？除分片外，還可以擴展節點的大小，爲用戶增長了新的功能和選擇。這是 Redis 與 KeyDB 之間意見分歧的其中之一。這不只是社區中的常見討論點，仍是某些圈子中的爭論點。

所以，爲了回答 「用 KeyDB 運行更多線程看起來像什麼？」 這個問題，咱們提供了一些基本數字，以便您對此問題有所瞭解。

如下是基準測試（操做/秒）與使用的線程數對應關係的圖表：

隨着分配更多資源給實例，您能夠看到性能獲得大幅提升。同時還能夠能夠將線程固定到某個CPU上以獲得進一步的提高，但最適合您的選擇可能取決於您的設置。默認狀況下，此選項是禁用的。

僅將一個線程分配給KeyDB，平均而言，與 Redis 的單個線程實例相比，它仍可保持約5％的性能提高。所以，即便添加了新功能並更改了體系結構，性能也沒有受到影響。

多線程架構

KeyDB 經過在多個線程上運行常規的 Redis 事件循環來工做。網絡 IO 和查詢解析是同時進行的。每一個鏈接在 accept() 上分配一個線程。自旋鎖保護對核心哈希表的訪問。由於哈希表訪問很是快，因此此鎖的爭用較低。事務在EXEC命令的持續時間內保持鎖定。模塊與GIL協同工做，而GIL僅在全部服務器線程都暫停時才獲取。這保持了模塊指望的原子性保證。

與大多數數據庫不一樣，核心數據結構是系統中最快的部分。查詢的大部分時間來自解析REPL協議並將數據複製到網絡或從網絡複製數據。

將來的工做包括容許在鏈接以後從新平衡與不一樣線程的鏈接，並容許多個讀取器同時訪問哈希表

進一步優化設置

此外，KeyDB 還提供了一些有助於簡化用戶體驗的功能。例如活動副本功能已在最新的穩定版本 5 中普遍採用並在生產中使用。此功能使您可以在兩個主節點彼此複製，同時接受讀取和寫入操做。並且不須要哨點節點來控制故障轉移。您將得到很高的可用性，同時最大限度地利用資源。若是還沒有平衡對副本節點的讀取，則可使用此選項將吞吐量提升一倍。這意味着從簡單的 Redis 主副本設置轉移到使用 KeyDB 的多線程活動副本設置，能夠將分片需求減小多達10倍。