[关闭]
@phper 2015-12-28T09:00:41.000000Z 字数 6112 阅读 3617

Twemproxy Redis 集群的研究和使用

redis


twitter的Twemproxy (https://github.com/twitter/twemproxy)是目前市面上用的最广的使用做多的用来做redis集群服务。由于redis 是单线程,而且官方的cluster 还不是很稳定和广泛使用。

0. twemproxy的特点

  1. 对外暴露一个访问节点
  2. 请求分片(sharding)
  3. 分片要合理(分片均匀,相同的请求要分配到同样的redis节点)

1. 下载和安装twemproxy

  1. git clone https://github.com/twitter/twemproxy.git

提示autoreconf 的版本过低

  1. [root@web3 twemproxy]# autoreconf
  2. configure.ac:8: error: Autoconf version 2.64 or higher is required
  3. configure.ac:8: the top level
  4. autom4te: /usr/bin/m4 failed with exit status: 63
  5. aclocal: autom4te failed with exit status: 63
  6. autoreconf: aclocal failed with exit status: 63

下载 2.69版本的autoconf

  1. [root@web3] wget http://ftp.gnu.org/gnu/autoconf/autoconf-2.69.tar.gz
  2. [root@web3] tar zxvf autoconf-2.69.tar.gz
  3. cd autoconf
  4. [root@web3 autoconf-2.69]# ./configure --prefix=/usr
  5. [root@web3 autoconf-2.69]# make
  6. [root@web3 autoconf-2.69]# make install

继续安装 twemproxy

  1. cd twemproxy/
  2. [root@web3 twemproxy] CFLAGS="-ggdb3 -O0" autoreconf -fvi && ./configure --prefix=/usr/local/twemproxy --enable-debug=log
  3. [root@web3 twemproxy] make
  4. [root@web3 twemproxy] make install

2. 添加配置文件

添加配置文件,加入我们测试用的3台机器

  1. [root@web3 conf]# cd /usr/local/twemproxy/
  2. [root@web3 twemproxy]# mkdir conf run
  3. [root@web3 twemproxy]# cd conf
  4. [root@web3 conf]# vi nutcracker.yml
  5. beta:
  6. listen: 0.0.0.0:22122
  7. hash: fnv1a_64
  8. hash_tag: "{}"
  9. distribution: ketama
  10. auto_eject_hosts: false
  11. timeout: 400
  12. redis: true
  13. servers:
  14. - 192.168.33.11:6370:1 master0
  15. - 192.168.33.11:6380:1 master1
  16. - 192.168.33.11:6381:1 master2

3. 启动twemproxy (nutcracker)

刚已经加好了配置文件,现在测试下:

  1. [root@web3 twemproxy]# ./sbin/nutcracker -t
  2. nutcracker: configuration file 'conf/nutcracker.yml' syntax is ok

说明配置文件已经成功,好。现在开始运行:

  1. [root@web3 twemproxy]# ./sbin/nutcracker -d -c /usr/local/twemproxy/conf/nutcracker.yml -p /usr/local/twemproxy/run/redisproxy.pid -o /usr/local/twemproxy/run/redisproxy.log

上面分别设置了配置文件制定路径,pid路径,日志路径等。

看看启动成功了没?

  1. [root@web3 twemproxy]# ps -ef|grep nutcracker
  2. root 13816 1 0 09:17 ? 00:00:00 ./sbin/nutcracker -d -c /usr/local/twemproxy/conf/nutcracker.yml -p /usr/local/twemproxy/run/redisproxy.pid -o /usr/local/twemproxy/run/redisproxy.log

说明成功了。

可以查看帮助,查看nutcracker的使用规则:

  1. [root@web3 twemproxy]# ./sbin/nutcracker --help
  2. This is nutcracker-0.4.1
  3. Usage: nutcracker [-?hVdDt] [-v verbosity level] [-o output file]
  4. [-c conf file] [-s stats port] [-a stats addr]
  5. [-i stats interval] [-p pid file] [-m mbuf size]
  6. Options:
  7. -h, help : 查看帮助文档,显示命令选项
  8. -V, version : 查看nutcracker版本
  9. -t, test-conf : 测试配置脚本的正确性
  10. -d, daemonize : 以守护进程运行
  11. -D, describe-stats : 打印状态描述
  12. -v, verbosity=N : 设置日志级别 (default: 5, min: 0, max: 11)
  13. -o, output=S : 设置日志输出路径,默认为标准错误输出 (default: stderr)
  14. -c, conf-file=S : 指定配置文件路径 (default: conf/nutcracker.yml)
  15. -s, stats-port=N : 设置状态监控端口,默认22222 (default: 22222)
  16. -a, stats-addr=S : 设置状态监控IP,默认0.0.0.0 (default: 0.0.0.0)
  17. -i, stats-interval=N : 设置状态聚合间隔 (default: 30000 msec)
  18. -p, pid-file=S : 指定进程pid文件路径,默认关闭 (default: off)
  19. -m, mbuf-size=N : 设置mbuf块大小,以bytes单位 (default: 16384 bytes)

3. 连接twemproxy

和连接redis 一摸一样,只是端口换成了22122:

  1. [root@qwb3 twemproxy]# redis-cli -p 22122
  2. 127.0.0.1:22122> set name2 yangyi
  3. OK
  4. 127.0.0.1:22122> get name2
  5. "yangyi"

表示成功了,可以进行读取。那么以后的php 代码中就可以直接连接22122端口使用redis了。

4. 性能测试

用redis自带的redis-benchmark进行性能测试:

set 测试:

twemproxy:

  1. [root@web3 twemproxy]# redis-benchmark -h 192.168.33.13 -p 22122 -c 100 -t set -d 100
  2. ====== SET ======
  3. 100000 requests completed in 3.82 seconds
  4. 100 parallel clients
  5. 100 bytes payload
  6. keep alive: 1
  7. 0.00% <= 1 milliseconds
  8. 0.13% <= 2 milliseconds
  9. 4.16% <= 3 milliseconds
  10. 77.03% <= 4 milliseconds
  11. 96.81% <= 5 milliseconds
  12. 98.40% <= 6 milliseconds
  13. 99.17% <= 7 milliseconds
  14. 99.46% <= 8 milliseconds
  15. 99.58% <= 9 milliseconds
  16. 99.64% <= 10 milliseconds
  17. 99.64% <= 11 milliseconds
  18. 99.78% <= 12 milliseconds
  19. 99.93% <= 13 milliseconds
  20. 99.96% <= 14 milliseconds
  21. 99.97% <= 15 milliseconds
  22. 100.00% <= 15 milliseconds
  23. 26532.24 requests per second

原生redis:

  1. [root@web3 twemproxy]# redis-benchmark -h 192.168.33.11 -p 6380 -c 100 -t set -d 100
  2. ====== SET ======
  3. 100000 requests completed in 4.53 seconds
  4. 100 parallel clients
  5. 100 bytes payload
  6. keep alive: 1
  7. 0.07% <= 1 milliseconds
  8. 22.66% <= 2 milliseconds
  9. 51.71% <= 3 milliseconds
  10. 60.04% <= 4 milliseconds
  11. 69.81% <= 5 milliseconds
  12. 77.51% <= 6 milliseconds
  13. 82.74% <= 7 milliseconds
  14. 86.95% <= 8 milliseconds
  15. 91.00% <= 9 milliseconds
  16. 93.94% <= 10 milliseconds
  17. 95.83% <= 11 milliseconds
  18. 98.03% <= 12 milliseconds
  19. 98.99% <= 13 milliseconds
  20. 99.36% <= 14 milliseconds
  21. 99.64% <= 15 milliseconds
  22. 99.75% <= 16 milliseconds
  23. 99.79% <= 17 milliseconds
  24. 99.87% <= 18 milliseconds
  25. 99.90% <= 19 milliseconds
  26. 99.91% <= 20 milliseconds
  27. 99.94% <= 22 milliseconds
  28. 99.95% <= 23 milliseconds
  29. 99.98% <= 24 milliseconds
  30. 99.98% <= 25 milliseconds
  31. 99.99% <= 26 milliseconds
  32. 100.00% <= 27 milliseconds
  33. 100.00% <= 27 milliseconds
  34. 22060.45 requests per second

呃,咋一看,为啥,感觉twemproxy比原生的redis屌太多。我看其他的 测试,不是说,少20%的性能嘛,这尼玛活脱脱高了20%啊。

再测测get

twemproxy:

  1. [root@web3 twemproxy]# redis-benchmark -h 192.168.33.13 -p 22122 -c 100 -t get -d 100
  2. ====== GET ======
  3. 100000 requests completed in 3.57 seconds
  4. 100 parallel clients
  5. 100 bytes payload
  6. keep alive: 1
  7. 0.00% <= 1 milliseconds
  8. 0.03% <= 2 milliseconds
  9. 8.20% <= 3 milliseconds
  10. 87.29% <= 4 milliseconds
  11. 98.06% <= 5 milliseconds
  12. 99.23% <= 6 milliseconds
  13. 99.54% <= 7 milliseconds
  14. 99.70% <= 8 milliseconds
  15. 99.72% <= 9 milliseconds
  16. 99.75% <= 10 milliseconds
  17. 99.80% <= 11 milliseconds
  18. 99.90% <= 12 milliseconds
  19. 99.98% <= 13 milliseconds
  20. 99.99% <= 14 milliseconds
  21. 100.00% <= 14 milliseconds
  22. 27995.52 requests per second

原生redis:

  1. [root@web3 twemproxy]# redis-benchmark -h 192.168.33.11 -p 6380 -c 100 -t get -d 100
  2. ====== GET ======
  3. 100000 requests completed in 4.91 seconds
  4. 100 parallel clients
  5. 100 bytes payload
  6. keep alive: 1
  7. 0.18% <= 1 milliseconds
  8. 22.35% <= 2 milliseconds
  9. 43.39% <= 3 milliseconds
  10. 53.87% <= 4 milliseconds
  11. 63.11% <= 5 milliseconds
  12. 72.07% <= 6 milliseconds
  13. 79.50% <= 7 milliseconds
  14. 85.14% <= 8 milliseconds
  15. 90.04% <= 9 milliseconds
  16. 93.09% <= 10 milliseconds
  17. 96.05% <= 11 milliseconds
  18. 98.24% <= 12 milliseconds
  19. 99.03% <= 13 milliseconds
  20. 99.45% <= 14 milliseconds
  21. 99.75% <= 15 milliseconds
  22. 99.81% <= 16 milliseconds
  23. 99.97% <= 17 milliseconds
  24. 100.00% <= 17 milliseconds
  25. 20387.36 requests per second

我擦,是我哪里配置不对嘛?get 也是 tw更屌一点~

😭

5. twemproxy的优缺点

优点

这是一个轻量级的Redis和memcached代理。使用它可以减少缓存服务器的连接数,并且利用它来作分片。这个代理的速度是相当快的,在网上查到会有20%的性能损耗,但上面的redis-benchmark做了测试,发现性能更快。后来找到英文原文,作者是说最差情况下,性能损耗不会多于20%。twemproxy用了pipeline. 首先redis是支持使用pipeline批处理的。twemproxy与每个redis服务器都会建立一个连接,每个连接实现了两个FIFO的队列,通 过这两个队列实现对redis的pipeline访问。将多个客户端的访问合并到一个连接,这样既减少了redis服务器的连接数,又提高了访问性能。

缺点

  • 虽然可以动态移除节点,但该移除节点的数据就丢失了。
    redis集群动态增加节点的时候,twemproxy不会对已有数据做重分布.maillist里面作者说这个需要自己写个脚本实现
  • 性能上的损耗

6. 配置文件解析

上面我们新建来一个简单的配置文件nutcracker.yml:

  1. beta:
  2. listen: 0.0.0.0:22122
  3. hash: fnv1a_64
  4. hash_tag: "{}"
  5. distribution: ketama
  6. auto_eject_hosts: false
  7. timeout: 400
  8. redis: true
  9. servers:
  10. - 192.168.33.11:6370:1 master0
  11. - 192.168.33.11:6380:1 master1
  12. - 192.168.33.11:6381:1 master2

我们来一一看下,这些参数的意思以及使用用法。

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注