前言

　　Redis在出从复制的模式下，一旦主节点由于故障不能提供服务，需要人工降从节点晋升为主节点，同时还要通知应用方更新主节点的地址，在很多应用场景下，这样的故障处理方式是无法被接受的。不过幸运的是Redis自从2.8之后，便正式提供了Redis Sentinel（哨兵）架构来解决这个问题，因此本文将开始说一下Redis Sentinel的一些基本概念特性。

一. 基本概念

　　Redis Sentinel 是 Redis的高可用的实现方案，再睡生产环境中，对提高整个系统的高可用是非常有帮助的，这里需要先回顾下主从复制模式下故障处理可能产生问题，而后再引出高可用的概念，最后再分析下 Redis Sentinel 的基本架构和优势，以及如何实现高可用。

二. 主从复制的问题

　　在Redis主从复制模式下，可以将主节点的数据改变同步给从节点，这样从节点就有两个作用：（1）作为主节点的一个备份，一旦主节点不可达了，那么从节点就能作为后备使用起来，且尽量保障主从复制的一致性。（2）从节点可以扩展从节点的读能力，一旦主节点不能支撑大并发的读操作，从节点在一定程度上是可以分担主节点的压力的。

　　但主从复制也会带来一下问题：

一旦主节点出现故障，需要手动将一个从节点晋升为主节点，同时还要修改应用方的主节点地址，还需要命令其他从节点来复制新的主节点，整个过程都需要人工干预，运维成本高。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。

三. 高可用

　　Redis在主从复制的模式下，当主节点出现不可达时，需要人工来干预做故障转移，这样不管是对Redis应用方来说，还是对运维来说，都是极其麻烦的。在应用方来看是无法及时感知到主节点的变化的，这样便必然造成数据丢失或读数据错误的情况，甚至造成应用方不可用。在运维方来看，整个故障都是需要人工介入，故障转移的实时性和准确性是无法保障的，如下图是展示1主2从的Redis主从复制模式下的主节点出现故障后是如何进行故障转移的。

流程说明：

主节点发生故障后，客户端（client）连接主节点失败，两个从节点与主节点连接失败，这样便导致复制中断了，如果主节点无法正常启动，需要选出一个从节点（slave-1），对其执行slaveof no one 命令，使其成为新的主节点。
当原来的从节点（slave-1）成为新的主节点后，更新应用方的主节点地址，重启应用方使其连接新的主节点。
客户端命令另一个从节点（slave-2）去复制新的主节点（new master）。
带原来的主节点恢复后，让它去复制新的主节点。

　　以上的整个流程，其设计不是高可用的，因为其整个故障转移都需要人工去干涉，考虑到这点，于是便促使 Redis Sentinel 的出现，其作用正是用于解决这些问题的。

四. Redis Sentinel 的高可用性

　　当主节点出现故障时，Redis Sentinel 能自动完成故障发现和故障转移，并通知应用方，从而实现真正的高可用。

　　Redis Sentinel 是一个分布式架构，其中包含若干个Sentinel界定和Redis数据节点，每个Sentinel节点会对数据节点和其余的Sentinel节点进行监控，当发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，它还会和其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，它们会选举出一个Sentinel节点来完成故障转移的工作，同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的，不需要人工干涉，所以这套方案很有效地解决了Redis的高可用问题。

　　Redis Sentinel 与 Redis 主从复制模式之间只是多了若干个 Sentinel 节点，所以 Redis Sentinel 并没有针对 Redis 节点做了特殊处理，这里容易让人混淆。如下图：