最近利用twitter的开源twemproxy做redis的代理,实现redis集群的功能。twemproxy利用一致性hash算法将key进行hash,使众多的key叫均匀的分布在后端各个redis中。值得注意的是这种hash粒度是key级别的,同一个key只会放在一个redis实例里,不同的key可能分布在不同的redis实例。
一、简介
引用
Twitter,世界最大的Redis集群之一部署在Twitter用于为用户提供时间轴数据。Twitter Open Source部门提供了Twemproxy。
Twemproxy,也叫nutcraker。是一个twtter开源的一个redis和memcache代理服务器。 redis作为一个高效的缓存服务器,非常具有应用价值。但是当使用比较多的时候,就希望可以通过某种方式 统一进行管理。避免每个应用每个客户端管理连接的松散性。同时在一定程度上变得可以控制。
Twemproxy是一个快速的单线程代理程序,支持Memcached ASCII协议和更新的Redis协议:
它全部用C写成,使用Apache 2.0 License授权。项目在Linux上可以工作,而在OSX上无法编译,因为它依赖了epoll API.
Twemproxy 通过引入一个代理层,可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配,使应用程序只需要在 Twemproxy 上进行操作,而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储。
二、twemproxy特性:
引用
支持失败节点自动删除
可以设置重新连接该节点的时间
可以设置连接多少次之后删除该节点
该方式适合作为cache存储
支持设置HashTag
通过HashTag可以自己设定将两个KEYhash到同一个实例上去。
减少与redis的直接连接数
保持与redis的长连接
可设置代理与后台每个redis连接的数目
自动分片到后端多个redis实例上
多种hash算法:能够使用不同的策略和散列函数支持一致性hash。
可以设置后端实例的权重
避免单点问题
可以平行部署多个代理层.client自动选择可用的一个
支持redis pipelining request
支持请求的流式与批处理,降低来回的消耗
支持状态监控
可设置状态监控ip和端口,访问ip和端口可以得到一个json格式的状态信息串
可设置监控信息刷新间隔时间
高吞吐量
连接复用,内存复用。
将多个连接请求,组成reids pipelining统一向redis请求。
三、安装
安装前提条件是必须有libtool,没有的可以自行安装,很简单。另外必须有autoconf,而且版本稍高点更好,有时需要升级才能用,我的就是这种情况。有这两个条件之后就可以动手了。
1.从git上将最新的code clone下来。
Java代码 收藏代码
$ git clone https://github.com/twitter/twemproxy.git
2.开始编译,安装
$ cd twemproxy/
$ CFLAGS="-ggdb3 -O0" autoreconf -fvi && ./configure --enable-debug=log && make && sudo make install
3.上一步的,可能会有一些依赖包要先安装,安装后再执行下编译安装即可。 安装完了之后修改配置文件,配置文件目录软件目录/conf/nutcracker.yml.我本次安装采用两个twemproxy实例、3个redis实例,配置内容如下:
redis1:
listen: 192.168.30.106:6311 #使用哪个端口启动Twemproxy
redis: true #是否是Redis的proxy
hash: fnv1a_64 #指定具体的hash函数
distribution: ketama #具体的hash算法
auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点
timeout: 4000 #超时时间(毫秒)
server_retry_timeout: 2000 #重试的时间(毫秒)
server_failure_limit: 1 #结点故障多少次就算摘除掉
servers: #下面表示所有的Redis节点(IP:端口号:权重)
- 127.0.0.1:6379:1
- 127.0.0.1:6389:1
- 127.0.0.1:6369:1
redis2:
listen: 192.168.30.106:6321 #使用哪个端口启动Twemproxy
redis: true #是否是Redis的proxy
hash: fnv1a_64 #指定具体的hash函数
distribution: ketama #具体的hash算法
auto_eject_hosts: true #是否在结点无法响应的时候临时摘除结点
timeout: 4000 #超时时间(毫秒)
server_retry_timeout: 2000 #重试的时间(毫秒)
server_failure_limit: 1 #结点故障多少次就算摘除掉
servers: #下面表示所有的Redis节点(IP:端口号:权重)
- 127.0.0.1:6379:1
- 127.0.0.1:6389:1
- 127.0.0.1:6369:1
4.开启twemproxy
虽然,安装编译会在/usr/bin里有nutcracker的快捷,但是切记不能这样开启。需要:
$ cd twemproxy/
$ /src/nutcracker -t ##先测试下配置文件是否正确
配置文件是conf/nutcracker.yml ,如果 -t 测试通过,则可以进行启动,配置好自己的环境。
$ /src/nutcracker
四、性能测试
利用redis的benchmark工具对采用代理方式和单台redis分别进行压力测试,可以比较出其性能。总的来说用twemproxy后性能有所下降,我的30%左右,其他有人测出20%,甚至有人测出无损性能。
直接测redis(红色部分尅换成其他命令如get,lpush,lpop等)
/usr/coolpad/redis6369/src/redis-benchmark -p 6379 -h 192.168.30.106 -c 100 -t [color=red]set [/color]-d 100 -l -q
测twemproxy
/usr/coolpad/redis6369/src/redis-benchmark -p 6311 -h 192.168.30.106 -c 100 -t [color=red]set[/color] -d 100 -l -q
分享到:
相关推荐
k8s集群搭建redis集群 k8s集群搭建redis集群 k8s集群搭建redis集群 k8s集群搭建redis集群 k8s集群搭建redis集群
1.先运行 createFile.py 输入宿主机IP地址,输入redis密码 2.按照控制台输出执行docker-compose up -d 启动命令 3.启动成功后执行加入集群命令即可
5分钟实现用docker搭建Redis集群模式和哨兵模式(csdn)————程序
windows搭建redis集群,里面包含有自己封装的redis集群文件,只需按照压缩包文档的介绍进行操作即可。
Rancher搭建redis集群配置Rancher搭建Rancher搭建redis集群配置Rancher搭建Rancher搭建redis集群配置Rancher搭建Rancher搭建redis集群配置Rancher搭建
keepalive+twemproxy+ redis主从安装配置的安装文档,里头包括了6篇
Windows环境下Redis集群的搭建,非常详细的介绍了搭建的步骤、每一步的命令等。 包括Ruby环境的搭建,还有客户端如何连接集群。
使用docker搭建redis集群,
阿里云公网redis集群搭建以及访问,本人亲测,可以成功搭建,java访问公网redis集群,
windows下搭建redis集群工具,具体的步骤可以看博客http://blog.csdn.net/wang_shuyu/article/details/78356843
采用spring-data-redis 搭建redis集群,代码包含redis工具类,可存储对象集合,maven项目,部署可运行。
包含redis的安装包,以及redis的安装步骤,redis集群的搭建
在我们日常开发工作中,经常会用到redis技术,而我们一般都是使用单机版,但是现在云上环境大多使用集群模式,在开发过程中,如果本地不能连内网或云上redis,就不能很好的开发,本资源为win10本地搭建redis集群的全...
redis集群自动搭建脚本,按照脚本中说明,简单修改ip 端口等参数 便可执行脚本自动搭建redis集群,适用centos7.X版本
CentOS系统搭建Redis集群(1主2从3哨兵)
搭建redis集群,使用ruby脚本搭建集群。 redis-3.0.0.gem
Windows Redis 集群搭建: 1、Redis 3.2.100。 2、redis-trib.rb。 3、rubygems-2.6.11.zip。 4、rubyinstaller-2.2.6.exe。
docker 搭建redis 集群
centos系统搭建Redis集群安装包
本次实验的目的主要是搭建Redis Cluster和TwemProxy Redis两种集群,分别对其进行性能测试,测试出集群性能的拐点,找出性能的瓶颈有哪些,并对两套集群进行比较,以便于在不同业务场景下择优选择。