Redis + Twemproxy（二）之测试

本章节主要对前面搭建好的 Redis + Twemproxy 进行测试。我们首先来看一下关于 Twemproxy 的介绍：

Twemproxy，又称 nutcraker，是 Twtter 开源的一个 Redis 和 Memcache 代理服务器，主要用于管理 Redis 和 Memcached 集群，减少与 Cache 服务器直接连接的数量。

Twemproxy 特性：

1、支持代理到多台服务器上，减少了与 Cache 服务器直接连接的数量，客户端可以连接到首个可用的代理服务器；
2、自动分片数据到多个服务器上；
3、支持请求的流式与批处理，因而能够降低来回的消耗；
4、通过端口监控状态，能够配置删除故障节点；
5、使用 pipelining 处理请求和响应；
6、支持多个哈希模式，包括一致性哈希和分布；
7、保持长连接；
8、通过 yaml 文件配置服务器池；
9、轻量级、快速；
10、支持 linux、*bsd、os x 和 solaris；
11、实现完整的 memcached 的 ASCII 和再分配协议

缺点：

1、不支持针对多个值的操作，比如取 sets 的子交并补等；
2、不支持 Redis 的事务操作；
3、错误消息、日志信息匮乏，排查问题困难。

下面针对 Twemproxy 特性进行测试。

1、查看端口

netstat -nltp | grep nutcracker

nutcracker 监听了 22121 与 22222 两个端口：
22121：是配置文件中所指定的、对外提供服务的端口；
22222：后台服务状态监控端口，默认每隔 30s 收集一次信息。

2、使用 nc 命令查看 Twemproxy 状态：

nc 192.168.255.128 22222 | python -mjson.tool

3、支持代理到多台服务器上，减少了与 Cache 服务器直接连接的数量，客户端可以连接到首个可用的代理服务器

通过 22121 端口进行写读操作：

直连后台 redis 服务器进行取值操作，判断前一步写入的值存在哪一个主备：

写入的数据被存入第二个主备，第一个主备取值失败。

4、自动分片数据到多个服务器上

编写 py 脚本，通过 Twemproxy 写入1万数据：

import redis

r=redis.Redis(host='192.168.255.128',password='www.wave.com',db=0,port=22121)

for _i in range(0, 10000):
	key_str = 'key_%d' % _i	
	r.set(key_str, _i)

直连 redis，查看两个主备上键值分布：

键值分布差异性不大，相对均衡。

注意：

需预先安装 python-redis，否则在 import redis 时，可能提示：No module named redis。
解决方案：https://packages.debian.org/stretch/python-redis

5、支持请求的流式与批处理，因而能够降低来回的消耗

Twemproxy 支持批处理，指的是当客户端发送的是批处理命令（如：mset、hset等）时，可能出现同一条命令的多个 key 分别被发送到多个后端 Redis 服务器的情况。

事先通过 Twemproxy 写入键值 key1、key2、area：

最终，键值 key1 与 key2 存储在 192.168.255.128 所在的主备，键值 area 存储在 192.168.177.128 所在的主备。

现在以命令：mget 为例，来测试 Twemproxy 批处理：

可以看到，Twemproxy 一次性返回来来自多个后端 Redis 的数据。

6、通过端口监控状态，能够配置删除故障节点

把 192.168.177.128:7004 对应的 redis kill 后，检查 Twemproxy 状态：

可以看到，Twemproxy 检测到对应的 Redis 出错。
但是，通过 Twemproxy 写入键值对 area:shenzhen 时，发现经常性出错。（按照之前的测试结论，正常情况下，键值 area 会被写入 192.168.177.128:7004 对应的主备）

这个错误与 server_retry_timeout 参数设置太小有关，默认值 30000msec 是一个很好的选择。

解决方法：

#每隔多少毫秒判断故障节点是否正常，若正常则放回一致性hash环
server_retry_timeout: 2000->30000

#连续多少次向同一个服务器发送命令请求都遇到错误时，就将该服务器标记为下线，并将命令交由池中其他在线服务器处理
server_failure_limit: 1->0

修改以上两个配置，将 server_retry_timeout 的间隔时间拉长，不然 Twemproxy 频繁重连，自然一直摘不掉机器；也可将 server_failure_limit 设置为 0，即一旦节点有错误立马摘掉。
更新配置后，重新测试：

直连 192.168.255.128:7000，发现键值被写入该主备，说明原先的 key 被 hash 到了新服务器上。

重新启动 192.168.177.128:7004，通过 Twemproxy 获取键值：area。

可见，在两台主备都存在该键值的情况下，Twemproxy 返回的是 192.168.177.128:7004 存储的数据，说明 key 被 hash 到了原先的服务器上。

7、使用 pipelining 处理请求和响应

pipelining 是 Twemproxy 高性能的原因之一，即 Twemproxy 可以同时接收多个 client 的请求，并仅通过一个或几个连接回源。这种结构很适合使用流水线处理请求和响应，从而节省 TCP 往返时间。

例如：
Twemproxy 正在同时代理3个 client 的请求，分别是：‘get key1’、‘set key2 server1’ 和 'delete key3 '，Twemproxy 可以将这3个请求打包成一个消息发送给后端的redis： ‘get key1\r\nset key2 server1\r\ndelete key3\r\n’。

8、性能测试

• set 命令

  • Twemproxy 测试结果：
    
  • 直连 Redis 测试结果：
    

  -c：指定并发连接数，默认50；
  -t：仅运行以逗号分隔的测试命令列表。若只需压测某个命令，如：get，那么可以在命令后增加该参数。

• get 命令

  • Twemproxy 测试结果：
    
  • 直连 Redis 测试结果：
    

• lpop 命令

  • Twemproxy 测试结果：
  • 直连 Redis 测试结果：

• sadd 命令

  • Twemproxy 测试结果：
  • 直连 Redis 测试结果：
    

• lpop 命令

  • Twemproxy 测试结果：
  • 直连 Redis 测试结果：
    
    由此可见，Twemproxy 性能与直连单台 redis 差不多。