redis高可用架构

86565656

　　一、背景
　　公司的业务在大量的使用redis，访问量大的业务我们有在使用codis集群，redis 3.0集群，说到redis 3.0集群，我们线上已经跑了半年多了，集群本身没有出现过任务问题，但是由于我们这个业务是海外的，集群建在aws的ec2上，由于ec2的网络抖动或者ec2本身的原因，导致主从切换，目前aws的技术正在跟进，这个集群目前的QPS 50w+，集群本身已经做到了高可用和横向扩展，但是，实际情况一些小的业务没必要上集群，单个实例就可以满足业务需求，那么我们就要想办法如何保证单个实例的高可用，最近也在看相关的文档，做一些测试，大家有在使用redis主从+lvs 漂VIP的方案，也有使用redis主从+哨兵 漂VIP的方案，甚至有在代码逻辑做故障切换等等，各种各样的方案都有，下面我介绍一下redis主从+哨兵 漂VIP的方案，后面我们打算线上大规模的使用这个方案。
　　二、环境
#redis　　
100.10.32.54:6400 主库
　　
100.10.32.55:6400 从库
　　
100.10.32.250 VIP
　　
#sentinel
　　
100.10.32.54:26400 sentinel 本地节点
　　
100.10.32.55:26400 sentinel 本地节点
　　
100.10.32.57:26400 sentinel 仲裁节点
　　三、部署
　　1、安装
yum -y install redis　　2、撰写redis配置文件（100.10.32.54 和100.10.32.55）
vim /etc/redis_6400.conf　　

　　
daemonize yes
　　
pidfile "/var/run/redis_6400.pid"
　　
port 6400
　　
tcp-backlog 65535
　　
bind 0.0.0.0
　　
timeout 0
　　
tcp-keepalive 0
　　
loglevel notice
　　
logfile "/var/log/redis/redis_6400.log"
　　
maxmemory 8gb
　　
maxmemory-policy allkeys-lru
　　
databases 16
　　
save 900 1
　　
save 300 10
　　
save 60 10000
　　
stop-writes-on-bgsave-error yes
　　
rdbcompression yes
　　
rdbchecksum yes
　　
dbfilename "dump.rdb"
　　
dir "/data/redis/6400"
　　
slave-serve-stale-data yes
　　
slave-read-only yes
　　
repl-disable-tcp-nodelay no
　　
slave-priority 100
　　
appendonly no
　　
appendfilename "appendonly.aof"
　　
appendfsync everysec
　　
no-appendfsync-on-rewrite no
　　
auto-aof-rewrite-percentage 100
　　
auto-aof-rewrite-min-size 64mb
　　
lua-time-limit 5000
　　
slowlog-log-slower-than 10000
　　
slowlog-max-len 128
　　
notify-keyspace-events ""
　　
hash-max-ziplist-entries 512
　　
hash-max-ziplist-value 64
　　
list-max-ziplist-entries 512
　　
list-max-ziplist-value 64
　　
set-max-intset-entries 512
　　
zset-max-ziplist-entries 128
　　3、撰写sentinel配置文件（100.10.32.54 、100.10.32.55 和100.10.32.57）
vim /etc/redis-sentinel6400.conf　　

　　
daemonize yes
　　
port 26400
　　
dir "/data/redis/redis_sentinels"
　　
pidfile "/var/run/redis/sentinel6400.pid"
　　
logfile "/data/redis/redis_sentinels/sentinel6400.log"
　　
sentinel monitor master6400 100.10.32.54 6400 2
　　
sentinel down-after-milliseconds master6400 6000
　　
sentinel failover-timeout master6400 18000
　　
sentinel client-reconfig-script master6400 /opt/notify_master6400.sh   ##仲裁节点无需添加这行配置，client-reconfig-script参数是在sentinel做failover的过程中调用脚本漂vip到新的master上
　　PS：
　　关于sentinel 的一些工作原理和参数说明，请参阅：http://redisdoc.com/topic/sentinel.html
　　4、撰写漂VIP的脚本（100.10.32.54 、100.10.32.55）
vim /opt/notify_master6400.sh　　

　　
#!/bin/bash
　　
MASTER_IP=$6
　　
LOCAL_IP='100.10.32.54' #从库修改为100.10.32.55
　　
VIP='100.10.32.250'
　　
NETMASK='24'
　　
INTERFACE='eth0'
　　
if [ ${MASTER_IP} = ${LOCAL_IP} ]; then
　　
         /sbin/ip addr add ${VIP}/${NETMASK} dev ${INTERFACE}
　　
         /sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
　　
        exit 0
　　
else
　　
         /sbin/ip addr del ${VIP}/${NETMASK} dev ${INTERFACE}
　　
        exit 0
　　
fi
　　
exit 1
chmod +x /opt/notify_master6400.sh   #赋予可执行权限　　PS：
　　这里大概说一下这个脚本的工作原理，sentinel在做failover的 过程中会传出6个参数，分别是、 、 、 、 、  、，其中第6个参数from-ip也就是新的master的ip，对应脚本中的MASTER_IP，下面的if判断大家应该都很了然了，如果MASTER_IP=LOCAL_IP，那就绑定VIP，反之删除VIP。
　　5、启动redis服务（100.10.32.54、100.10.32.55）
redis-server /etc/redis_6400.conf　　6、初始化主从（100.10.32.55）
redis-cli -p 6400 slaveof 10.10.32.54 6400　　7、绑定VIP到主库（100.10.32.54）
/sbin/ip addr add 100.10.32.250/24 dev eth0　　8、启动sentinel服务（100.10.32.54、100.10.32.55、100.10.32.57）
redis-server /etc/redis-sentinel6400.conf --sentinel　　至此，整个高可用方案已经搭建完成。
[root@localhost tmp]# redis-cli -h 100.10.32.54  -p 6400 info  Replication　　
# Replication
　　
role:master
　　
connected_slaves:1
　　
slave0:ip=100.10.32.55,port=6400,state=online,offset=72669,lag=1
　　
master_repl_offset:72669
　　
repl_backlog_active:1
　　
repl_backlog_size:1048576
　　
repl_backlog_first_byte_offset:2
　　
repl_backlog_histlen:72668
[root@localhost tmp]# redis-cli -h 100.10.32.54  -p 26400 info Sentinel　　
# Sentinel
　　
sentinel_masters:1
　　
sentinel_tilt:0
　　
sentinel_running_scripts:0
　　
sentinel_scripts_queue_length:0
　　
master0:name=master6400,status=ok,address=100.10.32.54:6400,slaves=1,sentinels=3
[root@localhost tmp]# ip a |grep eth0　　
2: eth0:  mtu 1500 qdisc mq state UP qlen 1000
　　
    inet 100.10.32.54/24 brd 100.10.32.255 scope global eth0
　　
    inet 100.10.32.250/24 scope global secondary eth0
　　四、测试
　　1、把主库停掉
redis-cli -h 100.10.32.54  -p 6400 shutdown　　2、看从库是否提升为主库
[root@localhost tmp]# redis-cli -h 100.10.32.55 -p 6400 info Replication　　
# Replication
　　
role:master
　　
connected_slaves:0
　　
master_repl_offset:0
　　
repl_backlog_active:0
　　
repl_backlog_size:1048576
　　
repl_backlog_first_byte_offset:0
　　
repl_backlog_histlen:0
　　3、看VIP是否漂移到100.10.32.55上
[root@localhost tmp]# ip a |grep eth0　　
2: eth0:  mtu 1500 qdisc mq state UP qlen 1000
　　
    inet 100.10.32.55/24 brd 100.10.32.255 scope global eth0
　　
    inet 100.10.32.250/24 scope global secondary eth0
　　4、看Sentinel的监控状态
[root@localhost tmp]# redis-cli -p 26400 info  Sentinel　　
# Sentinel
　　
sentinel_masters:1
　　
sentinel_tilt:0
　　
sentinel_running_scripts:0
　　
sentinel_scripts_queue_length:0
　　
master0:name=master6400,status=ok,address=100.10.32.55:6400,slaves=1,sentinels=3