Redis高可用架构(1)—

Redis高可用架构(1)—Keepalive+VIP

发表于2015年3月6日由sylar 3,931 views

最近整理一下Redis高可用架构的文档，也准备分享出来，虽然这些架构也不是很复杂。
Redis的高可用方案目前主要尝试过5种方式，其中2种方式已经在线上使用。

1）Redis Master-Slave + Keepalive + VIP。
这是很经典的db架构，也可以用与mysql的主从切换。
基本原理是：Keepalive通过脚本检测master的存活，然后通过漂移VIP（Virtual IP）完成主从切换。

2）Redis Master-Slave + DNS Service + Sentinel。
基本原理是Sentinel集群进行Redis的存活检测和Redis M-S状态切换。
完成切换之后，sentinel调用notification-script参数制定的配置文件，通知DNS Server更改DNS配置，master dns解析执行新的master。

3）Redis Master-Slave + Configure Center（Zookeeper） + Sentinel.
基本原理和第三种方案相似，只是notification-script通知的是配置中心完成redis连接配置的修改，比如Zookeeper实现的配置中心。

4）Redis Master-Slave + Sentinel + Twemproxy + Lvs.
这种方案层次比较多，sentinel通知twemproxy进行redis m-s的配置更改。

5）Redis Cluster，目前redis3.0接近发布stable版本了。

1、基本架构图

2、基本构建与原理
1）Keepalive + VIP : 在redis master-slave上部署keepalived、redis instance存活检测脚本、以及告警通知脚本。
2）当redis master失效的时候，VIP从master上漂移到slave上，完成m-s角色和配置更改。
3）客户端连接redis的参数中host设置的是VIP，整个切换过程对客户端透明。

3、优缺点与适用场景。
优点：实现简单，成本低。
缺点：整个集群的最大吞吐量受限于redis单实例的处理能力，除非一个应用使用多套这种Keepalive+VIP方案。
因而扩展能力较差，而且不适合目前单机部署多个redis实例的部署场景，而我们的一个物理机上至少部署8个redis实例。
目前我们DBA已经否定了这种架构，不再支持部署这种集群。
适合场景：并发请求不是很高的应用。

4、Keepalive配置和检测脚本
下面keepalive的简单配置、检测和通知脚本。
1）keepalive.conf
master和slave使用相同的配置脚本，其中要注意的地方state的配置都是backup状态，而且都是非抢占方式nopreempt。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

vrrp_script chk_redis {         script "/etc/keepalived/redis_check.sh"          interval 2                                      }   vrrp_instance VI_1 {         state BACKUP                                         interface bond0                                     virtual_router_id 51         priority 100                              nopreempt           authentication {                      auth_type PASS                      auth_pass redis             }         track_script {                 chk_redis                        }         virtual_ipaddress {              10.203.31.216                 }           notify_master  "/etc/keepalived/notify.sh master"         notify_backup  "/etc/keepalived/notify.sh backup" }

2）redis_check.sh，redis实例存活检测脚本。
当master检测到redis处于failed状态，将会释放VIP，slave机器将会获取VIP。

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#!/bin/bash REDIS_BIN='/apps/svr/redis/bin' REDIS_MASTER_HOST='127.0.0.1' REDIS_MASTER_PORT=6379   ALIVE=`$REDIS_BIN/redis-cli -h $REDIS_MASTER_HOST -p $REDIS_MASTER_PORT  PING`   if [ "$ALIVE" == "PONG" ]; then   echo $ALIVE   exit 0 else   echo $ALIVE   exit 1 fi

3）master-slave状态切换通知脚本，包括推送告警短信。
notify.sh

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

#!/bin/bash REDIS_BIN='/apps/svr/redis/bin' MASTER_IP='192.168.0.216' # virtual ip MASTER_PORT=6379   status=$1 echo $status   if [ "$status" = "master" ] then    # promoting slave to master    echo " config set slave-read-only no " | $REDIS_BIN/redis-cli -h 127.0.0.1 -p  $MASTER_PORT    echo " slaveof no one "                | $REDIS_BIN/redis-cli -h 127.0.0.1 -p  $MASTER_PORT    echo " config rewrite "                | $REDIS_BIN/redis-cli -h 127.0.0.1 -p  $MASTER_PORT    # pushing simple message to mobile or email   elif [ "$status" = "backup" ] then    # degrading master to slave    echo "config set slave-read-only yes " | $REDIS_BIN/redis-cli -h 127.0.0.1 -p  $MASTER_PORT    echo "slaveof $MASTER_IP $MASTER_PORT" | $REDIS_BIN/redis-cli -h 127.0.0.1 -p  $MASTER_PORT    echo " config rewrite "                | $REDIS_BIN/redis-cli -h 127.0.0.1 -p  $MASTER_PORT      # pushing simple message to mobile or email fi   exit 0