背景在生产环境中，为了保证redis服务的高可用，通常会搭建master-slave。我们知道主从的原理是从服务器获取rdb文件的全量副本+写操作的增量副本，共同保证数据的一致性，所以在配置从服务器的时候，一个很重要的配置项是表示master服务器的ip和端口号，你要知道哪个服务器是我的master，如下图replicaof配置。对于图中的部署方案，如果主服务器宕机，我们只能手动干预，重新选择一台从服务器作为主服务器，然后修改另外两台从服务器的配置文件，重新配置replicaof改成新的主服务器地址。人工干预费时费力，更重要的是会导致服务在一段时间内不可用。在这种场景下，哨兵模式应运而生。什么是哨兵模式Sentinelredis的哨兵模式用于一主多从的集群环境。如果master服务器宕机，会自动设置其中一台slave服务器为新的master，其余slave的配置文件自动修改，从而切换出一个新的master-slave服务，无需人工干预，并将不影响服务的使用。那么它究竟是如何工作的呢？先看下图：Sentinel模式结构图首先，Sentinel是一个独立于主从服务的服务，也是一个集群服务。哨兵实例会不断向主服务器发送Ping命令，主服务器收到命令后会返回一个有效的回复，这样哨兵实例就认为服务器是正常的。主观下线假设主服务器宕机，哨兵1在指定时间内（可配置）没有收到主服务器的有效回复，那么这个哨兵就会将服务器标记为下线，称为主观下线SDOWN。请注意，此时只有一个哨兵被标记为离线。事实上，哨兵没有收到回复的原因可能有很多。可能是服务器确实挂了，也可能是服务器没有挂。由于网络原因，没有收到回复。简而言之，哨兵未收到回复并不能证明主服务器已关闭。客观下线的Sentinel2也发了Ping命令，但同样没有收到回复，Sentinel2也会将主服务器标记为SDOWN。这时，3名哨兵中有2人报告了SDOWN。哨兵相互沟通后，认为有足够的实例可以证明该服务不再可用。因此，哨兵将服务器标记为客观离线ODOWN。这里的足够数量是可配置的。一般为哨兵数量的一半加1。比如有3个哨兵，则设置为2。在剩余的从服务器实例中选择一个作为主节点，同时修改剩余从服务器的配置文件，使用新的主节点作为数据同步源，然后重启服务完成切换。至此，一个完整的哨兵自动故障转移过程就完成了。springboot配置一主多从+sentinel。如果我们的环境从master-slave改成master-slave+sentinel，那么修改配置就比较简单了。首先将原来的host和port配置注释掉，替换成sentinel的配置，如下图：需要注意这里的nodes中配置的是sentinel集群的IP+端口，不是master-slave节点，所以一定不能配置错误。
