Twemproxy + Sentinel Redis架构

http://blog.sina.com.cn/s/blog_66e0f3be0102uzxn.html

一、基本构件介绍

1、LVS:为Twemproxy提供load balance

2、Twemproxy：对应用提供透明的redis服务，并可以对数据进行sharding。

github：https://github.com/twitter/twemproxy

3、Sentinel：监控redis master的状态，当master失效的时候可以发出通知和完成自动故障转移。

4、twemproxy-sentinel-agent监控sentinal里面master信息，如果sentinal mater信息发生变化，那么修改Twemproxy 的servers配置参数，并重启Twemproxy。  

github：https://github.com/JasonLZJ/twemproxy-sentinel-agent-python-

twemproxy limitations：

http://wiki.corp.vipshop.com/display/iocc/Redis+Commands+Supported

二、基本架构与部署

三 配置概要

3.1 Twemproxy配置参数

Twem1: listen: 0.0.0.0:9999 hash: fnv1a_64 distribution: ketama auto_eject_hosts: true redis: true server_retry_timeout: 2000 server_failure_limit: 1 servers: - 10.201.54.193:6381:1 - 10.201.54.193:6382:1

 

问题：

auto_eject_hosts： A boolean value that controls if server should be ejected temporarily when it fails consecutively server_failure_limit times.

这个值的选择需要慎重，当为true的时候可能导致数据的不一致性问题。（测试过程中发现）

比如一个key在第一个个实例中（shard），当这个实例down掉之后，假设这个key再次写入（更新）会写入到第二个redis实例中（shard）。

 当第一个实例恢复之后，twemproxy会到第一个实例中读取这个key，而不是第二个redis实例，这样数据存在不一致性。或者读取了错误的数据。

 当redis作为DB使用的时候，不推荐使用auto_eject_hosts设置为true，数据的一致性和有效性得不到保证。

 

3.2 sentinel配置

daemonize yes port 26379 logfile "/apps/logs/redis/sentinel6379.log" sentinel monitor master16 192.168.44.17 6379 1 sentinel down-after-milliseconds master16 3000 sentinel failover-timeout master16 60000

 

sentinel monitor master16 192.168.44.17 6379 1

设置监听的master ip和端口。最后的1表示判断master失效至少需要几个sentinel同意

sentinel down-after-milliseconds master16 3000

sentinel认为redis实例SDOWN的需要的毫秒数，如果在给定的毫秒数内热第十没有任何响应，sentinel将这个服务器标记为主观下线（sbujectively down）。

sentinel failover-timeout master16 90000

 failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，当前sentinel将会认为此次failoer失败。  

 

3.3 twemproxy-sentinel-agent

global: agent_log: /apps/logs/twemproxy/agent.log delay_loop: 2 agents: twem1: sentinel_host: 10.201.54.193 sentinel_port: 26379 twem_config: /apps/conf/twemproxy/twemproxy.yml twem_cmd: /etc/init.d/twemproxy restart

四 Twemproxy性能测试

测试条件：redis 2.6.16 * 2个实例（6379和6380端口），twemproxy 端口为9999，1000M带宽，CPU E5-2620  2.00GHz，设置value 500字节,100个用户并发10000个请求

测试指令：redis-benchmark -h 127.0.0.1 -p 9999 -c 100 -n 10000 -d 500 -t -l

 real是指直接连接redis

twem是指连接twemproxy

twemproxy和redis都是单线程。 总结：一台 twemporxy 效率与直接连接redis-server 相比性能达到 80% 左右。 twemproxy不支持mset。

测试中发现twemproxy因为没有lvs的DR模式，首先会出现cpu满或网卡流程满，后面的redis负载还没上去，以及单点问题。

以上负载和单点问题，twemproxy可以在不通的机器启动多个twemproxy进程，前端在加入通过lvs的DR模式来做负载均衡。

维护上这样的多层架构有点蛋疼。

对比图：