一、端口轉發

如果在一個主機里面，安裝了兩個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、檢查后一切正常