介紹
redis做爲一款優秀的NoSQL表明軟件,正變得愈來愈流行,雖然Redis很容易就能夠啓動並使用,可是要想在線上用好它卻也並不是易事。redis的高可用和可擴展不管是自帶的Redis Sentinel仍是Redis Cluster都要求客戶端進行額外的支持,而目前基本上沒有合適的客戶端可以作這些事情,實際上客戶端來作這些事情也並不合適,它會讓維護變得特別困難。所以在客戶端和redis服務端之間加一層代理成了一種理想的方案,代理屏蔽後端Redis實現細節向客戶端提供redis服務,能夠完美的解決Redis的高可用和擴展性問題,同時代理的引入也使得Redis維護變得更加簡單。在本文所要介紹的代理predixy以前,已經有幾款流行的redis代理,它們各具特點。接下來,咱們就來比較如下代理:redis
代理 簡介
詳細功能對比
簡單來講,predixy既支持Redis Sentinel也支持Redis Cluster後端
後端爲Redis Sentinel監控的一組Redis,功能徹底等同於原始Redis
後端爲Redis Sentinel監控的多組Redis,則有部分功能受限
後端爲Redis Cluster,功能徹底等同於Redis Cluster
性能
做爲redis代理,高性能是硬性要求,爲了測試上面四款代理的性能接下來咱們就來作個簡單的評測,測試平臺及各代理具體的版本信息以下:緩存
redis部署:
多線程
單線程SET/GET測試
這裏單線程是指四款代理都運行在單線程下(下同),redis-benchmark默認併發50個客戶端鏈接,每一個鏈接每次發送一個命令收到響應後再發下一個命令。這是不少線上實際的場景。併發
測試命令:
$ redis-benchmark -p xxx -t set,get -r 3000 -n 1000000 -d xxx
測試結果:
ide
結果說明:
在吞吐上,四款代理的性能排列的整齊有序,predixy大幅領先於另外三款代理,而twemproxy又以較大優點領先另外兩個,剩下的兩個codis在數據量小於512的時候稍稍領先cerberus,而當數據量大於512的時候,codis對cerberus的領先愈來愈大。總體上在數據量達到16KB時,因爲redis-benchmark自己成爲瓶頸,predixy和twemproxy的SET成績差很少了。
在延時上,codis因爲語言的問題,一直都大於另外三款代理,後續測試也同樣。性能
單線程PIPELINE SET/GET測試
在有些場景下,客戶端可能在處理一個請求時可能須要發起屢次redis請求,這時若是把多個redis請求pipeline一塊兒請求的話,會大幅改善性能。本輪測試就來看看當客戶端一次發送多個請求時咱們各代理表現如何?Redis-benchmark依舊是併發50個鏈接,可是一次發送20個命令。測試
測試命令:
$ redis-benchmark -p xxx -t set,get -r 3000 -n 5000000 -P 20 -d xxx
測試結果:
結果說明:
在吞吐上,redis-benchmark一次pipeline 20個命令後,各代理的吞吐量全都猛增。predixy更是一騎絕塵,遙遙領先另外三個,而最後看到在GET 4K數量據的時候predixy表現和其它代理差很少是由於對predixy來講,當數據量大於2K時redis-benchmark自身已經成爲瓶頸。另外三款代理,在上輪測試中落後的cerberus在本輪測試一開始表現遠好過twemproxy和codis,但cerberus仍是存在隨着數據量變大性能迅速下降的問題。twemproxy和codis在本輪測試中表現基本至關。
在時延上,codis固有的問題表現較差,另外三款在數據量較小時差異較小,而當數據量超過512時,predixy則表現出較明顯的優點。線程
雙線程PIPELINE SET/GET測試
測完了單線程,如今咱們開始多線程測試,因爲twemproxy不支持多線程,所以twemproxy不參與多線程的測試。考慮到redis-benchmark自己是個單線程程序,在多線程代理下若是咱們再測單個命令的性能,那redis-benchmark極可能就是瓶頸,則沒法更明確的看出各代理的性能差別,所以咱們直接測試pipeline,還跟上輪同樣,50個併發鏈接,一次發送20個命令。3d
測試命令:
$ redis-benchmark -p xxx -t set,get -r 3000 -n 10000000 -P 20 -d xxx
測試結果:
結果說明:
整體趨勢和第二輪單線程pipeline測試一致,predixy在本輪測試中依舊取得了領先,不過在開始階段cerberus和predixy遙遙領先於codis,cerberus和predixy差距不大。可是隨着數據量的變大,cerberus再次顯示出了性能急劇下降的問題,到1K之後甚至就比codis差了。
結論
在功能的對比上,predixy相比另外三款代理更爲全面,基本能夠徹底適用原生redis的使用場景。在性能上,predixy在各輪測試中都以較大優點領先。對各代理的總結以下:
predixy:功能全面,既可使用單個主從redis,也可以使用Redis Cluster;性能優異。twemproxy:高可用依賴一致性哈希,僅在緩存場景下適用,不適用存儲使用;性能中等。codis:適用redis集羣使用;性能通常。cerberus:適用使用Redis Cluster;在數據量較小且pipeline使用狀況下性能尚可,不然性能較差。