先讲解一下sentinel配置文件的主要配置：
// Sentinel节点的端口
port 26379
dir /usr/local/redis/tmp
// 当前Sentinel节点监控 127.0.0.1 这个主节点//
1代表判断主节点失败至少需要2个Sentinel节点节点同意，这个数字应该<=sentinel主机数量//
mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6379 2
master被当前sentinel实例认定为“失效”的间隔时间
如果当前sentinel与master直接的通讯中，在指定时间内没有响应或者响应错误代码，那么
当前sentinel就认为master失效
sentinel down-after-milliseconds mymaster 30000
//当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，
选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1
//故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000
进入正题：
还是https://blog.csdn.net/a944750471/article/details/80717930这里的环境
sentinel就一台（应该弄三台的），监控master
1、修改sentinel配置文件（这里不让他后台运行）
dir /usr/local/redis/tmp
sentinel monitor mymaster 47.101.32.189 6379 1
2、修改slave（6380配置文件中的slave-priority）
slave-priority 99
默认值是100。master down了之后sentinel会选slave-priority值更小的作为新的master。
如果slave-priority一样，则随机选一个为master（好像是这样）。
3、测试
1）、先启动sentinel
sentinel的启动方式有以下两种：
bin/redis-sentinel ./sentinel.conf
bin/redis-server ./sentinel.conf --sentinel
因为没有启动被监控的master和slave所以出现下图
2）、启动master
新增以下log
3）、依次启动slave（6379）和slave（6380）
新增以下log
4）、让master down
新增以下log
master down了
继续出现log
查看slave（80）
已经变成新的master了，并且有了一个slave，slave是slave（79）
查看slave（79）
变成slave(80)的slave了
重新启动原来的master
新增以下log
原master连接上了，并且更改为slave（80）的slave了
查看原master
变成slave（80）的slave了
查看slave（80）
有两个slave了
ps:把所有redis和sentinel关闭后再重新启动，启动后的状态会和sentinel做完故障切换后的状态一样。
因为sentinel做完故障切换的时候会修改redis和sentinel的配置文件！
关于设置连接密码：
修改所有master、slave的配置文件的requirepass和masterauth （保持一致）
requirepass 123123
masterauth 123123
修改sentinel的配置文件的sentinel auth-pass
sentinel auth-pass mymaster 123123
修改完成后可正常进行主从复制和sentinel监控
有不正确的地方还望指出！