Keepalived实现redis的主从切换高可用原理详解

Keepalived实现redis的主从切换高可用原理详解

 

具体安装和配置keepalived和redis的教程，网上很多。

推荐几个：

 http://www.ttlsa.com/redis/redis-keepalived-achieve-high-availability/

 https://my.oschina.net/guol/blog/182491

keepalived默认只能做到对网络故障和keepalived本身的监控，即当出现网络故障或者keepalived本身出现问题时，进行切换。但我们更关注的是机器上运行的业务，如果业务出问题了VIP没有变化，整体来说还是失败的。这时候就需要根据业务进程的运行状态决定是否需要进行主备切换。还好keepalived提供了这样一个自定义脚本监控功能，不过该参数设置在官方默认的文档中并没有出现。

 

这里主要分析如何通过自定义脚本实现redis的主从切换。

我们需要着重看一下keepalived.conf

1.      vrrp_script &&track_script

     vrrp_script代码块是用来定义监控脚本，脚本执行时间间隔以及脚本的执行结果导致优先级变更幅度的。

2  notify_stop

      keepalived停止运行前运行notify_stop指定的脚本。

       配合官方文档提到的以下三个参数一起使用，功能更强大：

       notify_master  keepalived切换到master时执行的脚本  

       notify_backup  keepalived切换到backup时执行的脚本 

       notify_fault   keepalived出现故障时执行的脚本

 

通过keepalived的自定义脚本功能监控本机的redis服务状态，当监控脚本检测到redis服务出现异常时，则改变本机keepalived的优先级，同时这会导致master/backup角色的变化，而keepalived在角色变化时也会触发一些机制执行相关脚本，这就为我们改变redis的master/slave状态提供了机会，这样做的目的是为了是redis的master/slave直接的数据保持一致。

通过编写脚本，对返回的值进行判断

Exit 0：健康检查正常，keepalived状态正常

Exit 1：检查失败，keepalived状态异常

Exit 退出值等于其他值时，需要修改值为小于exitstatus的状态码

 

在keepalived+redis的使用过程中有四种情况：

 

    1一种是keepalived挂了，同时redis也挂了，这样的话直接VIP飘走之后，是不需要进行redis数据同步的，因为redis挂了，你也无法去master上同步，不过会损失已经写在master上却还没同步到slave上面的这部分数据。

 

    2另一种是keepalived挂了，redis没挂，这时候VIP飘走后，redis的master/slave还是老的对应关系，如果不变化的话会把数据写入redis slave中，从而不会同步到master上去，这就要借助监控脚本反转redis的master/slave关系。这时候就要预留一点时间进行数据同步，然后反转master/slave。

 

    3还有一种是keepalived没挂，redis挂了，这时候根据监控脚本会检测到redis挂了，通过返回exit 1，告诉keepalived状态异常，降低keepalived master的优先级，同样会导致VIP飘走，情况和第二种一样，也是需要进行数据同步，然后反转当前redis的master/slave关系的。

 

4 随后一种是keepalived没挂，redis也没挂，大吉大利啊，什么都不用操作。

 

在script下有五个脚本，一个是检测redis状态的redis_check.sh脚本，其余四个是keepalived状态变化时执行的脚本。keepalived有master/backup/stop/fault四种状态，因为我们主要是关注系统上的业务，所以在在keepalived进入fault/stop状态后，也认为是进入了backup状态，需要对redis的master/slave关系进行反转，否则即使VIP漂移过去，但是redis的主从关系还没有改变，会导致数据不一致，所以最终四个脚本只有两种内容。

Redis的高可用方案目前主要尝试过4种方式:

1）RedisMaster-Slave + Keepalive + VIP。

这是很经典的db架构，也可以用与MySQL的主从切换。

 

基本原理是：Keepalive通过脚本检测master的存活，然后通过漂移VIP（Virtual IP）完成主从切换。

2）RedisMaster-Slave + DNS Service + Sentinel。

基本原理是Sentinel集群进行Redis的存活检测和RedisM-S状态切换。

完成切换之后，sentinel调用notification-script参数制定的配置文件，通知DNSServer更改DNS配置，master dns解析执行新的master。

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

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

notify_master/backup/fault分别表示切换为主/备/出错时所执行的脚本。