redis哨兵模式-Sentinel

• 我们之前知道主从模式可以提高redis的高可用性，那如果主节点凌晨 3 点redis主机突然宕机怎么办? 难道等着运维从睡梦中醒来，或者自己半夜起来手工进行从主切换，再通知所有的程序把地址统统改一遍重新上线么? (因为从数据库IP或者端口号跟主数据库是不一样的)毫无疑问，这样即麻烦又效率低。

• 所以我们必须有一个高可用方案来抵抗节点出现故障的问题，当故障发生时可以自动进行从主切换，程序可以不用重启，我们也不需要半夜起来手动切换了。而这个方案就是Redis给我们提供的Redis Sentinel(哨兵)模式了

• Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，是Redis高可用解决方案，哨兵可以监视一个或者多个redis master服务，以及这些master服务的所有从服务。期间如果某个master服务宕机，它就会把这个master下的某个从服务升级为master来替代已宕机的master继续工作。

• 主节点挂掉了，原先的主从复制也断开了，客户端和损坏的主节点也断开了。从节点被提升为新的主节点，其它从节点开始和新的主节点建立复制关系。客户端通过新的主节点继续进行交互。

• Sentinel 会持续监控已经挂掉了主节点，待它恢复后，之前的主节点将会变成从节点跟新的主节点建立主从复制关系

哨兵环境搭建：

• 因为Sentinel本身也需要多个哨兵共同确认主节点是否宕机，所以一个稳健的 Redis Sentinel集群建议至少使用三个 Sentinel 实例，并且保证讲这些实例放到不同的机器上，甚至不同的物理区域。

• 这里我们在服务器创建一个sentinel目录，然后里面创建sentinel01、sentinel02、sentinel03三个目录，并目每个目录下都创建data和conf目录。

然后使用docker分别创建三个不同的sentinel容器环境，然后进入sentinel容器查看info.

我们停止掉redis-master来模拟宕机等故障信息，然后通过“info replication”查看角色信息是否自主完成了主从切换。

当我们再次启动redis-master的时候，发现它已经变为了slave的角色