一、Sentinel介绍
之前骚了一波Redis的简介及应用场景，今天试了下他的哨兵模式；
Sentinel是Redis的高可用性（HA）解决方案，由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，
并在被监视的主服务器进行下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求。
Redis提供的sentinel（哨兵）机制，通过sentinel模式启动redis后，自动监控master/slave的运行状态，基本原理是：心跳机制+投票裁决
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器，
并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
二、Redis Sentinel搭建
测试采用2个哨兵，1个主redis，2个从redis。
复制5份redis.windows.conf文件并重命名如下（开发者可根据自己的开发习惯进行重命名）：
master.6379.conf 配置：
port 6379
#设置连接密码
requirepass grs
#连接密码
masterauth grs
slave.6380.conf 配置：
port 6380
requirepass grs
masterauth grs
dbfilename dump6380.rdb
#配置master
slaveof 127.0.0.1 6379
slave.6381.conf 配置：
port 6381
requirepass grs
masterauth grs
dbfilename dump6381.rdb
#配置master
slaveof 127.0.0.1 6379
sentinel.63791.conf 配置（将原配置文件清空后添加如下内容）（另一个一样，只需要修改下端口）：
port 63791
#主master，2个sentinel选举成功后才有效，这里的master-1是名称，在整合的时候需要一致，这里可以随便更改
sentinel monitor master-1 127.0.0.1 6379 2
#判断主master的挂机时间（毫秒），超时未返回正确信息后标记为sdown状态
sentinel down-after-milliseconds master-1 5000
#若sentinel在该配置值内未能完成failover操作（即故障时master/slave自动切换），则认为本次failover失败。
sentinel failover-timeout master-1 18000
#身份认证
sentinel auth-pass master-1 grs
#选项指定了在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步，这个数字越小，完成故障转移所需的时间就越长
sentinel parallel-syncs master-1 1
这里有三个问题需要注意
第一，若通过redis-cli -h 127.0.0.1 -p 6379连接，无需改变配置文件，配置文件默认配置为bind 127.0.0.1(只允许127.0.0.1连接访问）
若通过redis-cli -h 192.168.180.78 -p 6379连接，需改变配置文件，配置信息为bind 127.0.0.1 192.168.180.78（只允许127.0.0.1和192.168.180.78访问）或者将bind 127.0.0.1注释掉（允许所有远程访问）
第二，masterauth为所要连接的master服务器的requirepass,如果一个redis集群中有一个master服务器，两个slave服务器，当master服务器挂掉时，sentinel哨兵会随机选择一个slave服务器充当master服务器，鉴于这种机制，解决办法是将所有的主从服务器的requirepass和masterauth都设置为一样。
第三，sentinel monitor master-1 127.0.0.1 6379 2 行尾最后的一个2代表什么意思呢？我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，当sentinel集群式，解决这个问题的方法就变得很简单，只需要多个sentinel互相沟通来确认某个master是否真的死了，这个2代表，当集群中有2个sentinel认为master死了时，才能真正认为该master已经不可用了。（sentinel集群中各个sentinel也有互相通信，通过gossip协议）。
按如下循序依次启动服务
1、redis-server master.6379.conf
2、redis-server slave.6380.conf
3、redis-server slave.6381.conf
4、redis-server sentinel.63791.conf --sentinel（linux:redis-sentinel sentinel.63791.conf）
5、redis-server sentinel.63792.conf --sentinel（linux:redis-sentinel sentinel.63792.conf）
查看master状态：
查看slave状态：
查看sentinel状态：
验证redis sentinel的主从切换：
1、首先关闭主redis（6379）服务（shutdown）。
2、查看哨兵，发现端口号为6380的从服务变成了主服务,sentinel自动完成了故障切换。
3、启动刚才被shutdown的6379服务并查看，发现它变成了从服务。
到这 我搭建和演示就结束了
后续单机版 spring 整合使用慢慢玩吧，成功了再来
参考如下：
https://blog.csdn.net/liguangyan_neu/article/details/78027105
如果有不足和错误的地方还请各位大佬指点
谢谢！！！
