国内的IDC机房一般只能保证99%的可用率，因此粗略计算的话一年会有三天多的时间无法访问服务。因此建立一个failover机制就相当有必要。我们使用Mysql和redis，因此需要解决mysql和redis的failover问题。

关于redis：对redis进行failover的思路主要有以下几种（参考自：http://tech.gmo-media.jp/post/48748908427/introduce-redis-sentinel

1. VIP方式，可以使用keepalived等软件来实现。keepalived也可以用来做mysql的failover。
2. hosts或dns方式。这种需要有脚本来定时监测和控制，如果发现失效就更新dns缓存或hosts表。
3. iptables方案。这种办法的优点是无需引入其他中间件，但是可能难以解决主从同步的问题。
4. 使用redis-sentinel。它的原理是引入多个哨兵，哨兵根据监测结果来切换主从服务器。需要客户端配合。

rails有一个gem，会使用redis的sentinel机制。参考资料：

github主页

部署使用说明

主从同步数据、持久化在redis端设定，与rails无关。注意：在master-slave部署模式下，只需slave实例配置Peplication相关项。

参考：

redis.conf中Replication配置项说明

7月3日更新

今天在虚拟机里配置了redis的主从复制，但是奇怪的是，主机无法连接到局域网内其他redis服务器。redis配置文件里已经写了bind 0.0.0.0，但是仍然无效。以为是权限的问题，使用sudo运行仍然无效。经过查询日志，发现redis的日志没有收到任何连接信息;redis ping也ping不通，主机本身能ping通。后来检查syslog发现被iptables阻止了。解决办法：在iptables的配置文件中加入放行redis的规则：

# redis -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 6379 -jACCEPT

清空iptables的现有规则：暂时禁用iptables

sudo /sbin/iptables -F

问题回避。经过测试，发现向主服务器写入的数据，在从服务器也能查询到。

关于sentinel文件：这个文件应该只写入master服务器，而不写slave服务器。

7月4日更新

考虑了一下不用redis哨兵而是也用keepalived的方案。因为一般来说是机房原因导致服务器宕掉的情况比较多，而进程崩溃情况相对较少，因此如果能使用keepalived的话，好处就是rails层面基本不需改动什么配置，只需要将redis和mysql的IP改为keepalived建立的虚拟IP就行了，这样比较透明。但由于redis目前不支持主主双向同步，因此需要解决一些问题。

redis的方案：

    * 直接在redis上配置主从同步、sentinel机制，并在rails中使用redis-sentinel的gem
    *
        * 要点
        *
            * 配置好至少两个哨兵
            * 哨兵的配置文件只写对主服务器的监视
            * 在rails项目中加入对应的Gemfile的行;redis和sidekiq的配置文件里增添相应的代码

        * 缺点
        *
            * 在服务器整台宕掉的前提下，redis哨兵推选新master的过程，和keepalived走新服务器的过程并不同步，在我的测试环境下，前者相对较慢。因此可能会造成mysql已经failover，但redis还未就绪
            * redis哨兵机制现在并不是正式版，日后行为可能会有变化
            * 如果在哨兵推选出新master之前redis回复服务，那么可能会造成无主状态

        * 优点
        *
            * 哨兵可以正确检测到redis进程崩溃的情况，而相应地keepalived只能检测到主机网络不可达，或keepalived进程挂掉的状况。


    * 使用keepalived
    *
        * 要点
        *
            * 如果keepalived狂写系统日志，可能是某两个模块未加载，执行：sudo modprobe ip_vs && sudo modprobe ip_vs_wrr
            * 配置文件中设置好虚拟IP和真实网卡的IP后，应能ping通虚拟IP。
            * 主服务器挂掉并恢复后，默认会抢占回来。这会造成很多麻烦。解决办法是：在配置文件中将主从服务器都设置为“backup”服务器;在逻辑上的主服务器的权限高于另一台，并设置nopreempt参数，这样就可以不抢占。
            * redis的配置文件中，双方都指定自己为对方的slave。这样宕掉的机器启动成功后，redis会读取配置文件自动成为新master的slave。
            * 在上一种情况下，如果不做特别的设置，那么双方在刚启动时都死锁无法查询，互相显示master已宕掉。这时，如果对虚拟IP的redis执行解除slave操作，则master-slave结构会正常。
            * 在keepalived的脚本中，分别写好如下的脚本：
            *
                * notify_master :当本台机器变成master时执行的脚本。指定本机没有slaveof。
                * notify_backup 当本台机器变成backup时执行的脚本。指定本机slaveof到另一台。

            * 这样的话，系统启动后，总会有一台作为master角色，因此master-slave结构就可以正常运作。

        * 缺点：
        *
            * 只能检测到系统宕机的情况，因此如果需要应对redis（或mysql）进程挂掉的情况，需要自己写监测脚本
            * 过程比较复杂，可能有意料之外的不稳定的地方

        * 优点：
        *
            * 当系统宕机后，keepalived可以检测到宕机并切换，虚拟IP不变，因此对客户端和rails都比较透明