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

?

Redis集群性能測(cè)試分析

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

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

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

1　存儲(chǔ)測(cè)試分析

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

1.1Redis C luster

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

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

（2）大量數(shù)據(jù)存儲(chǔ)分析

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

1.2Twem Proxy Red is

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

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

（2）大量數(shù)據(jù)存儲(chǔ)分析

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

2　使用Java代碼測(cè)試吞吐率

主要從3個(gè)方面進(jìn)行測(cè)試，當(dāng)value類型分別是String類型、list類型和map類型時(shí)，統(tǒng)計(jì)吞吐率的走勢(shì)，找出拐點(diǎn)，并分析原因［2］。

2.1Redis C luster

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

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

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

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

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

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

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

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

2.2Twem Proxy Redis

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

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

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

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

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

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

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

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

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

3　結(jié)論

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

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

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

參考文獻(xiàn)

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

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

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

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

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

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

引用格式：柳皓亮，王麗，周陽辰.Redis集群性能測(cè)試分析［J］.微型機(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

作者簡(jiǎn)介：

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

中圖分類號(hào)：TP23

文獻(xiàn)標(biāo)識(shí)碼：A

DOI：10.19358 /j.issn.1674-7720.2016.09.024