Redis 的主从复制模式下，一旦主节点由于故障不能提供服务，需要人工进行主从切换，同时大量的客户端需要被通知切换到新的主节点上，对于上了⼀定规模的应用来说，这种方案是无法接受的，于是 Redis 从 2.8 开始提供了 Redis Sentinel（哨兵）加个来解决这个问题。
在这之前我们需要先了解一下哨兵机制所关联到的一些名词。
如图：
主从复制的问题：
Redis 的主从复制模式可以将主节点的数据改变同步给从节点，这样从节点就可以起到两个作用：
第一，作为主节点的⼀个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上
来，并且保证数据尽量不丢失（主从复制表现为最终⼀致性。第⼆，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。但是主从复制模式并不是万能的，它同样遗留下以下几个问题：
第一，作为主节点的⼀个备份，一旦主节点出了故障不可达的情况，从节点可以作为后备 “顶” 上
来，并且保证数据尽量不丢失（主从复制表现为最终⼀致性。第⼆，从节点可以分担主节点上的读压力，让主节点只承担写请求的处理，将所有的读请求负载均衡到各个从节点上。但是主从复制模式并不是万能的，它同样遗留下以下几个问题：
1. 主节点发生故障时，进行主备切换的过程是复杂的，需要完全的人工参与，导致故障恢复时间无法保障。
2. 主节点可以将读压力分散出去，但写压力/存储压力是无法被分担的，还是受到单机的限制。
其中第一个问题是高可用问题，即 Redis 哨兵主要解决的问题。第⼆个问题是属于存储分布式的问
题，留给 Redis 集群去解决，本章我们集中讨论第⼀个问题。
从以上的问题中，如果我们进行人工恢复主节点，那么问题将会非常的繁琐。
这里我们引入哨兵的机制。
哨兵自动恢复主节点故障：
当主节点出现故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。
Redis Sentinel 是一个分布式架构，其中包含若干个 Sentinel 节点和 Redis 数据节点，每个
Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控，当它发现节点不可达时，会对节点做下线。
表示：如果下线的是主节点，它还会和其他的 Sentinel 节点进行 “协商”，当大多数 Sentinel 节点对主节点不可达这个结论达成共识之后，它们会在内部 “选举” 出⼀个领导节点来完成自动故障转移的 工作，同时将这个变化实时通知给 Redis 应用方。整个过程是完全自动的，不需要人工介入。整体的架构，如图所示：
Redis Sentinel 相对于主从复制模式是多了若干（建议保持奇数）Sentinel 节点⽤于实现监控数据节点，哨兵节点会定期监控所有节点（包含数据节点和其他哨兵节点）。针对主节点故障的情况，故障转移流程大致如下：
1）主节点故障，从节点同步连接中断，主从复制停止。
2）哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进行协商，达成多数认同主节点故障的共识。这步主要是预防该情况：出故障的不是主节点，而是发现故障的哨兵节点，该情况经常发生于哨兵节点的网络被孤立的场景下。
3）哨兵节点之间使用 Raft 算法选举出⼀个领导角色，由该节点负责后续的故障转移工作。
4）哨兵领导者开始执行故障转移：从节点中选择⼀个作为新主节点；让其他从节点同步新主节点；通知应用层转移到新主节点。
以上就是哨兵的基本的概念。
如果自己想通过实际的操作来进一步的去验证的话，前提是必须要有3台服务器以上，但是这里我们可以采用docker ，通过镜像的方式来部署这些节点。