86565656 发表于 2018-11-5 11:27:49

redis高可用架构

  一、背景
  公司的业务在大量的使用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  至此,整个高可用方案已经搭建完成。
# redis-cli -h 100.10.32.54-p 6400 infoReplication  
# 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
# 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
# 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、看从库是否提升为主库
# 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上
# 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的监控状态
# redis-cli -p 26400 infoSentinel  
# 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


页: [1]
查看完整版本: redis高可用架构