柳皓亮,王丽,周阳辰
(中国科学院电子学研究所苏州研究院 存储计算组， 江苏 苏州 215123)
摘要：Redis是一个非关系型数据库，属于内存级数据库。但是由于数据量的不断增大，单机的Redis物理内存远远无法满足大数据的需要，因此需要搭建分布式的Redis，可以动态扩展内存，弥补单机Redis物理内存不够的缺点。本次测试旨在对Redis各方面性能有深入的了解，为今后的工作打好基础。本次实验的目的主要是搭建Redis Cluster和TwemProxy 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）相同。
（4）List插入测试——吞吐率随List大小变化情况：当List元素大小和吞吐量一定时，吞吐率随list的size增大而减小，size从10增加大100时吞吐率下降了一半。由此可见，Redis Cluster对List的支持效果并不好，性能有待提升，不建议在以后的项目阶段用Redis Cluster存储List。
（5）List插入测试——吞吐率随List元素字节大小变化情况： List的元素字节大小变化对吞吐率没有影响。
（6）List插入测试——吞吐率随吞吐量大小的变化关系：吞吐率与吞吐量无关。
（7）Map插入测试——吞吐率随Map size大小变化关系：当吞吐量和元素字节一定时，吞吐率随Map的size增大而减小。
（8）Map插入测试——吞吐率随Map的value大小变化情况：当吞吐量和Map的size一定时，吞吐率随Map元素字节增大而减小。
2.2TwemProxy Redis
TwemProxy Redis［2］采用单条读写和批量读写两种方式进行压力测试，测试结果如下。
（1）String单条插入测试——吞吐率随value大小变化情况：value值在1 KB以内且总请求量为1万时吞吐率基本保持不变；当value值大于1 KB时, 吞吐率随value增大而减小，单条TwemProxy Redis的插入吞吐率明显比Redis Cluster低。
（2）String批量插入测试——吞吐率随value大小变化情况：当吞吐量一定时，value值小于100 B时，吞吐率随value增大而增大；当value值大于100 B时，吞吐率随value增大而减小。由此可见，批量插入存在极值点，此外批量插入的吞吐率远远高于TwemProxy Redis和Redis Cluster的单条插入。
（3）String单条获取测试——吞吐率随value大小变化关系：测试结果与（1）的结果相同。由此可见，TwemProxy Redis的单条读写效率一致。
（4）String批量获取测试——吞吐率随value大小变化关系：结果与（2）相同。
（5）String单条插入测试——吞吐率随吞吐量的变化关系：吞吐率与吞吐量无关，TwemProxy Redis吞吐率只有Redis Cluster的一半，明显吞吐率很低。
（6）String批量插入测试——吞吐率随吞吐量的变化关系：随着吞吐量的增加，吞吐率也在增加。但在测试时将请求量给到10万条后，程序宕掉并且集群服务停止工作，说明pipeline批量打包的数据量有限，即性能是有限的。但是可以通过打包多次解决这个问题，批量插入的吞吐率明显高于TwemProxy Cluster和Redis Cluster的单条插入吞吐率。
（7）List和Map类型的单条插入测试吞吐率变化：吞吐率变化与Redis Cluster的相同，但是吞吐率低于Redis Cluster。
(8)List和Map类型的单条插入测试吞吐率变化：吞吐率变化与Redis Cluster的相同，但是吞吐率高于TwemProxy Cluster和Redis Cluster的单条吞吐率。
3结论
（1） TwemProxy Redis的批量读写吞吐率远远高于Redis Cluster单条的吞吐率，Redis Cluster单条读写的吞吐率略高于TwemPrxoy Redis单条吞吐率。
（2） Redis Cluster和TwemPrxoy Redis对List和Map集合的吞吐率很低，不建议存储这两种类型的数据。
（3）当需要进行TwemProxy Redis批量操作时，需要通过程序保证一次批量读写的数据量不宜过大，否则底层服务会宕掉。
参考文献
［1］ 王敏，陈亚光.数据库系统辅助测试工具［J］.微型机与应用，2013，32（3）：1315，18.
［2］ 夏文忠,邹雯奇.基于X86平台的高性能数据库集群技术的研究［J］.微型机与应用,2015,34(1):3639,46.
［3］ 张蕾,侯瑞春,丁香乾，等.会话保持机制在集群系统中的应用研究［J］.微型机与应用,2015,34(9):3234,50.