sentinel监控redis高可用集群（二）

一、端口转发。

如果在一个主机里面，安装了两个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、检查后一切正常。