1. 需求描述

redis 主从模式下，当 master 服务意外停掉或该服务所在的主机发生宕机故障或网络故障时，另一台 redis 服务会由 slave 自动成为 master，提供读写服务。

2. 需求分析

刚开始主从模式如下：

当redis master挂掉后，原来的redis slave被提升为主，客户端自动将请求切换到新的master，如下图：

原来的master恢复后，手动添加节点，并以slave的角色加入到原来的主从模式中，如下图：

根据上述故障恢复流程，可以抽象出以下几个关键技术点：

1. 当 master 挂掉后，如何将 slave 提升为新的 master ？
2. 如何通知 client 将请求打到新的 master ？

3. 方案调研

3.1 如何将 slave 提升为新的 master

使用 redis 官方的 sentinel 组件。如下图：

使用一组 sentinel 节点对 redis 主从节点做监控。当 master 节点故障后，sentinel 会从 slave 节点中选出一个做为 master，并通知其它的 slave 和新的 master 做数据同步，如下图：

问题点：

1. 使用一组 sentinel 集群监控所有的 reids 主从节点。当监控的主从节点较多时，sentinel 是否会有性能瓶颈？
2. sentinel 不支持跨机房部署，备机房是否需要做 sentinel 监控？

3.2 如何通知 client 将请求打到新的 master

3.2.1 方案一

客户端每次请求时，先从 sentinel 中获取 master 地址，再访问 master 节点。

1. 客户端先连接 sentinel 节点，执行 SENTINEL get-master-addr-by-name <master name>命令，返回给定名字的 master 的 IP 地址和端口号。 如果这个 master 正在执行故障转移操作， 或者针对这个 master 的故障转移操作已经完成， 那么这个命令返回新的 master 的 IP 地址和端口号。
2. 通过获取到的 master 地址和端口号，再访问 master 节点。

优点：

1. 方案简单，不需要依赖其它组件或配置。

缺点：

1. 业务端需要做修改，每次访问 master 节点前，先要查询 sentinel，多一次网络传输。

3.2.2 方案二

VIP 漂移，master 节点所在机器配置 VIP (虚拟ip地址)，当发生主从切换后，将 VIP 绑定到新的 master 节点所在的机器上。

触发 VIP 漂移有两种方式：

1.sentinel 主动触发

故障发生后，sentinel 触发 VIP 漂移，将 VIP 绑定到新的 master 上

sentinel 如何触发 VIP 漂移？

这里可以使用 redis sentinel 的一个参数 client-reconfig-script

sentinel client-reconfig-script <master-name> <script-path>
当一个master由于failover而发生改变时，这个脚本将会被调用并且传递6个参数
<master-name>、 <role>、 <state>、 <from-ip>、 <from-port>、 <to-ip> 、<to-port>，
其中<to-ip>是新主redis的IP地址，可以在这个脚本里做VIP漂移操作。

举例：

sentinel client-reconfig-script master8000   /opt/notify_master6800.sh

修改三个服务器的redis-sentinel配置文件/etc/sentinel.conf，增加上面一行。然后在/opt/目录下创建notify_master6800.sh脚本文件，这个脚本做VIP漂移操作，内容如下：

#notify_master6800.sh脚本内容
#!/bin/bash
MASTER_IP=$6  #第六个参数是新主redis的ip地址
LOCAL_IP='192.168.56.101'  #其他两个服务器上为192.168.56.102，192.168.56.103
VIP='192.168.56.250'
NETMASK='24'
INTERFACE='eth1'
if [ ${MASTER_IP} = ${LOCAL_IP} ];then   
    /sbin/ip  addr  add ${VIP}/${NETMASK}  dev ${INTERFACE}  #将VIP绑定到该服务器上
    /sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
    exit 0
else 
   /sbin/ip  addr del  ${VIP}/${NETMASK}  dev ${INTERFACE}   #将VIP从该服务器上删除
   exit 0
fi
exit 1  #如果返回1，sentinel会一直执行这个脚本

优点：

1. 对客户端透明，客户端无需改动。
2. 故障切换响应快，sentinel 做完主从切换后，可以主动触发 VIP 漂移。

缺点：

1. 只适合单个 redis 的高可用。如果机器上部署了多个redis master，只有一个 redis master 故障，就会导致 VIP 漂移，那么机器上其它 master 实例就无法访问（因为其它 master 还在原来的机器上，但请求已经打到 VIP 所在的机器上）。
2. 需要有 ssh 权限，执行 VIP 漂移相关命令。

2.通过 keepalived 触发

在每台 redis 实例上的机器上起一个 keepalived 服务，在多个 keepalived 组里面有一个 keealived master 和多个 backup，master 上面有一个对外提供服务的 VIP。

keepalived master 会发组播到 backup，故障发生时，keepalived 检测到 redis master 不可用，调用自定的 stop 脚本，将本机器的 keepalived 进程杀死。keepalived backup 收不到 keepalived master 的 vrrp 包时，认为 keepalived master 挂掉了，这时就需要根据 vrrp 的优先级来选举一个 backup 当 master，这样的话就可以保证路由器的高可用了。

优点：

1. 对客户端透明，客户端无需改动。
2. 不需要通过脚本修改 VIP，keepalived 会自动设置。

缺点：

1. 每个 redis 所在机器都要部署 keepalived 服务。
2. VIP 漂移有一定的延时，依赖 keepalived 健康检测周期。
3. 不适合单机器上部署多个 redis 实例。

VIP 漂移方案总结：

只适合单个 redis 高可用，不适合但机器上多个 redis 实例的部署。

3.2.3 方案三

使用 consul 服务发现组件，架构图如下：

1. redis 节点所在的机器都部署一个 consul client，主要负责和 consul server 通信。
2. redis 节点通过 consul client 将自己以服务的方式注册到 consul server。同一组主从节点注册的服务名相同。查询 consul server 时，相同服务名会返回该名称下所有可用的服务IP地址和端口。
3. redis 节点注册服务时会提供一个自定义的健康检测脚本，consul client 定期执行健康检测脚本。脚本返回0表示服务可用，返回2表示服务不可用。
4. 健康检测脚本主要判断该节点的 role 是否是 master，如果是 master，则返回0，表示服务可用；如果返回2，表示服务不可用。
5. 向 consul 集群查询 test_redis 服务时，由于 slave 健康检测都不可用，所以只会返回 master 的地址。

发生故障转移时：

1. sentinel 将 slave 1提升为 master 后，该节点的健康检测脚本发现服务的 role 变为 master，所以健康检测通过，服务可用。
2. 向 consul 集群查询 test_redis 服务，返回新的 master 的 IP 地址和端口号。

上述故障转移流程，客户端都是先查询 consul server 获取可用的 master 地址，然后再通过 master 地址访问 redis 服务，类似于方案一中的先查 sentinel，再连接 master。如果是使用这种方案，引入 consul 组件显得多此一举，还不如方案一简单。那么通过 consul，有没有更优雅的方式来获取到 master 地址呢？—— consul DNS 接口。

通过 consul DNS 接口，做服务自动发现：

1. 服务注册到 consul 后，consul 都会为服务生成一个域名，如test_redis.service.consul，后缀为service.consul
2. 客户端通过域名访问服务，配置局域网内的 DNS 服务器，将后缀为 consul 的域名都转发到 conusl server 机器上。
3. consul server 的 DNS 端口为8600，而默认的 DNS 端口为53，可以通过 dnsmasq 服务。在 consul server 机器上，启动 dnsmasq 服务，将 consul 域名转发到8600端口，这样就可以通过 consul server，返回域名对应的服务地址。

优点：

1. 客户端通过域名访问服务，不需要做其它调整，后端切换 master 地址对客户端透明。
2. 相比 VIP 漂移，更加灵活，支持对一台机器上的多个 redis 主从实例做高可用。

缺点：

1. 引入了新的 consul 和 dnsmasq 组件，所有的 redis 机器几点都需要安装 consul client服务。