吃透Redis系列(九):Redis代理twemproxy和predixy详细介绍
文章目录一,实现Redis集群方案1,客户端分片2,代理分片2.1,twemproxy2.2,predixy3,服务端分片redis cluster4,方案选择二,twemproxy1,twemproxy使用1.1,clone代码1.2,生成configure文件1.3,执行./configure1.4,执行make1.5,拷贝nutcracker.init1.6,给twemproxy赋可执行权限
Redis系列文章:
吃透Redis系列(三):Redis管道,发布/订阅,事物,过期时间 详细介绍
吃透Redis系列(九):Redis代理twemproxy和predixy详细介绍
吃透Redis系列(十一):Jedis和Lettuce客户端详细介绍
一,实现Redis集群方案
Redis在3.0版本前只支持单实例模式,虽然Redis的开发者Antirez早在博客上就提出在Redis 3.0版本中加入集群的功能,但3.0版本等到2015年才发布正式版。各大企业等不急了,在3.0版本还没发布前为了解决Redis的存储瓶颈,纷纷推出了各自的Redis集群方案。这些方案的核心思想是把数据分片(sharding)存储在多个Redis实例中,每一片就是一个Redis实例。
为了实现集群的功能,从服务端、客户端分片的角度来看,可以分为以下三类:
- 客户端分片: 典型的是支持一致性哈希的客户端
- 代理层分片: 典型代表twemproxy、codis
- redis服务端分片: redis cluster
1,客户端分片
客户端分片是把分片的逻辑放在Redis客户端实现,(比如:jedis已支持Redis Sharding功能,即ShardedJedis),通过Redis客户端预先定义好的路由规则(使用一致性哈希),把对Key的访问转发到不同的Redis实例中,查询数据时把返回结果汇集。
客户端分片的优缺点:
优点:
客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的,不依赖于第三方分布式中间件。服务端的Redis实例彼此独立,相互无关联,每个Redis实例像单服务器一样运行,非常容易线性扩展,系统的灵活性很强。开发人员清楚怎么实现分片、路由的规则,不用担心踩坑。
缺点:
- 这是一种静态的分片方案,需要增加或者减少Redis实例的数量,需要手工调整分片的程序。
- 运维成本比较高,集群的数据出了任何问题都需要运维人员和开发人员一起合作,减缓了解决问题的速度,增加了跨部门沟通的成本。
- 在不同的客户端程序中,维护相同的路由分片逻辑成本巨大。比如:java项目、PHP项目里共用一套Redis集群,路由分片逻辑分别需要写两套一样的逻辑,以后维护也是两套。
客户端分片有一个最大的问题就是,服务端Redis实例群拓扑结构有变化时,每个客户端都需要更新调整。如果能把客户端分片模块单独拎出来,形成一个单独的模块(中间件),作为客户端 和 服务端连接的桥梁就能解决这个问题了,此时代理分片就出现了。
2,代理分片
代理基本原理是:通过中间件的形式,Redis客户端把请求发送到代理,代理根据路由规则发送到正确的Redis实例,最后代理把结果汇集返回给客户端。
2.1,twemproxy
在redis 3.0推出redis cluster
之前,代理层实现redis集群是首选方案,twemproxy
和codis
是最常见的两个代理。
然而twemproxy
不支持的redis功能太多,像列表的阻塞命令、事物、发布订阅等都不支持,而且也没有直接支持redis的高可用。
twemproxy github地址:https://github.com/twitter/twemproxy
2.2,predixy
基于上述原因,2017年推出了一款全新的redis代理:predixy
。
predixy
完美的实现了对redis单例模式及集群模式的支持,几乎完整的实现了redis原生的所有用于客户端的命令。多key命令、列表阻塞操作、发布订阅、脚本、扫描等高级功能全支持,在使用redis单例模式下也支持事物。
predixy github地址:https://github.com/joyieldInc/predixy
3,服务端分片redis cluster
Redis Cluster是一种服务器Sharding技术(分片和路由都是在服务端实现),采用多主多从,每一个分区都是由一个Redis主机和多个从机组成,片区和片区之间是相互平行的。Redis Cluster集群采用了P2P的模式,完全去中心化。
redis cluster原理上和codis差不多,同样是引入了slot的概念,不过redis cluster有16384个slot。redis cluster自身集成了高可用的功能,可扩展也是通过迁移slot来实现的。但是对客户端来说,redis cluster和单个redis实例相比它在请求响应上带来了MOVE/ASK语义,也就意味着之前的redis客户端无法直接获得全部集群功能,需要增加对MOVE/ASK响应的支持才可以访问整个集群。
为了让客户端透明的访问redis cluster,可以在中间加一层代理,predixy是一个不错的选择
4,方案选择
-
基于客户端的方案任何时候都要慎重考虑,在此我们不予推荐。
-
基于twemproxy的方案虽然看起来功能挺全面,但是实际使用中存在的问题同样很多,具体见上述,目前也不推荐再用twemproxy的方案。
-
redis cluster自redis 3.0推出以来,目前已经在很多生产环境上得到了应用,目前来讲,构建redis集群,推荐采用redis cluster搭配一款支持redis cluster的代理方案。
二,twemproxy
1,twemproxy使用
github地址:https://github.com/twitter/twemproxy
1.1,clone代码
git clone https://github.com/twitter/twemproxy.git
1.2,生成configure文件
autoreconf -fvi
1.3,执行./configure
./configure
1.4,执行make
make
执行完之后我们进src目录会发现生成一个nutcracker可执行程序
1.5,拷贝nutcracker.init
cd ..
cd /scripts
sudo cp nutcracker.init /etc/init.d/twemproxy
1.6,给twemproxy赋可执行权限
cd /etc/init.d
sudo chmod +x twemproxy
1.7,拷贝配置文件
mkdir /etc/nutcracker
去源码目录
cd /soft/twemproxy/conf
拷贝当前目录下所有文件到/etc/nutcracker
目录
sudo cp ./* /etc/nutcracker/
1.8,拷贝make生成的nutcracker可执行程序到/usr/bin目录下
cd /soft/twemproxy/src
sudo cp nutcracker /usr/bin/
然后我们就可以在操作系统的任何位置来使用nutcracker命令
1.9,修改配置文件
参照https://github.com/twitter/twemproxy的configuration
cd /etc/nutcracker/
sudo gedit nutcracker.yml
配置twemproxy端口为22121,监听6379,6380两个redis实例
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:6379:1
- 127.0.0.1:6380:1
1.10,启动6379,6380两个redis实例,启动twemproxy代理
#启动两个redis实例
redis-server --port 6379
redis-server --port 6380
redis-cli -p 6379
redis-cli -p 6380
#启动twemproxy代理
nutcracker -d -c /etc/nutcracker/nutcracker.yml
#连接twemproxy代理
redis-cli -p 22121
1.11,测试数据
在twemproxy
代理也就是22121端口,设置k1 bo
然后我们发现,可以在6380读取出来,而6379读取不到,证明代理把k1存储到6380实例上面了。
2,twemproxy缺点
twemproxy
不支持的redis功能太多,像列表的阻塞命令、事物、发布订阅等都不支持,而且也没有直接支持redis的高可用。
三,predixy
1,predixy安装
我们打开predixy github地址:https://github.com/joyieldInc/predixy
1.1,下载代码
你可以直接下载编译好的包,也可以下载代码自己make
直接下载包地址:https://github.com/joyieldInc/predixy/releases
或下载代码:
git clone https://github.com/joyieldInc/predixy.git
#下载完成后
cd /predixy
make
make完成后会在src目录下生成predixy可执行文件
1.2,把predixy可执行文件拷贝到/user/bin目录下,这样就可以全局使用了
cd /predixy/src
sudo sudo cp predixy /usr/bin/
1.3,把predixy/conf中的配置文件拷贝到/etc/predixy目录下
cd /etc
mkdir predixy
cd /soft/predixy/conf
sudo cp ./* /etc/predixy
1.4,给predixy目录下所有文件赋可执行权限
cd /etc
sudo chmod +x -R predixy
2,predixy+redis cluster模式
prefixy详细使用方式可以参考官网:https://github.com/joyieldInc/predixy/blob/master/doc/config_CN.md
2.1,配置文件
predixy的配置类似redis, 具体配置项的含义在配置文件里有详细解释,请参考下列配置文件:
- predixy.conf,整体配置文件,会引用下面的配置文件
- cluster.conf,用于Redis Cluster时,配置后端redis信息
- sentinel.conf,用于Redis Sentinel时,配置后端redis信息
- auth.conf,访问权限控制配置,可以定义多个验证密码,可每个密码指定读、写、管理权限,以及定义可访问的健空间
- dc.conf,多数据中心支持,可以定义读写分离规则,读流量权重分配
- latency.conf, 延迟监控规则定义,可以指定需要监控的命令以及延时时间间隔
提供这么多配置文件实际上是按功能分开了,所有配置都可以写到一个文件里,也可以写到多个文件里然后在主配置文件里引用进来。
2.2,配置predixy.conf
# 此代理绑定本机端口:7617
Bind 127.0.0.1:7617
# 包含集群配置文件
Include cluster.conf
注意:这里有一个点,配置文件中每一块只能开启一个配置,比如:
################################### SERVERS ####################################
Include cluster.conf
# Include sentinel.conf
#Include try.conf
在SERVERS中你如果开启了cluster,那么就必须把sentinel和try给注释掉!!!
2.3,配置cluster.conf
配置7000,7001,7002三个主节点,配置8000,8001,8002三个从节点。
ClusterServerPool {
MasterReadPriority 60
StaticSlaveReadPriority 50
DynamicSlaveReadPriority 50
RefreshInterval 1
ServerTimeout 1
ServerFailureLimit 10
ServerRetryTimeout 1
KeepAlive 120
Servers {
+ 127.0.0.1:7000
+ 127.0.0.1:7001
+ 127.0.0.1:7002
+ 127.0.0.1:8000
+ 127.0.0.1:8001
+ 127.0.0.1:8002
}
}
2.4,搭建cluster集群
1>,启动上述6个节点
redis-server /etc/redis/redis_7000.conf
redis-server /etc/redis/redis_7001.conf
redis-server /etc/redis/redis_7002.conf
redis-server /etc/redis/redis_8000.conf
redis-server /etc/redis/redis_8001.conf
redis-server /etc/redis/redis_8002.conf
2>,节点握手
把上述节点加入到同一个集群中,在7000节点中使用cluster meet命令,可以将所有节点加入到集群,完成节点握手:
cluster meet 127.0.0.1 7002
cluster meet 127.0.0.1 7003
cluster meet 127.0.0.1 8000
cluster meet 127.0.0.1 8001
cluster meet 127.0.0.1 8002
3>,分配槽
给三个主节点7001,7002,7003分配槽
redis-cli -p 7000 cluster addslots {0..5461}
redis-cli -p 7001 cluster addslots {5462..10922}
redis-cli -p 7002 cluster addslots {10923..16383}
4>,设置主从关系
至此,集群搭建成功!
2.5,启动predixy代理
predixy /etc/predixy/predixy.conf
出现如下打印则证明启动成功!
2.6,连接predixy客户端,设置set k1 bo
2.7,查询k1
可以看到,k1被分配到了7002主节点,那么7002的从节点8002应该也能查询到:
可以看到在从节点8002也可以查询到!
2.8,验证
- 验证发布/订阅
- 验证多key命令支持: mset/msetnx/mget/del/unlink/touch/exists
3,predixy优点
- 高性能并轻量级
- 支持多线程
- 多平台支持:Linux、OSX、BSD、Windows(Cygwin)
- 支持Redis Sentinel,可配置一组或者多组redis
- 支持Redis Cluster
- 支持redis阻塞型命令,包括blpop、brpop、brpoplpush
- 支持scan命令,无论是单个redis还是多个redis实例都支持
- 多key命令支持: mset/msetnx/mget/del/unlink/touch/exists
- 支持redis的多数据库,即可以使用select命令
- 支持事务,当前仅限于Redis Sentinel下单一redis组可用
- 支持脚本,包括命令:script load、eval、evalsha
- 支持发布订阅机制,也即Pub/Sub系列命令
- 多数据中心支持,读写分离支持
- 扩展的AUTH命令,强大的读、写、管理权限控制机制,健空间限制机制
- 日志可按级别采样输出,异步日志记录避免线程被io阻塞
- 日志文件可以按时间、大小自动切分
- 丰富的统计信息,包括CPU、内存、请求、响应等信息
- 延迟监控信息,可以看到整体延迟,分后端redis实例延迟
更多推荐
所有评论(0)