哨兵解决的问题与原理：

哨兵解决的问题：

Redis的主从模式可以将主节点的数据改变同步给从节点，从节点就可以起到两个作用：

（1）作为主节点的一个备份。一旦主节点出现了故障，不可达，从节点可以作为后备，顶上来，保证数据尽量不丢失。

（2）从节点可以扩展主节点的读能力。如果主节点撑不住大量并发的读操作，此时可以分担主节点的读能力。

主从复制也随之带来了一下几个问题：

（1）一旦主节点出现了故障，需要手动的将一个从节点晋升为主节点，同时需要修改应用方（即客户端）的连接主节点的地址和端口号。还需要命令其他从节点去复制新的主节点，这整个过程都需要人工的操作。

（2）主节点的写能力、存储能力收到单机的限制。

第（1）个问题就是Redis的高可用问题了，第（2）个问题是Redis分布式的问题。这里主要总结第一个问题，Redis的高可用问题。

Redis 哨兵就能解决这个问题。其实，哨兵不止解决了自动故障转移问题，还能提供监控Redis主从数据库、提醒的重要功能。

因此，哨兵具有以下功能：

监控：哨兵节点定期检测Redis数据节点，其余哨兵节点是否可达；

通知：哨兵节点会将故障转移的结果通知给应用方；

主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系；

配置提供者：在Redis哨兵结构中，客户端在初始化的时候连接的哨兵节点集合，从中获取主节点信息。

原理：

哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。
​ 每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown).
若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。
​ 虽然哨兵(sentinel) 释出为一个单独的可执行文件 redis-sentinel ,但实际上它只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。