Redis集群性能测试分析集群性能测试分析
Redis是一个非关系型数据库,属于内存级数据库。但是由于数据量的不断增大,单机的Redis物理内存远远无
法满足大数据的需要,因此需要搭建分布式的Redis,可以动态扩展内存,弥补单机Redis物理内存不够的缺
点。本次测试旨在对Redis各方面性能有深入的了解,为今后的工作打好基础。本次实验的目的主要是搭建
Redis Cluster和TwemProxy Redis两种集群,分别对其进行性能测试,测试出集群性能的拐点,找出性能的瓶
颈有哪些,并对两套集群进行比较,以便于在不同业务场景下择优选择。
柳皓亮,王丽,周阳辰
(中国科学院电子学研究所苏州研究院 存储计算组, 江苏 苏州 215123)
摘要 摘要:Redis是一个非关系型数据库,属于内存级数据库。但是由于数据量的不断增大,单机的Redis物理内存远远无法
满足大数据的需要,因此需要搭建分布式的Redis,可以动态扩展内存,弥补单机Redis物理内存不够的缺点。本次测试旨在
对Redis各方面性能有深入的了解,为今后的工作打好基础。本次实验的目的主要是搭建
关键词关键词:Redis Cluster;TwemProxy Redis;性能测试
1存储测试分析存储测试分析
本次存储测试是用Java程序调用Jedis提供的API向集群里面灌入数据。首先研究灌入少量数据后两种集群的数据分布在
哪些节点上,然后研究灌入大量数据后两种集群的落盘情况。
1.1Redis Cluster
(1)少量数据储存分析
用程序向某一个节点灌入30条数据,结果发现每个节点拥有部分数据,数据存储得很分散。由此可知,数据落盘时把一
份数据分成多份存储在不同的Redis节点上,进行分片存储,通过调研得知这种分配方式是通过sharding算法分配[1]的。
(2)大量数据存储分析
首先查看单节点未插入数据前的rdb大小为18 B;然后,用Java程序插入10万条数据,查看rdb大小为1 289 892 B,然后
改用Java程序向Redis Cluster集群中灌入10万条数据,查看每个节点rdb文件大小分别为214 912 B、216 586 B、215 939
B、214 145 B和213 757 B。由此可见,单机的rdb大小约等于每个Redis节点rdb大小之和,并且每个节点rdb大小相对均衡。
综上所述,这种落盘方式把一份数据平均分配到每一个节点上,也就是说每一个节点的rdb文件共同组成一份完整的数据。
1.2TwemProxy Redis
(1)少量数据存储分析
向集群中插入20条key为0~19的数据,查看数据在各个Redis节点分布情况,结果发现某个节点存储第0~9的数据,另一
个节点存储11~19的数据,最后一个节点没有存储数据。经过多次相同参数测试,每次落盘结果相同,由此可见
TwemProxy[2]根据相应算法将数据落盘到各个节点中,并且分配算法是对一段连续的数据进行落盘,而不是对每一条数据
进行选择存入到哪个节点中的操作,这样可以减少路由开销。
(2)大量数据存储分析
首先查看单机Redis节点未插入数据前的rdb文件大小为84 B; 然后插入10万条数据,查看rdb文件大小为1.6 MB;接着改
用Java程序向TwemProxy Redis[2]集群中灌入10万条数据,查看各各节点rdb文件大小分别为0.49 MB、0.62 MB和0.51
MB。由此可见,单机的rdb大小约等于每个Redis节点rdb大小之和,并且每个节点rdb大小相对均衡。由此可见,这种落盘方
式把一份数据平均分配到每一个节点上,也就是说每一个节点的rdb文件共同组成一份完整的数据。
2使用使用Java代码测试吞吐率代码测试吞吐率
主要从3个方面进行测试,当value类型分别是String类型、list类型和map类型时,统计吞吐率的走势,找出拐点,并分析
原因[2]。
2.1Redis Cluster
(1)String插入测试——吞吐率随value大小变化情况:当吞吐量一定时并且插入的是String类型数据时,如果value值在
1 KB以内时,吞吐率基本保持不变;如果 value值大于1 KB,吞吐率随value增大而减小。当value值达到10 KB且请求总量为
1万条时,共100 MB的数据,内存远远没有被打满,即此时内存的使用率仍比较低,所以此时Redis数据存储瓶颈[3]并不
是内存。同时监控了网卡和IO,发现均处于正常水平,所以也不是这两方面的原因。所以可以推出,此时吞吐率下降是由于
Redis本身不能够承受过大的value值。
(2)String插入测试——吞吐率随吞吐量变化情况:当value大小一定时,吞吐量的增大对吞吐率没有影响。
(3)String获取测试——吞吐率随value大小变化关系:结果与(2)相同。
评论0