柳皓亮，王　麗，周陽辰（中國科學(xué)院電子學(xué)研究所蘇州研究院存儲計算組，江蘇蘇州215123）

?

Redis集群性能測試分析

柳皓亮，王麗，周陽辰
（中國科學(xué)院電子學(xué)研究所蘇州研究院存儲計算組，江蘇蘇州215123）

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

關(guān)鍵詞：Redis Cluster；TwemProxy Redis；性能測試

1　存儲測試分析

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

1.1Redis C luster

（1）少量數(shù)據(jù)儲存分析

用程序向某一個節(jié)點灌入30條數(shù)據(jù)，結(jié)果發(fā)現(xiàn)每個節(jié)點擁有部分數(shù)據(jù)，數(shù)據(jù)存儲得很分散。由此可知，數(shù)據(jù)落盤時把一份數(shù)據(jù)分成多份存儲在不同的Redis節(jié)點上，進行分片存儲，通過調(diào)研得知這種分配方式是通過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.2Twem Proxy Red is

（1）少量數(shù)據(jù)存儲分析

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

（2）大量數(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個方面進行測試，當(dāng)value類型分別是String類型、list類型和map類型時，統(tǒng)計吞吐率的走勢，找出拐點，并分析原因［2］。

2.1Redis C luster

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

（2）String插入測試——吞吐率隨吞吐量變化情況：當(dāng)value大小一定時，吞吐量的增大對吞吐率沒有影響。

（3）String獲取測試——吞吐率隨value大小變化關(guān)系：結(jié)果與（2）相同。

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

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

（6）List插入測試——吞吐率隨吞吐量大小的變化關(guān)系：吞吐率與吞吐量無關(guān)。

（7）Map插入測試——吞吐率隨Map size大小變化關(guān)系：當(dāng)吞吐量和元素字節(jié)一定時，吞吐率隨Map的size增大而減小。

（8）Map插入測試——吞吐率隨Map的value大小變化情況：當(dāng)吞吐量和Map的size一定時，吞吐率隨Map元素字節(jié)增大而減小。

2.2Twem Proxy Redis

TwemProxy Redis［2］采用單條讀寫和批量讀寫兩種方式進行壓力測試，測試結(jié)果如下。

（1）String單條插入測試——吞吐率隨value大小變化情況：value值在1 KB以內(nèi)且總請求量為1萬時吞吐率基本保持不變；當(dāng)value值大于1 KB時，吞吐率隨value增大而減小，單條TwemProxy Redis的插入吞吐率明顯比Redis Cluster低。

（2）String批量插入測試——吞吐率隨value大小變化情況：當(dāng)吞吐量一定時，value值小于100 B時，吞吐率隨value增大而增大；當(dāng)value值大于100 B時，吞吐率隨value增大而減小。由此可見，批量插入存在極值點，此外批量插入的吞吐率遠遠高于TwemProxy Redis和Redis Cluster的單條插入。

（3）String單條獲取測試——吞吐率隨value大小變化關(guān)系：測試結(jié)果與（1）的結(jié)果相同。由此可見，Twem-Proxy Redis的單條讀寫效率一致。

（4）String批量獲取測試——吞吐率隨value大小變化關(guān)系：結(jié)果與（2）相同。

（5）String單條插入測試——吞吐率隨吞吐量的變化關(guān)系：吞吐率與吞吐量無關(guān)，TwemProxy Redis吞吐率只有Redis Cluster的一半，明顯吞吐率很低。

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

（7）List和Map類型的單條插入測試吞吐率變化：吞吐率變化與Redis Cluster的相同，但是吞吐率低于Redis Cluster。

（8）List和Map類型的單條插入測試吞吐率變化：吞吐率變化與Redis Cluster的相同，但是吞吐率高于Twem-Proxy Cluster和Redis Cluster的單條吞吐率。

3　結(jié)論

（1）TwemProxy Redis的批量讀寫吞吐率遠遠高于Redis Cluster單條的吞吐率，Redis Cluster單條讀寫的吞吐率略高于TwemPrxoy Redis單條吞吐率。

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

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

參考文獻

［1］王敏，陳亞光.數(shù)據(jù)庫系統(tǒng)輔助測試工具［J］.微型機與應(yīng)用，2013，32（3）：13-15，18.

［2］夏文忠，鄒雯奇.基于X86平臺的高性能數(shù)據(jù)庫集群技術(shù)的研究［J］.微型機與應(yīng)用，2015，34（1）：36-39，46.

［3］張蕾，侯瑞春，丁香乾，等.會話保持機制在集群系統(tǒng)中的應(yīng)用研究［J］.微型機與應(yīng)用，2015，34（9）：32-34，50.

柳皓亮（1991 -），男，碩士研究生，主要研究方向：分布式在線實時流式計算。

王麗（1992 -），女，碩士研究生，主要研究方向：分布式數(shù)據(jù)挖掘與存儲。

周陽辰（1992 -），男，碩士研究生，主要研究方向：集群監(jiān)控。

引用格式：柳皓亮，王麗，周陽辰.Redis集群性能測試分析［J］.微型機與應(yīng)用，2016，35（10）：70-71，78.

The analysis of the performance test of the Redis Cluster

Liu Haoliang， Wang Li， Zhou Yangchen
（Storage Computing Group，Suzhou Institute of Electronics，Chinese Academy of Sciences Research Institute，Suzhou 215123，China）

Abstrac t：Redis is a non-relational database，which belongs to the memory database.However，with the amount of data increasing quickly，the single Redis is unable tomeet the needs of the large data.So we need to build a distributed Redis，which can extend memory dynamicly and make up the faults that the single Redis doesn' t have enough physical memory.In order to have a good design for the Redis Cluster and p lay a Redis high throughput characteristics of Redis Cluster，we make the experiment about this.In this experiment，we build two clusters，which are Redis Cluster and TwemProxy Cluster.W e make experiment one by one to test out the clustering performance of inflection point，meanwhile，find out what are the performance bottlenecks.So we can make a good choice under different business scenarios.

Key w ords：Redis Cluster；TwemProxy Redis；performance test

作者簡介：

收稿日期：（2016-01-20）

中圖分類號：TP23

文獻標(biāo)識碼：A

DOI：10.19358 /j.issn.1674-7720.2016.09.024