介紹
redis作為一款優(yōu)秀的NoSQL代表軟件绪钥，正變得越來越流行痒蓬，雖然Redis很容易就可以啟動并使用王财，但是要想在線上用好它卻也并非易事徽级。redis的高可用和可擴(kuò)展無論是自帶的Redis Sentinel還是Redis Cluster都要求客戶端進(jìn)行額外的支持舌剂，而目前基本上沒有合適的客戶端能夠做這些事情济锄，實際上客戶端來做這些事情也并不合適，它會讓維護(hù)變得特別困難霍转。因此在客戶端和redis服務(wù)端之間加一層代理成了一種理想的方案荐绝，代理屏蔽后端Redis實現(xiàn)細(xì)節(jié)向客戶端提供redis服務(wù)，可以完美的解決Redis的高可用和擴(kuò)展性問題避消，同時代理的引入也使得Redis維護(hù)變得更加簡單低滩。在本文所要介紹的代理predixy之前，已經(jīng)有幾款流行的redis代理岩喷，它們各具特色恕沫。接下來，我們就來比較以下代理：
| 代理 | 簡介 |
|---|---|
| predixy | 高性能全特征redis代理均驶，支持Redis Sentinel和Redis Cluster |
| twemproxy | 快速昏兆、輕量級memcached和redis代理 |
| codis | redis集群代理解決方案 |
| redis-cerberus | Redis Cluster代理 |
詳細(xì)功能對比
| 特性 | predixy | twemproxy | codis | redis-cerberus |
|---|---|---|---|---|
| 高可用 | Redis Sentinel或Redis Cluster | 一致性哈希 | Redis Sentinel | Redis Cluster |
| 可擴(kuò)展 | Key哈希分布或Redis Cluster | Key哈希分布 | Key哈希分布 | Redis Cluster |
| 開發(fā)語言 | C++ | C | GO | C++ |
| 多線程 | 是 | 否 | 是 | 是 |
| 事務(wù) | Redis Sentinel模式單Redis組下支持 | 不支持 | 不支持 | 不支持 |
| BLPOP/BRPOP/BLPOPRPUSH | 支持 | 不支持 | 不支持 | 支持 |
| Pub/Sub | 支持 | 不支持 | 不支持 | 支持 |
| Script | 支持load | 不支持 | 不支持 | 不支持 |
| Scan | 支持 | 不支持 | 不支持 | 不支持 |
| Select DB | 支持 | 不支持 | 支持 | Redis Cluster只有一個DB |
| Auth | 支持定義多個密碼，給予不同讀寫及管理權(quán)限和Key訪問空間 | 不支持 | 同redis | 不支持 |
| 讀從節(jié)點 | 支持妇穴，可定義豐富規(guī)則讀指定的從節(jié)點 | 不支持 | 支持爬虱，簡單規(guī)則 | 支持，簡單規(guī)則 |
| 多機(jī)房支持 | 支持腾它，可定義豐富規(guī)則調(diào)度流量 | 不支持 | 有限支持 | 有限支持 |
| 統(tǒng)計信息 | 豐富 | 豐富 | 豐富 | 簡單 |
簡單來說跑筝，predixy既支持Redis Sentinel也支持Redis Cluster
- 后端為Redis Sentinel監(jiān)控的一組Redis，功能完全等同于原始Redis
- 后端為Redis Sentinel監(jiān)控的多組Redis瞒滴，則有部分功能受限
- 后端為Redis Cluster曲梗，功能完全等同于Redis Cluster
性能
作為redis代理，高性能是硬性要求妓忍，為了測試上面四款代理的性能接下來我們就來做個簡單的評測虏两，測試平臺及各代理具體的版本信息如下：
| 名稱 | 內(nèi)容 |
|---|---|
| CPU | AMD Ryzen 7 1700X Eight-Core Processor 3.775GHz |
| 內(nèi)存 | 16GB DDR4 3000 |
| 系統(tǒng) | x86_64 GNU/Linux 4.10.0-27-generic #30~16.04.2-Ubuntu |
| predixy | 版本1.0.1，源碼默認(rèn)參數(shù)編譯 |
| twemproxy | 版本0.4.1世剖，源碼默認(rèn)參數(shù)編譯 |
| codis | 二進(jìn)制發(fā)布版本codis3.2.0-go1.8.1-linux.tar.gz |
| cerberus | github遷出8d68a5d源碼默認(rèn)參數(shù)編譯 |
redis-server定罢、各代理、redis-benchmark均在這一臺機(jī)器上運行旁瘫。
redis部署：
| 代理 | redis后端部署 |
|---|---|
| predixy | redis cluster模式部署三個redis主節(jié)點, slots平分 |
| twemproxy | 三個redis主節(jié)點祖凫，采用crc16哈希琼蚯，modula分布 |
| codis | 三個redis主節(jié)點，slots平分 |
| cerberus | redis cluster模式部署三個redis主節(jié)點, slots平分 |
以下測試的結(jié)果中惠况，橫坐標(biāo)為數(shù)據(jù)大小遭庶、縱坐標(biāo)為qps或者毫秒。
單線程SET/GET測試
這里單線程是指四款代理都運行在單線程下（下同）稠屠，redis-benchmark默認(rèn)并發(fā)50個客戶端連接峦睡，每個連接每次發(fā)送一個命令收到響應(yīng)后再發(fā)下一個命令。這是很多線上實際的場景权埠。
測試命令：
$ 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)和其它代理差不多是因為對predixy來說再沧，當(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使用情況下性能尚可嚷炉，否則性能較差。
