背景
在生产环境中，为了保证redis服务的高可用，通常都会搭建主从。我们知道主从的原理是从服务器获取rdb文件的全量复制+写操作的增量复制来共同保证数据的一致性，所以在配置从服务器的时候，一个很重要的配置项就是标明主服务器的ip和端口号，总得知道哪一台服务器是我的主子不是，像下图中的replicaof配置。
对于图中的部署方案，如果主服务器宕机了，我们只能进行手动干预，选择一台从服务器重新作为主服务器，然后将另外的两台从服务器的配置文件修改一下，将replicaof的配置重新改成新的主服务器地址。人工干预费时费力不说，更重要的是，这样会造成一段时间内服务是不可用的。在这种场景下，哨兵模式应运而生了。
什么是哨兵模式Sentinel
redis的哨兵模式，就是用于在一主多从的集群环境下，如果主服务器宕机了，它会自动的将从服务器中的一台设为新的master，并且将其余的slave的配置文件自动修改，这样就切换出一套新的主从服务，不需要人工干预，且不会影响服务的使用。
那么它具体是怎么工作的呢？首先看下面这张图：
哨兵模式结构图
首先哨兵是一个独立于主从服务之外的服务，它也是一个集群服务。哨兵实例会不断给主服务器发送Ping命令，主服务器在收到命令后，返回一个有效回复，这样哨兵实例认为服务器是正常的。
主观下线
假设主服务器宕机，哨兵1在指定时间内(可配置)没有收到主服务器的有效回复，那么这个哨兵会把服务器标记为下线，叫做主观下线SDOWN。
注意此时只有一个哨兵标记为下线，实际上哨兵没有收到回复原因可能有很多，可能是服务器确实挂了，也有可能是服务器并没有挂，由于网络原因没有收到回复，总之，一个哨兵没有收到回复并不能证明主服务器宕机。
客观下线
哨兵2也发送了Ping命令，同样也没有收到回复，哨兵2也会将主服务器标记为SDOWN。这个时候，3个哨兵中有2个哨兵上报了SDOWN，哨兵们在彼此交流之后，认为已经有足够数量的实例证明该服务已经不可用，因此，哨兵实例会将该服务器标记为客观下线ODOWN。
这里的足够数量是可配置的，一般是哨兵个数的一半加1，比如3个哨兵则就设置为2。
投票选举，故障转移
当哨兵实例将服务标记为客观下线时，会进行一次选举。在剩下的从服务器实例中，选出一个作为主节点，并同时修改其余从服务器的配置文件，将新的主节点作为数据同步的来源，然后重新启动服务，完成切换。
至此，一个完整的哨兵自动进行故障转移的过程就完成了。
springboot配置一主多从+哨兵
如果我们的环境由主从换成了主从+哨兵，修改配置也比较简单，先注释掉原来的host和port的配置，替换成哨兵的配置，如下图：
需要注意的是，这里nodes里配置的是哨兵集群的IP+端口，而不是主从节点，一定不要配错了。
