介紹

redis作為一款優(yōu)秀的NoSQL代表軟件，正變得越來越流行，雖然Redis很容易就可以啟動并使用，但是要想在線上用好它卻也并非易事。redis的高可用和可擴(kuò)展無論是自帶的Redis Sentinel還是Redis Cluster都要求客戶端進(jìn)行額外的支持，而目前基本上沒有合適的客戶端能夠做這些事情，實(shí)際上客戶端來做這些事情也并不合適，它會讓維護(hù)變得特別困難。因此在客戶端和redis服務(wù)端之間加一層代理成了一種理想的方案，代理屏蔽后端Redis實(shí)現(xiàn)細(xì)節(jié)向客戶端提供redis服務(wù)，可以完美的解決Redis的高可用和擴(kuò)展性問題，同時代理的引入也使得Redis維護(hù)變得更加簡單。在本文所要介紹的代理predixy之前，已經(jīng)有幾款流行的redis代理，它們各具特色。接下來，我們就來比較以下代理：

詳細(xì)功能對比

簡單來說，predixy既支持Redis Sentinel也支持Redis Cluster

• 后端為Redis Sentinel監(jiān)控的一組Redis，功能完全等同于原始Redis
• 后端為Redis Sentinel監(jiān)控的多組Redis，則有部分功能受限
• 后端為Redis Cluster，功能完全等同于Redis Cluster

性能

作為redis代理，高性能是硬性要求，為了測試上面四款代理的性能接下來我們就來做個簡單的評測，測試平臺及各代理具體的版本信息如下：

redis-server、各代理、redis-benchmark均在這一臺機(jī)器上運(yùn)行。

redis部署：

以下測試的結(jié)果中，橫坐標(biāo)為數(shù)據(jù)大小、縱坐標(biāo)為qps或者毫秒。

單線程SET/GET測試

這里單線程是指四款代理都運(yùn)行在單線程下（下同），redis-benchmark默認(rèn)并發(fā)50個客戶端連接，每個連接每次發(fā)送一個命令收到響應(yīng)后再發(fā)下一個命令。這是很多線上實(shí)際的場景。

測試命令：

$ redis-benchmark -p xxx -t set,get -r 3000 -n 1000000 -d xxx                                                           

測試結(jié)果：

結(jié)果說明：

在吞吐上，四款代理的性能排列的整齊有序，predixy大幅領(lǐng)先于另外三款代理，而twemproxy又以較大優(yōu)勢領(lǐng)先另外兩個，剩下的兩個codis在數(shù)據(jù)量小于512的時候稍稍領(lǐng)先cerberus，而當(dāng)數(shù)據(jù)量大于512的時候，codis對cerberus的領(lǐng)先越來越大。整體上在數(shù)據(jù)量達(dá)到16KB時，由于redis-benchmark本身成為瓶頸，predixy和twemproxy的SET成績差不多了。
在延時上，codis由于語言的問題，一直都大于另外三款代理，后續(xù)測試也一樣。

單線程PIPELINE SET/GET測試

在有些場景下，客戶端可能在處理一個請求時可能需要發(fā)起多次redis請求，這時如果把多個redis請求pipeline一起請求的話，會大幅改善性能。本輪測試就來看看當(dāng)客戶端一次發(fā)送多個請求時我們各代理表現(xiàn)如何？Redis-benchmark依舊是并發(fā)50個連接，但是一次發(fā)送20個命令。

測試命令：

$ redis-benchmark -p xxx -t set,get -r 3000 -n 5000000 -P 20 -d xxx

測試結(jié)果：

結(jié)果說明：

在吞吐上，redis-benchmark一次pipeline 20個命令后，各代理的吞吐量全都猛增。predixy更是一騎絕塵，遙遙領(lǐng)先另外三個，而最后看到在GET 4K數(shù)量據(jù)的時候predixy表現(xiàn)和其它代理差不多是因?yàn)閷redixy來說，當(dāng)數(shù)據(jù)量大于2K時redis-benchmark自身已經(jīng)成為瓶頸。另外三款代理，在上輪測試中落后的cerberus在本輪測試一開始表現(xiàn)遠(yuǎn)好過twemproxy和codis，但cerberus還是存在隨著數(shù)據(jù)量變大性能迅速降低的問題。twemproxy和codis在本輪測試中表現(xiàn)基本相當(dāng)。
在時延上，codis固有的問題表現(xiàn)較差，另外三款在數(shù)據(jù)量較小時差別較小，而當(dāng)數(shù)據(jù)量超過512時，predixy則表現(xiàn)出較明顯的優(yōu)勢。

雙線程PIPELINE SET/GET測試

測完了單線程，現(xiàn)在我們開始多線程測試，由于twemproxy不支持多線程，因此twemproxy不參與多線程的測試。考慮到redis-benchmark本身是個單線程程序，在多線程代理下如果我們再測單個命令的性能，那redis-benchmark很可能就是瓶頸，則無法更明確的看出各代理的性能差異，因此我們直接測試pipeline，還跟上輪一樣，50個并發(fā)連接，一次發(fā)送20個命令。

測試命令：

$ redis-benchmark -p xxx -t set,get -r 3000 -n 10000000 -P 20 -d xxx

測試結(jié)果：

結(jié)果說明：

總體趨勢和第二輪單線程pipeline測試一致，predixy在本輪測試中依舊取得了領(lǐng)先，不過在開始階段cerberus和predixy遙遙領(lǐng)先于codis，cerberus和predixy差距不大。但是隨著數(shù)據(jù)量的變大，cerberus再次顯示出了性能急劇降低的問題，到1K以后甚至就比codis差了。

結(jié)論

在功能的對比上，predixy相比另外三款代理更為全面，基本可以完全適用原生redis的使用場景。在性能上，predixy在各輪測試中都以較大優(yōu)勢領(lǐng)先。對各代理的總結(jié)如下：

• predixy：功能全面，既可以使用單個主從redis，也可使用Redis Cluster；性能優(yōu)異。
• twemproxy：高可用依賴一致性哈希，僅在緩存場景下適用，不適用存儲使用；性能中等。
• codis：適用redis集群使用；性能一般。
• cerberus：適用使用Redis Cluster；在數(shù)據(jù)量較小且pipeline使用情況下性能尚可，否則性能較差。