《電子技術應用》
您所在的位置:首頁 > 嵌入式技術 > 設計應用 > Redis集群性能測試分析
Redis集群性能測試分析
2016年微型機與應用第10期
柳皓亮,王麗,周陽辰
(中國科學院電子學研究所蘇州研究院 存儲計算組, 江蘇 蘇州 215123)
摘要: Redis是一個非關系型數(shù)據(jù)庫,屬于內存級數(shù)據(jù)庫。但是由于數(shù)據(jù)量的不斷增大,單機的Redis物理內存遠遠無法滿足大數(shù)據(jù)的需要,因此需要搭建分布式的Redis,可以動態(tài)擴展內存,彌補單機Redis物理內存不夠的缺點。本次測試旨在對Redis各方面性能有深入的了解,為今后的工作打好基礎。本次實驗的目的主要是搭建Redis Cluster和TwemProxy Redis兩種集群,分別對其進行性能測試,測試出集群性能的拐點,找出性能的瓶頸有哪些,并對兩套集群進行比較,以便于在不同業(yè)務場景下?lián)駜?yōu)選擇。
Abstract:
Key words :

  柳皓亮,王麗,周陽辰

  (中國科學院電子學研究所蘇州研究院 存儲計算組, 江蘇 蘇州 215123)

  摘要:Redis是一個非關系型數(shù)據(jù)庫,屬于內存級數(shù)據(jù)庫。但是由于數(shù)據(jù)量的不斷增大,單機的Redis物理內存遠遠無法滿足大數(shù)據(jù)的需要,因此需要搭建分布式的Redis,可以動態(tài)擴展內存,彌補單機Redis物理內存不夠的缺點。本次測試旨在對Redis各方面性能有深入的了解,為今后的工作打好基礎。本次實驗的目的主要是搭建Redis ClusterTwemProxy Redis兩種集群,分別對其進行性能測試,測試出集群性能的拐點,找出性能的瓶頸有哪些,并對兩套集群進行比較,以便于在不同業(yè)務場景下?lián)駜?yōu)選擇。

  關鍵詞:Redis Cluster;TwemProxy Redis;性能測試

1存儲測試分析

  本次存儲測試是用Java程序調用Jedis提供的API向集群里面灌入數(shù)據(jù)。首先研究灌入少量數(shù)據(jù)后兩種集群的數(shù)據(jù)分布在哪些節(jié)點上,然后研究灌入大量數(shù)據(jù)后兩種集群的落盤情況。

  1.1Redis Cluster

 ?。?)少量數(shù)據(jù)儲存分析

  用程序向某一個節(jié)點灌入30條數(shù)據(jù),結果發(fā)現(xiàn)每個節(jié)點擁有部分數(shù)據(jù),數(shù)據(jù)存儲得很分散。由此可知,數(shù)據(jù)落盤時把一份數(shù)據(jù)分成多份存儲在不同的Redis節(jié)點上,進行分片存儲,通過調研得知這種分配方式是通過sharding算法分配[1]的。

  (2)大量數(shù)據(jù)存儲分析

  首先查看單節(jié)點未插入數(shù)據(jù)前的rdb大小為18 B;然后,用Java程序插入10萬條數(shù)據(jù),查看rdb大小為1 289 892 B,然后改用Java程序向Redis Cluster集群中灌入10萬條數(shù)據(jù),查看每個節(jié)點rdb文件大小分別為214 912 B、216 586 B、215 939 B、214 145 B和213 757 B。由此可見,單機的rdb大小約等于每個Redis節(jié)點rdb大小之和,并且每個節(jié)點rdb大小相對均衡。綜上所述,這種落盤方式把一份數(shù)據(jù)平均分配到每一個節(jié)點上,也就是說每一個節(jié)點的rdb文件共同組成一份完整的數(shù)據(jù)。

  1.2TwemProxy Redis

 ?。?)少量數(shù)據(jù)存儲分析

  向集群中插入20條key為0~19的數(shù)據(jù),查看數(shù)據(jù)在各個Redis節(jié)點分布情況,結果發(fā)現(xiàn)某個節(jié)點存儲第0~9的數(shù)據(jù),另一個節(jié)點存儲11~19的數(shù)據(jù),最后一個節(jié)點沒有存儲數(shù)據(jù)。經過多次相同參數(shù)測試,每次落盤結果相同,由此可見TwemProxy[2]根據(jù)相應算法將數(shù)據(jù)落盤到各個節(jié)點中,并且分配算法是對一段連續(xù)的數(shù)據(jù)進行落盤,而不是對每一條數(shù)據(jù)進行選擇存入到哪個節(jié)點中的操作,這樣可以減少路由開銷。

 ?。?)大量數(shù)據(jù)存儲分析

  首先查看單機Redis節(jié)點未插入數(shù)據(jù)前的rdb文件大小為84 B; 然后插入10萬條數(shù)據(jù),查看rdb文件大小為1.6 MB;接著改用Java程序向TwemProxy Redis[2]集群中灌入10萬條數(shù)據(jù),查看各各節(jié)點rdb文件大小分別為0.49 MB、0.62 MB和0.51 MB。由此可見,單機的rdb大小約等于每個Redis節(jié)點rdb大小之和,并且每個節(jié)點rdb大小相對均衡。由此可見,這種落盤方式把一份數(shù)據(jù)平均分配到每一個節(jié)點上,也就是說每一個節(jié)點的rdb文件共同組成一份完整的數(shù)據(jù)。

2使用Java代碼測試吞吐率

  主要從3個方面進行測試,當value類型分別是String類型、list類型和map類型時,統(tǒng)計吞吐率的走勢,找出拐點,并分析原因[2]。

  2.1Redis Cluster

 ?。?)String插入測試——吞吐率隨value大小變化情況:當吞吐量一定時并且插入的是String類型數(shù)據(jù)時,如果value值在1 KB以內時,吞吐率基本保持不變;如果 value值大于1 KB,吞吐率隨value增大而減小。當value值達到10 KB且請求總量為1萬條時,共100 MB的數(shù)據(jù),內存遠遠沒有被打滿,即此時內存的使用率仍比較低,所以此時Redis數(shù)據(jù)存儲瓶頸[3]并不是內存。同時監(jiān)控了網卡和IO,發(fā)現(xiàn)均處于正常水平,所以也不是這兩方面的原因。所以可以推出,此時吞吐率下降是由于Redis本身不能夠承受過大的value值。

 ?。?)String插入測試——吞吐率隨吞吐量變化情況:當value大小一定時,吞吐量的增大對吞吐率沒有影響。

  (3)String獲取測試——吞吐率隨value大小變化關系:結果與(2)相同。

 ?。?)List插入測試——吞吐率隨List大小變化情況:當List元素大小和吞吐量一定時,吞吐率隨list的size增大而減小,size從10增加大100時吞吐率下降了一半。由此可見,Redis Cluster對List的支持效果并不好,性能有待提升,不建議在以后的項目階段用Redis Cluster存儲List。

  (5)List插入測試——吞吐率隨List元素字節(jié)大小變化情況: List的元素字節(jié)大小變化對吞吐率沒有影響。

  (6)List插入測試——吞吐率隨吞吐量大小的變化關系:吞吐率與吞吐量無關。

  (7)Map插入測試——吞吐率隨Map size大小變化關系:當吞吐量和元素字節(jié)一定時,吞吐率隨Map的size增大而減小。

 ?。?)Map插入測試——吞吐率隨Map的value大小變化情況:當吞吐量和Map的size一定時,吞吐率隨Map元素字節(jié)增大而減小。

  2.2TwemProxy Redis

  TwemProxy Redis[2]采用單條讀寫和批量讀寫兩種方式進行壓力測試,測試結果如下。

  (1)String單條插入測試——吞吐率隨value大小變化情況:value值在1 KB以內且總請求量為1萬時吞吐率基本保持不變;當value值大于1 KB時, 吞吐率隨value增大而減小,單條TwemProxy Redis的插入吞吐率明顯比Redis Cluster低。

 ?。?)String批量插入測試——吞吐率隨value大小變化情況:當吞吐量一定時,value值小于100 B時,吞吐率隨value增大而增大;當value值大于100 B時,吞吐率隨value增大而減小。由此可見,批量插入存在極值點,此外批量插入的吞吐率遠遠高于TwemProxy Redis和Redis Cluster的單條插入。

 ?。?)String單條獲取測試——吞吐率隨value大小變化關系:測試結果與(1)的結果相同。由此可見,TwemProxy Redis的單條讀寫效率一致。

  (4)String批量獲取測試——吞吐率隨value大小變化關系:結果與(2)相同。

  (5)String單條插入測試——吞吐率隨吞吐量的變化關系:吞吐率與吞吐量無關,TwemProxy Redis吞吐率只有Redis Cluster的一半,明顯吞吐率很低。

 ?。?)String批量插入測試——吞吐率隨吞吐量的變化關系:隨著吞吐量的增加,吞吐率也在增加。但在測試時將請求量給到10萬條后,程序宕掉并且集群服務停止工作,說明pipeline批量打包的數(shù)據(jù)量有限,即性能是有限的。但是可以通過打包多次解決這個問題,批量插入的吞吐率明顯高于TwemProxy Cluster和Redis Cluster的單條插入吞吐率。

  (7)List和Map類型的單條插入測試吞吐率變化:吞吐率變化與Redis Cluster的相同,但是吞吐率低于Redis Cluster。

  (8)List和Map類型的單條插入測試吞吐率變化:吞吐率變化與Redis Cluster的相同,但是吞吐率高于TwemProxy Cluster和Redis Cluster的單條吞吐率。

3結論

 ?。?) TwemProxy Redis的批量讀寫吞吐率遠遠高于Redis Cluster單條的吞吐率,Redis Cluster單條讀寫的吞吐率略高于TwemPrxoy Redis單條吞吐率。

 ?。?) Redis Cluster和TwemPrxoy Redis對List和Map集合的吞吐率很低,不建議存儲這兩種類型的數(shù)據(jù)。

  (3)當需要進行TwemProxy Redis批量操作時,需要通過程序保證一次批量讀寫的數(shù)據(jù)量不宜過大,否則底層服務會宕掉。

參考文獻

 ?。?] 王敏,陳亞光.數(shù)據(jù)庫系統(tǒng)輔助測試工具[J].微型機與應用,2013,32(3):1315,18.

 ?。?] 夏文忠,鄒雯奇.基于X86平臺的高性能數(shù)據(jù)庫集群技術的研究[J].微型機與應用,2015,34(1):3639,46.

 ?。?] 張蕾,侯瑞春,丁香乾,等.會話保持機制在集群系統(tǒng)中的應用研究[J].微型機與應用,2015,34(9):3234,50.


此內容為AET網站原創(chuàng),未經授權禁止轉載。