如果我告訴您有一個(gè) Redis 的分支版本，它的性能比原生的 Redis 快 5 倍，而且延遲卻降低近 5 倍，你會(huì)不會(huì)想了解一下這個(gè)項(xiàng)目?而如果您不再需要哨兵節(jié)點(diǎn)并且您的副本可以接受讀取和寫入，這將有可能使分片數(shù)量減少 10 倍，這樣對(duì)你的吸引力是不是更大了呢?

我說的這個(gè)分支版本，它其實(shí)是 Redis 的一個(gè)分叉版本，名叫 KeyDB 。KeyDB 是 Redis 開源的多線程分叉版本。本文我們將提供最新的基準(zhǔn)測(cè)試結(jié)果，并討論更強(qiáng)大的 KeyDB 實(shí)例如何減少集群大小以及簡(jiǎn)化堆棧。同時(shí)我們還將討論了多線程體系結(jié)構(gòu)，并演練了如何利用它實(shí)現(xiàn)性能的提升。

為什么要取個(gè)新名字，為什么要做 Redis 的分叉?

憑借著我們不受限制的代碼庫(kù)開發(fā)能力，KeyDB 能夠在短時(shí)間內(nèi)取得長(zhǎng)足的進(jìn)步，并且所走的道路將在未來(lái)幾個(gè)月內(nèi)破壞整個(gè)數(shù)據(jù)庫(kù)格局。

關(guān)于為什么首先搞一個(gè) Redis 分叉的原因，這是因?yàn)?KeyDB 和 Redis 在如何發(fā)展方面有不同的理念。我們認(rèn)為易用性、高性能和“內(nèi)置動(dòng)力”的方法是創(chuàng)造良好用戶體驗(yàn)的最佳方法。盡管我們非常尊重 Redis 維護(hù)者，但我們認(rèn)為 Redis 的方法過于注重代碼的簡(jiǎn)單性，而以犧牲用戶的便利性為代價(jià)。這導(dǎo)致經(jīng)常需要借助外部組件和方案來(lái)解決很多常見問題。

由于存在意見分歧，因此適合 KeyDB 的功能可能不適用于 Redis。而做一個(gè)新的分叉版本可以允許我們探索這一新的開發(fā)路徑并實(shí)現(xiàn)可能永遠(yuǎn)不會(huì)成為 Redis 一部分的功能。KeyDB 將與上游的 Redis 代碼變更保持同步，在適用的情況下，我們還給 Redis 提交錯(cuò)誤修復(fù)和改進(jìn)。我們希望這兩個(gè)項(xiàng)目能夠繼續(xù)發(fā)展并相互學(xué)習(xí)。

最新基準(zhǔn)數(shù)據(jù)

KeyDB 于今年3月推出，盡管我們的性能有所提高，但我們?nèi)匀幌Ｍ芨斓匕l(fā)展。我們最新的基準(zhǔn)測(cè)試數(shù)據(jù)顯示，KeyDB的單個(gè)實(shí)例的每秒操作數(shù)(圖范圍為53-5.49)比Redis(v5)的單個(gè)實(shí)例多5倍以上，而延遲(圖形范圍為4.6-5.1)近5倍：

多線程的優(yōu)勢(shì)

增加 KeyDB 的單個(gè)實(shí)例/節(jié)點(diǎn)的功能可以減少分片的需要，并且可以大大減少數(shù)據(jù)移動(dòng)的數(shù)量。您可能會(huì)問，與在單個(gè)節(jié)點(diǎn)上多線程化相比，在群集中運(yùn)行許多Redis 節(jié)點(diǎn)是否可以獲得比單線程多線程更多的吞吐量?您可以像 Redis 一樣對(duì) KeyDB 進(jìn)行分片，這對(duì)數(shù)據(jù)庫(kù)進(jìn)行水平擴(kuò)展很有意義。但是，如果您可以選擇增加馬力而不購(gòu)買第二輛車，那為什么不呢?除分片外，還能夠擴(kuò)展節(jié)點(diǎn)的大小，為用戶增加了新的功能和選擇。這是 Redis 與 KeyDB 之間意見分歧的其中之一。這不僅是社區(qū)中的常見討論點(diǎn)，還是某些圈子中的爭(zhēng)論點(diǎn)。

因此，為了回答 “用 KeyDB 運(yùn)行更多線程看起來(lái)像什么?” 這個(gè)問題，我們提供了一些基本數(shù)字，以便您對(duì)此問題有所了解。

以下是基準(zhǔn)測(cè)試(操作/秒)與使用的線程數(shù)對(duì)應(yīng)關(guān)系的圖表：

隨著分配更多資源給實(shí)例，您可以看到性能得到大幅提高。同時(shí)還可以可以將線程固定到某個(gè)CPU上以得到進(jìn)一步的提升，但最適合您的選擇可能取決于您的設(shè)置。默認(rèn)情況下，此選項(xiàng)是禁用的。

僅將一個(gè)線程分配給KeyDB，平均而言，與 Redis 的單個(gè)線程實(shí)例相比，它仍可保持約5%的性能提升。因此，即使添加了新功能并更改了體系結(jié)構(gòu)，性能也沒有受到影響。

多線程架構(gòu)

KeyDB 通過在多個(gè)線程上運(yùn)行常規(guī)的 Redis 事件循環(huán)來(lái)工作。網(wǎng)絡(luò) IO 和查詢解析是同時(shí)進(jìn)行的。每個(gè)連接在 accept() 上分配一個(gè)線程。自旋鎖保護(hù)對(duì)核心哈希表的訪問。因?yàn)楣１碓L問非常快，所以此鎖的爭(zhēng)用較低。事務(wù)在EXEC命令的持續(xù)時(shí)間內(nèi)保持鎖定。模塊與GIL協(xié)同工作，而GIL僅在所有服務(wù)器線程都暫停時(shí)才獲取。這保持了模塊期望的原子性保證。

與大多數(shù)數(shù)據(jù)庫(kù)不同，核心數(shù)據(jù)結(jié)構(gòu)是系統(tǒng)中最快的部分。查詢的大部分時(shí)間來(lái)自解析REPL協(xié)議并將數(shù)據(jù)復(fù)制到網(wǎng)絡(luò)或從網(wǎng)絡(luò)復(fù)制數(shù)據(jù)。

未來(lái)的工作包括允許在連接之后重新平衡與不同線程的連接，并允許多個(gè)讀取器同時(shí)訪問哈希表

進(jìn)一步優(yōu)化設(shè)置

此外，KeyDB 還提供了一些有助于簡(jiǎn)化用戶體驗(yàn)的功能。例如活動(dòng)副本功能已在最新的穩(wěn)定版本 5 中廣泛采用并在生產(chǎn)中使用。此功能使您能夠在兩個(gè)主節(jié)點(diǎn)彼此復(fù)制，同時(shí)接受讀取和寫入操作。而且不需要哨點(diǎn)節(jié)點(diǎn)來(lái)控制故障轉(zhuǎn)移。您將獲得很高的可用性，同時(shí)最大限度地利用資源。如果尚未平衡對(duì)副本節(jié)點(diǎn)的讀取，則可以使用此選項(xiàng)將吞吐量提高一倍。這意味著從簡(jiǎn)單的 Redis 主副本設(shè)置轉(zhuǎn)移到使用 KeyDB 的多線程活動(dòng)副本設(shè)置，可以將分片需求減少多達(dá)10倍。