twemproxy for redis使用说明及简单分析

来源：互联网发布：getopt函数 python 编辑：程序博客网时间：2024/04/27 17:27

redis的数据量在内存高过50G时系统出现了明显的瓶颈。为了解决这个问题，笔者找了些相关的资料，发现了这个开源软件。功能很强大，包含了last.fm的ketama的一致性hash算法，对于笔者目前的需求，该软件已经能够完全满足。

软件的源代码已经在git上面开源：https://github.com/twitter/twemproxy

下载和安装的过程就不再赘述，在README中有详细的叙述。这里主要说一说如何配置一个自己的集群。

安装完成之后，修改配置文件。

alpha:                                                                                                                                         listen: 127.0.0.1:22121  hash: fnv1a_64  distribution: ketama  auto_eject_hosts: true  redis: true  server_retry_timeout: 2000  server_failure_limit: 1  servers:   - 127.0.0.1:8604:1   - 127.0.0.1:8605:1   - 127.0.0.1:8606:1   - 127.0.0.1:8607:1

按照配置文件中的端口启动两台redis服务器，权重均配置为1，不用配置数据库的index。

启动完成redis之后，启动代理服务。

$ nutcracker -d

此时，nutcracker就已经启动了，下面可以使用redis的客户端做简单的测试。

$ ./redis-cli -p 22121 set abc abc

$ ./redis-cli -p 22121 get abc

简单测试之后结果正常。

为了简单测试proxy的性能，使用脚本执行批量写入的操作：

#!/usr/bin/perl                                                                                                                              # Program:#     # History:# Author: luyao(yaolu1103@gmail.com)# Date:  2013/02/22 17:09:30use strict;my @port = (8604, 8605, 8606, 8607);my $pre = shift;for (my $i = 0; $i< 1000;$i++) {  my $num = rand;  `./redis-cli -p 22121 set $pre$i $i`;}

使用shell命令调用：

$for i in a b c d e f g h i j k l m n o p q r s t u v w x y z;do sh -c "time perl test.pl $i&";done

结果如下：

real    0m3.315suser    0m0.457ssys     0m1.473sreal    0m3.391suser    0m0.458ssys     0m1.512sreal    0m3.433suser    0m0.459ssys     0m1.455sreal    0m3.475suser    0m0.449ssys     0m1.465sreal    0m3.442suser    0m0.472ssys     0m1.465sreal    0m3.483suser    0m0.471ssys     0m1.421sreal    0m3.487suser    0m0.467ssys     0m1.459sreal    0m3.440suser    0m0.480ssys     0m1.425sreal    0m3.498suser    0m0.452ssys     0m1.428sreal    0m3.403suser    0m0.445ssys     0m1.411sreal    0m3.505suser    0m0.479ssys     0m1.416sreal    0m3.495suser    0m0.461ssys     0m1.483sreal    0m3.424suser    0m0.465ssys     0m1.422sreal    0m3.477suser    0m0.496ssys     0m1.403sreal    0m3.521suser    0m0.454ssys     0m1.474sreal    0m3.494suser    0m0.491ssys     0m1.399sreal    0m3.550suser    0m0.446ssys     0m1.435sreal    0m3.539suser    0m0.445ssys     0m1.442sreal    0m3.527suser    0m0.501ssys     0m1.447sreal    0m3.477suser    0m0.468ssys     0m1.442sreal    0m3.569suser    0m0.449ssys     0m1.405sreal    0m3.512suser    0m0.462ssys     0m1.428sreal    0m3.539suser    0m0.472ssys     0m1.388sreal    0m3.584suser    0m0.483ssys     0m1.396sreal    0m3.529suser    0m0.468ssys     0m1.396sreal    0m3.554suser    0m0.459ssys     0m1.398s

根据上述数据，proxy在3.5s内写入了1000*26条数据，7000+ QPS。考虑到所有的redis服务以及写入服务均在同一台机器上部署，因此，真实能力应该大于该值。

最后，查看一下key的分布情况：

8604：db0:keys=7760,expires=0

8605：db0:keys=6010,expires=0

8606：db0:keys=6545,expires=0

8607：db0:keys=5685,expires=0

key的分布基本ok，考虑到key都比较简单，而且可能相似"a-z+0-999"，因此，该分布表现仍可以接受。