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

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:30

use 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.315s
user    0m0.457s
sys     0m1.473s


real    0m3.391s
user    0m0.458s
sys     0m1.512s


real    0m3.433s
user    0m0.459s
sys     0m1.455s


real    0m3.475s
user    0m0.449s
sys     0m1.465s


real    0m3.442s
user    0m0.472s
sys     0m1.465s


real    0m3.483s
user    0m0.471s
sys     0m1.421s


real    0m3.487s
user    0m0.467s
sys     0m1.459s


real    0m3.440s
user    0m0.480s
sys     0m1.425s


real    0m3.498s
user    0m0.452s
sys     0m1.428s


real    0m3.403s
user    0m0.445s
sys     0m1.411s


real    0m3.505s
user    0m0.479s
sys     0m1.416s


real    0m3.495s
user    0m0.461s
sys     0m1.483s


real    0m3.424s
user    0m0.465s
sys     0m1.422s


real    0m3.477s
user    0m0.496s
sys     0m1.403s


real    0m3.521s
user    0m0.454s
sys     0m1.474s


real    0m3.494s
user    0m0.491s
sys     0m1.399s


real    0m3.550s
user    0m0.446s
sys     0m1.435s


real    0m3.539s
user    0m0.445s
sys     0m1.442s


real    0m3.527s
user    0m0.501s
sys     0m1.447s


real    0m3.477s
user    0m0.468s
sys     0m1.442s


real    0m3.569s
user    0m0.449s
sys     0m1.405s


real    0m3.512s
user    0m0.462s
sys     0m1.428s


real    0m3.539s
user    0m0.472s
sys     0m1.388s


real    0m3.584s
user    0m0.483s
sys     0m1.396s


real    0m3.529s
user    0m0.468s
sys     0m1.396s


real    0m3.554s
user    0m0.459s
sys     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"，因此，该分布表现仍可以接受。