一、首先配置redis的主从同步集群。
1、主库的配置文件不用修改，从库的配置文件只需增加一行，说明主库的IP端口。如果需要验证的，也要加多一行，认证密码。
slaveof 192.168.20.26 5268
masterauth hodge01
一主多从的话，就启用多个从库。其中，从库都是一样的方案。本次有两个slave。
2、命令检查。
/usr/local/redis/bin/redis-cli -p 5257 -a hodge01 info Replication
二、sentinel高可用。
1、概况。sentinel是redis自带的附件，在新的版本redis安装都有sentinel。sentinel是称作哨兵的监控机制，当达到一定数量的sentinel投票支持，redis的master就会切换。本次使用docker容器搭建，主要讲述配置文件。
2、配置文件。注意：每次要抛弃上一次集群都考检查配置文件，因为sentinel是靠更改配置文件实现功能的。
监听端口。
第一行最后的那个2，是说明需要两个sentinel确认客观下线，需要切换，才能操作。
如果有需要密码验证的，要在这里添加密码信息，否则不能通讯。
在配置文件后面几行是启动后系统自动添加。
3、启动。
启动之后，本实验就是3台redis，三台sentinel，sentinel的配置文件自动填写了sentinel集群和redis集群的信息。因为网络影响，所以单单凭一台sentinel之言就随便切换，所以一般情况需要3台sentinel以上。
确认5268是master，连接两个slave。
4、测试。
a、关掉5268redis。
b、检查4157和5257redis。发现master已经转移到5257。
c、查看转移日志。
+failover-state-reconf-slaves master mymaster
…………
+failover-end master mymaster
第一行是确认预先的架构复核标准。
第二行认为5268已经客观下线。
第三行表示准备重写主从架构的配置文件。
第四行表示开始重写。
第五行表示故障切换处理5268完毕.。
第六、七行记录在sentinel中已经认为4157和5268作为slave已经追随5257master。
第九行sentinel认为5268已经沦落为slave，但是并不在线。紧接着标记主观下线。
第十行表示5268重启后符合slave标准，用“-”移除主观下线记录。
但是，查了两次5257，并没有发现5268的信息。于是我们查看redis5258的日志，看没有连上master是怎么回事，反正sentinel那边已经认为连上。
d、恢复后的redis5268的日志。（异常处理）
NOAUTH Authentication required.
满满的认证不成功，已经很明显告知，5268恢复之后就是slave了，因为此时的5257已经有了密码，而5268没有密码记录，自然没有认证成功连上master5257。
所以在redis5268加上在master面前的认证密码。
masterauth hodge01
e、重启验证。
重启redis5268
检查redis master5257，发现5268已经连上。
到此为止，sentinel支持的redis高可用集群就全部完成，IP自动切换方面下次探索。