欢迎光临 www.huangdc.com

twemproxy + redis + sentinel 实现redis集群高可用

技术杂谈 huangdc 9926℃ 0评论

本文主要描述使用 twemproxy + redis + sentinel + 脚本 实现redis集群的高可用,篇幅有点长(实战配置文件/命令)

先贴个本文主要标题列表哈

  • redis简介
  • sentinel 功能
  • twemproxy特性
  • twemproxy + redis + sentinel 实现redis集群高可用架构图
  • 实战一 :环境部署
  • 实战二 :redis 主从配置
  • 实战三 :sentinel 配置
  • 实战四 :twemproxy 配置

 

redis

Redis 是完全开源免费的,遵守BSD协议,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件,是一个高性能的key-value数据库。

前面有篇文档写到了redis简介及安装和压测数据:http://www.huangdc.com/246

 

redis sentinel 

redis sentinel 是redis 官方推荐的redis 高可用(HA)解决方案

sentinel 的功能:

  • 监控(Monitoring),sentinel 时刻监控着redis master-slave 是否正常运行
  • 通知(Notification),sentinel 可以通过api 来通知管理员,被监控的redis master-slave 出现了问题
  • 自动故障转移(Automatic failover),当redis master 出现故障不可用状态,sentinel 会开始一次故障转移,将其中一个 slave 提升为新的master ,将其他的slave 将重新配置使用新的master同步,并使用Redis的服务器应用程序在连接时收到使用新的地址连接
  • 配置提供者(Configuration provider) ,sentinel 作为在集群中的权威来源,客户端连接到sentinel来获取某个服务的当前Redis主服务器的地址和其他信息。当故障转移发生时,Sentinel 会报告新地址。

 

twemproxy (nutcraker)

Twemproxy,也叫nutcraker。是一个twtter开源的一个redis 和memcache 快速/轻量级代理服务器;Twemproxy是一个快速的单线程代理程序,支持Memcached ASCII协议和更新的Redis协议
Twemproxy 通过引入一个代理层,可以将其后端的多台 Redis 或 Memcached 实例进行统一管理与分配,使应用程序只需要在 Twemproxy 上进行操作,而不用关心后面具体有多少个真实的 Redis 或 Memcached 存储

twemproxy 的特性:

  • 支持失败节点自动删除
    – 可以设置重新连接该节点的时间
    – 可以设置连接多少次之后删除该节点
  • 支持设置HashTag
    – 通过HashTag可以自己设定将两个key哈希到同一个实例上去
  • 减少与redis的直接连接数
    – 保持与redis的长连接
    – 减少了客户端直接与服务器连接的连接数量
  • 自动分片到后端多个redis实例上
    – 多种hash算法:md5、crc16、crc32 、crc32a、fnv1_64、fnv1a_64、fnv1_32、fnv1a_32、hsieh、murmur、jenkins
    – 多种分片算法:ketama(一致性hash算法的一种实现)、modula、random
    – 可以设置后端实例的权重
  • 避免单点问题
    – 可以平行部署多个代理层,通过HAProxy做负载均衡,将redis的读写分散到多个twemproxy上。
  • 支持状态监控
    – 可设置状态监控ip和端口,访问ip和端口可以得到一个json格式的状态信息串
    – 可设置监控信息刷新间隔时间
  • 使用 pipelining 处理请求和响应
    – 连接复用,内存复用
    – 将多个连接请求,组成reids pipelining统一向redis请求
  • 并不是支持所有redis命令
    – 不支持redis的事务操作
    – 使用SIDFF, SDIFFSTORE, SINTER, SINTERSTORE, SMOVE, SUNION and SUNIONSTORE命令需要保证key都在同一个分片上。

 

twemproxy + redis + sentinel 高可用架构

 

redis20160309162514

  • 前端使用twemproxy (主备节点)做代理,将其后端的多台Redis实例分片进行统一管理与分配
  • 每一个分片节点的redis slave 都是redis master的副本且只读
  • redis sentinel 持续不断的监控每个分片节点的master,当master出现故障且不可用状态时,sentinel 会通知/启动自动故障转移等动作
  • sentinel 可以在发生故障转移动作后触发相应脚本(通过 client-reconfig-script 参数配置 ),脚本获取到最新的master来修改 twemproxy 配置并重启 twemproxy

 

实战一 :环境部署

实验环境:(简单化用三台主机)

ip 系统 部署软件 twemproxy服务 redis服务 sentinel服务
192.168.16.23 CentOS 6.7 redis
twemproxy
192.168.16.23:14500 _ 192.168.16.23:26379
192.168.16.22 CentOS 6.7 redis _ 192.168.16.22:4500
192.168.16.22:4501
192.168.16.22:26379
192.168.16.24 CentOS 6.7 redis _ 192.168.16.24:4500
192.168.16.24:4501
192.168.16.24:26379

实验架构图:

redis20160309180825

安装redis

分别在三台服务器都安装 redis  (192.168.16.22,192.168.16.23,192.168.16.24 )

安装twemproxy

在 192.168.16.23 服务器安装 twemproxy

安装twemproxy 前,需要安装autoconf,automake,libtool 软件包

1、编译安装autoconf

2、编译安装automake

3、编译安装libtool

4、编译安装twemproxy

注意:如果没有安装libtool 的话,autoreconf 的时候会报错,如下:

 

实战二 : redis 主从配置

1、创建目录环境

 

192.168.12.22:4500 -> 192.168.12.24:4500 (主->从)

192.168.12.22:4501 -> 192.168.12.24:4501 (主->从)

2、在 192.168.12.22 配置 192.168.12.22:4500  redis master

在192.168.12.22 配置master文件 /data/nosql/redis_4500/redis.conf  ,文件内容如下:

启动master 4500 端口:

 

3、在 192.168.12.24 配置 192.168.12.24:4500  redis slave

在 192.168.12.24 配置slave文件 /data/nosql/redis_4500/redis.conf

redis slave 从实例需要多加一个配置参数:  slaveof 192.168.16.22 4500  , 指明master 的ip 和端口

文件内容如下:

启动 slave 实例服务

4、192.168.12.22:4501 -> 192.168.12.24:4501  的 master->slave 同理第2、3步骤

5、检查两个主从实例信息:

6、检查两个主从实例同步:

检查 192.168.12.22:4500 -> 192.168.12.24:4500 (主->从)同步

检查 192.168.12.22:4501 -> 192.168.12.24:4501 (主->从)同步

ok , 两个主从同步没有问题

实战三 : sentinel 配置

在三台服务器配置 sentinel ,sentinel 默认监听端口是 26379

1、三台服务器的sentinel 配置文件 /data/nosql/sentinel/sentinel.conf ,内容如下:

上面的配置项配置了两个名字分别为redis_14555_g1_4500 和redis_14555_g2_4501 的master,配置文件只需要配置master的信息就好啦,不用配置slave的信息,因为slave能够被自动检测到(master节点会有关于slave的消息)。需要注意的是,配置文件在sentinel运行期间是会被动态修改的,例如当发生主备切换时候,配置文件中的master会被修改为另外一个slave。这样,之后sentinel如果重启时,就可以根据这个配置来恢复其之前所监控的redis集群的状态。

大家在这里记一下我给两个master的命名为 redis_14555_g1_4500 和 redis_14555_g2_4501  ,是有目的的,为了sentinel 后面触发修改twemproxy 的配置文件和重启有关系

sentinel 的配置信息也可以通过动态配置 ,如 SENTINEL SET command动态修改

2、在三台服务器分别启动 sentinel 服务

3、测试sentinel 自动故障转移(kill掉一个master ,sentinel 会将slave 提升为master)

在前面redis 配置主从时候,我们已经检查过了 主从的信息

4、查看一台sentinel 的日志信息

大家可以自行查看一下相关说明

 

实战四 : twemproxy 配置

因为sentinel 确保了 redis 主从故障转移,当master 出现故障后,将slave提升为master 继续为客户端提供缓存服务;但是新的master ip 和端口信息已经发生了改变,所以客户端需要重新配置文件或者改造程序才能重新连接新的master ,这样有点不方便 。为了方便客户端无需改造及redis 达到高可用状态(故障恢复时间保持在1分钟内),我们采用 twemproxy 做redis 前端代理,分片存储数据,结合sentinel故障转移时的通知/触发脚本功能,做一个自动故障转移且高可用的redis 集群。也就是本文最开始的架构图 twemproxy + redis + sentinel + 脚本 实现redis高可用架构(高可用集群)

redis 主从 和 sentinel 基本都已经配置好了,我们现在来配置一下 twemproxy

1、在 192.168.16.23 服务器上配置twemproxy ,配置文件为 /usr/local/twemproxy/conf/redis_14555.yml

内容为:

上面配置了两个redis master 的分片 192.168.16.22:4500 和 192.168.16.22:4501 。

这里的参数我们先不讲,我们看看配置的文件名是 redis_14555.yml ,大家有没有想起来,跟sentinel monitor 监控的 master-group-name 有关系,对了取的就是master-group-name 的前半段(redis_14555_g1_4500); 大家再记住一下,后面还会用到

2、启动twemproxy

启动相关参数信息说明:

3、测试 twemproxy set/get ,后端分片查看

我们现在将 192.168.16.22:4501 master  直接kill 掉 ,并查看 192.168.16.22:4501 的从服务192.168.16.24:4501是否被提示为 master

好了,我们再次通过 twemproxy 获取 刚刚设置的两个key “huang” 和 “huangggggggggggggggggggggggggg”

为了让redis 达到高可用状态,我们还需要在 sentinel 发送故障转移的时候,将新的master ip和端口告知twemproxy ,并修改twemproxy的配置文件和重启nutcracker服务,下一步见分晓

4、sentinel 配置 client-reconfig-script 脚本

增加脚本 /data/nosql/sentinel/client-reconfig.sh ; 并添加执行权限 chmod +x /data/nosql/sentinel/client-reconfig.sh ; 脚本内容如下:

动态修改192.168.16.23:26379 sentinel 的配置,添加 client-reconfig-script 项

5、再次测试 twemproxy

我们确认一下 twemproxy的配置文件的 servers 信息:(/usr/local/twemproxy/conf/redis_14555.yml)

好了,在192.168.16.22服务器上,我们把 192.168.16.22:4501 master 干掉,直接kill 掉

通过twemproxy 代理192.168.16.23:14555 获取key “huang” 和 “huangggggggggggggggggggggggggg”的值

再次查看twemproxy 的配置文件的 servers 信息:(/usr/local/twemproxy/conf/redis_14555.yml)

看到没有,看到没有,看到没有,192.168.16.22:4501 已经被替换为 192.168.16.24:4501 了。

twemproxy + redis + sentinel + 脚本 实现redis高可用架构(高可用集群)

twemproxy 有个缺点:如果 Twemproxy 的后端节点数量发生变化,Twemproxy 相同算法的的情况下,原来的数据必须重新处理分布,否则会存在找不到key值的情况

 

 

转载请注明:Huangdc » twemproxy + redis + sentinel 实现redis集群高可用

喜欢 (25)or分享 (0)
发表我的评论
取消评论

表情
(6)个小伙伴在吐槽
  1. 前端加上keepalived 就更加完美了[给力]
    仔锅2016-03-10 21:23 回复
  2. 不错,
    专业坏蛋2016-03-13 22:45 回复
  3. 这样 twemproxy 配置文件是否需要物理分隔
    shuoshadow2016-03-13 22:47 回复
  4. 文章篇幅好长
    死亡之影2016-03-15 14:34 回复
  5. 很有用,谢谢
    观望2016-05-28 13:34 回复