一、端口转发。
如果在一个主机里面，安装了两个redis实例，可以在项目里面配置IP端口，用iptables转发。
iptables -t nat -A PREROUTING -p tcp --dport 6379 -j REDIRECT --to-ports 7379
当发生切换的时候，触发了脚本，执行语句。端口可以马上转发带正确的redis上面。参数的含义：
脚本配置：
脚本实例：
#!/bin/bash
iptables -t nat -I PREROUTING -p tcp --dport 6379 -j REDIRECT --to-ports $7
这样在项目配置就可以直接使用6379，有什么切换交给iptables转发。IP转发也可以用这种方法实现。不能这样实现的原因是，sentinel和redis都是由不同的容器实现。除非用宿主机安装的办法，不然由sentinel执行的脚本根本不能控制到宿主机的iptables来选择redis。
二、修改HOST文件。
这种方法和第一种少有不同。就不是从网络上面改了。项目里面的配置可以直接用主机名。不过这种方法的缺陷是只能改IP，就是说使用的端口号要一致，每次故障只切换IP，不切换端口。
echo "192.168.20.26 redis" >> /etc/hosts
这种方法不能实现的原因是，sentinel和项目执行容器独立，由sentinel执行的脚本动不了apache的host文件，除非sentinel和apache共享host文件。这非常麻烦。而且，每个sentinel有执行一次，就需要和sentinel一样数量的apache容器。
脚本示例：
#!/bin/bash
sed -i 's/$4/$6/g' /etc/hosts
三、用第三方代理haproxy。
用这种方法的话，就不管sentinel怎么切换，haproxy只需检测到可读写的redis交给项目就行，而且项目里面配置指向haproxy的IP。
上图可知haproxy是通过交互发现master可用，slave都切换为down。haproxy是利用轮询检测。
项目的配置：
四、插曲
这里是sentinel检测redis。如果3个redis，mater挂了，另外一个slave顶上。如果master重启了，却没有加入集群。
问题就在这里，1的状态都知道2是master，2确不知道有1这个slave。那就是1和2没有通讯了。
1、初始状态：
2、初始master：
3、关掉1，
4、2切换为master：
5、master状态：
6、重启1的状态：
1启动之后，马上变为master，但是没有slave，后面切换回slave，他的master是2.。就是说1是master，2、3都是slave，1的状态可以看到2、3的存在。1挂了，2就是master，3还是slave。1重启了就应该是slave，1的状态也说他的master是2，但是2说他只有3这一个slave。
7、查看sentinel的切换日志：
第一行，说明检测到1已经挂了。
第二行，移除挂了这个状态，即是1已经恢复。
第三行，把1转变为slave，master为2.
这个日志说明出问题不在sentinel，因为他已经完成了使命。
8、查看1的日志：
这个日志说明1想去连接，但是认证失败。
9、我们去改redis的配置：
10、检查后一切正常。