Redis Enterprise新版優化線性擴充套件，效能測試有點厲害！

在Redis Enterprise 5.0版本中，其團隊引入了對開源（OSS）叢集API的支援，允許Redis Enterprise叢集通過新增分片和節點以線性方式進行擴充套件。本文給出了第一個線性擴充套件基準測試，並展示了這種無限的線性擴充套件能力。

線性擴充套件是什麼？

根據維基百科的介紹，可擴充套件的資料庫是一個可以通過新增新的處理器和儲存來升級處理更多事務的資料庫，並且可以在不影響使用的情況下輕鬆升級。資料庫可以向外擴充套件（通過向叢集新增節點，重新平衡並分配資料庫）或向上擴充套件（通過向資料庫新增分片而無需向叢集新增節點）。Redis Enterprise經過優化，只需將其繫結到磁碟即可擴充套件。

線性擴充套件意味著通過新增與吞吐量相關的資源（在Redis術語中，“資源”指的是節點和分片）來順序擴充套件資料庫。真正的線性可擴充套件意味著資源量以與資料庫吞吐量以相同的比例增加，並且以確定的方式增加。例如，將叢集資源增加50％將導致吞吐量增加50％。

如果資料庫可以線性擴充套件，則可以最大限度地降低運營開銷並可擴充套件業務，而無需擔心資料庫中的大小限制或效能瓶頸。但是，通常會出現與擴充套件相關的開銷，這意味著當容量增加N時，資料庫吞吐量通常會增加一個比N少（或少得多）的數字。

資料庫提供：

• 亞線性擴充套件——當相對容量小於資源數量時。

• 線性擴充套件——當相對容量等於新增資源的相對數量時。

• 超線性擴充套件——當相對容量因增加資源而增加時。

Redis Enterprise的簡要介紹

Redis Enterprise術語中的叢集是一組雲例項，虛擬機器/容器節點或裸機伺服器，允許建立任意數量的Redis資料庫（Redis Enterprise術語中的資料庫是跨多個Redis分片/例項管理整個資料集的實體，不要將此與每個Redis例項中的資料庫混淆，你可以使用Redis SELECT命令在鍵空間中進行分段）在整個集合共享的記憶體池中。叢集具有對稱的無共享架構，資料路徑與控制和管理路徑之間完全分離，它包括以下主要元件：

• Redis Shards-具有主或從的Redis例項

• Zero-latency Proxy- 構建在多執行緒、無狀態架構之上，負責隱藏叢集的複雜性，增強安全性（SSL，身份驗證，DDoS保護）並提高效能（無TCP連線管理）

• Cluster Manager（控制和管理路徑） - 由叢集節點上的一組分散式程式構建，負責叢集配置、響應請求、資源管理等工作，以及充當資源監視器並完全使Redis分片管理叢集中其他分片的執行狀況或執行故障轉移。

可以在以下任何一種配置中建立Redis Enterprise叢集中的資料庫：

 

構建測試環境

綜合各方面因素，其團隊決定在AWS上構建測試環境，以驗證Redis Enterprise是否能夠以線性方式實現無限擴充套件。最終測試使用的是EC2 m4.16xlarge例項（64核，256GB RAM）用於叢集節點和c4.8xlarge例項（36核，60GB RAM）用於執行memtier_benchmark，一個開源多執行緒負載生成工具。

使用多個memtier_benchmark例項是必須的，因為在許多情況下，單Redis Enterprise節點可以處理比單memtier_benchmark例項更多的流量，這種方法可避免單個NIC網路頻寬和資料每秒傳輸限制，並且可以逐步（逐個例項）增加流量負載。

這是其團隊的最終設定：

Redis Enterprise叢集節點的6x m4.16xlarge例項：

 

執行memtier_benchmark的8x c4.8xlarge例項：

 

在過去幾個月，其團隊進行了多次測試，其中包括k節點Redis Enterprise叢集其他基準測試n-shard資料庫，如下所示：

表1：Redis Enterprise線性擴充套件，同時提供亞毫秒級效能。

圖1：叢集吞吐量（@ 1毫秒延遲）

這表明隨著吞吐量的增加，其節點的線性擴充套件能力增加，Redis Enterprise能夠在所有資料大小和工作負載上始終如一地提供亞毫秒級延遲。

建立和調整叢集資料庫

其團隊使用Redis Enterprise API建立了一個192-shard叢集Redis資料庫，其中包含以下引數：

我們通過將proxy 執行緒數設定為24來調整每個節點上的proxy以應對預期的負載：

當然，其他資料庫供應商也釋出了許多關於其擴充套件能力的基準測試資料。實際上，結果表明Redis Enterprise的表現優於NoSQL同行。以下圖表是其他NoSQL供應商的基準測試結果，該圖表比較了Apache Cassandra，HBase，MongoDB和Couchbase。

從圖表中可以看出，所有供應商都提供了亞線性擴充套件能力。例如，如果按節點分析Cassandra的吞吐量，Cassandra的1個節點可處理大約18,700 ops /秒，以此類推，32個節點時應該能夠處理大約600,000 ops /秒。但實際上，它只能處理大約330,000ops /秒，只具備真正線性擴充套件資料庫55％的能力。

憑藉其最新的基準測試，Redis Enterprise已證明其每秒能夠處理數百萬次操作，即使在最基本的配置情況下也是如此。如下圖所示，Redis Enterprise的效能優於其他資料庫，可提供超線性擴充套件而不會影響效能！

表3：Redis Enterprise ——節點的最佳與實際吞吐量

這一新的基準測試證明了Redis Enterprises能夠實現真正的線性可擴充套件性，同時通過有效的資源利用提供強大的效能，但是，基準測試中並未提到其他參與資料庫的版本是企業版還是開源版，因此資料還有待考量。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31077337/viewspace-2213708/，如需轉載，請註明出處，否則將追究法律責任。