redis数据库哨兵（理论）

Redis哨兵
Redis的主从复制模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用场景这种故障处理的方式是无法接受的。可喜的是Redis从2.8开始正式提供了Redis Sentinel (哨兵)架构来解决这个问题,本章会对Redis Sentinel进行详细分析。

基本概念
名词 逻辑结构 物理结构 主节点 Redis主服务 一个独立的Redis进程 从节点 Redis从服务 一个独立的Redis进程Redis数据节点 主节点和从节点 主节点和从节点的进程 Sentinel节点 监控Redis数据节点 一个独立的Sentinel进程 Sentinel节点集合 若干个Sentinel节点的抽象组合 若干个Sentinel节点进程 Redis Sentinel Redis高可用方案Sentinel节点集合和Redis数据及诶单进程

主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备“顶”上来,并且保证数据尽量不丢失(主从复制是最终一致性)。 第二,从节点可以扩展主节点的读能力,一旦主节点不能支撑住大并发量的读操作,从节点可以在一定程度上帮助主节点分担读压力。 但是主从复制也带来了以下问题: （1）一旦主节点出现故障,需要手动将一个从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令其他从节点去复制新的主节点,整个过程都需要人工干预。 （2）主节点的写能力受到单机的限制。 （3）主节点的存储能力受到单机的限制。

高可用
Redis主从复制模式下,一旦主节点出现了故障不可达,需要人工干预进行故障转移.无论对于Redis的应用方还是运维方都带来了很大的不便。对于应用方来说无法及时感知到主节点的变化,必然会造成一定的写数据丢失和读数据错误,甚至可能造成应用方服务不可用。对于Redis的运维方来说,整个故障转移的过程是需要人工来介入的,故障转移实时性和准确性上都无法得到保障，一个1主2从的Redis主从复制模式下的主节点出现故障后,是如何进行故障转移的。 1)主节点发生故障后,客户端(client)连接主节点失败,两个从节点与主节点连接失败造成复制中断。 2)如果主节点无法正常启动,需要选出一个从节点(slave-1),对其执行slaveof no one命令使其成为新的主节点。 3)原来的从节点（slave-1）成为新的主节点后，更新应用方的主节点信息，重新启动应用方 4)客户端命令另一个从节点（slave-2）去复制新的主节点（new-master） 5)待原来的主节点恢复后，让它去复制新的主节点。上述处理过程就可以认为整个服务或者架构的设计不是高可用的,因为整个故障转移的过程需要人为介入。考虑到这点,有些公司把上述流程自动化了,但是仍然存在如下问题:第一，断节点不可达的机制是否健全和标准。第二,如果有多个从节点,怎样保证只有一个被晋升为主节点。第三，通知客户端新的主节点机制是否足够强壮。Redis Sentinel正是用于解决这个问题。

Redis Sentinel的高可用性当主节点出现故障时, Redis Sentinel能自动完成故障发现和故障转移,并通知应用方,从而实现真正的高可用。Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成第六章sentinel.md2020/3/132 / 4自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决了Redis的高可用问题。Redis Sentinel与Redis主从复制模式只是多了若于Sentinel节点,所以Redis Sentinel并没有针对Redis节点做了特殊处理,这里是很多开发和运维人员容易混淆的。从逻辑架构上看, Sentinel节点集合会定期对所有节点进行监控,特别是对主节点的故障实现自动转移。假设我们现在有一个主节点，两个从节点和三个Sentinel节点组成的Redis Sentinel的例。 整个故障转移的处理逻辑有下面4个步骤: 1)主节点出现故障,此时两个从节点与主节点失去连接,主从复制失败 2)每个Sentinel节点通过定期监控发现主节点出现了故障。 3)多个Sentinel节点对主节点的故障达成一致,选举出其中一个sentinel节点作为领导者负责故障转移。 4)Sentinel领导者节点执行了故障转移。通过上面介绍的Redis Sentinel逻辑架构以及故障转移的处理,可以看出Redis Sentinl具有以下几个功能: （1）监控: Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。 （2）通知: Sentinel节点会将故障转移的结果通知给应用方。 （3）主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。 （4）配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节占 集合,从中获取主节点信息。同时看到, Redis Sentinel包含了若干个Sentinel节点,这样做也带来了两个好处: （1）对于节点的故障判断是由多个Sentinel节点共同完成,这样可以有效地防止误判。 （2）Sentinel节点集合是由若干个Sentinel节点组成的,这样即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。 但是Sentinel节点本身就是独立的Redis节点,只不过它们有一些特殊,它们不存储数据,只支持部分命令。

配置优化
Sentinel monitor Sentinel节点会定期监控主节点,所以从配置上必然也会有所体现,本配置说明Sentinel节点要监控的是一个名字叫做, ip地址和端口为 的主节点.代表要判定主节点最终不可达所需要的票数。但实际上Sentinel第六章sentinel.md2020/3/133 / 4节点会对所,有节点进行监控,但是在Sentinel节点的配置中没有看到有关从节点和其余Sentinel节点的,配置,那是因为Sentinel节点会从主节点中获取有关从节点以及其余Sentinel节点的相关信息。 参数用于故障发现和判定,例如将quorum配置为2、代表至少有2个Sentinel节点认为主节点不可达,那么这个不可达的判定才是客观的。对于设置的越小,那么达到下线的条件越宽松,反之越严格。一般建议将其设置为Sentinel节点的一半加1。 同时还与Sentinel节点的领导者选举有关,至少要有max (quorum, num(sentinels) /2 + 1)个Sentinel节点参与选举,才能选出领导者Sentinel,从而完成移。例如有5个Sentinel节点, quorum-4,那么至少要有max (quorum, num(sentinels)/2 +1)=4个在线Sentinel节点才可以进行领导者选举。(2) sentinel down-after-milliseconds Sentinel down-after-milliseconds 每个Sentinel节点都要通过定期发送ping命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过了down-after-milliseconds配置的时间且没有有效的回复，则判定节点不可达, (单位为毫秒)就是超时时间。这个配置是对节点失败判定的重要依据。 优化说明: down-after-milliseconds越大,代表Sentinel节点对于节点不可达的条件越宽松,反之越严格。条件宽松有可能带来的问题是节点确实不可达了,那么应用方需要等待故障转移的时间越长,也就意味着应用方故障时间可能越长。条件严格虽然可以及时发现故障完成故障转移,但是也存在一定的误判率。(3) sentinel parallel-syncs Sentinel parallel-syncs 当Sentinel节点集合对主节点故障判定达成一致时, Sentinel领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作, parallel-syncs就是用来限制在一次故障转移之后,每次向新的主节点发起复制操作的从节点个数。如果这个参数配置的比较大,那么多个从节点会向新的主节点同时发起复制操作,尽管复制操作通常不会阻塞主节点,但是同时向主节点发起复制,必然会对主节点所在的机器造成一定的网络和磁盘IO开销。parallel-syncs-3和parallel-syncs-1的效果, parallelsyncs-3会同时发起复制, parallel-syncs-1时从节点会轮询发起复制。(4) sentinel failover-timeout Sentinel failover-timeout failover-timeout通常被解释成故障转移超时时间,但实际上它作用于故障转移的各个阶段: a)选出合适从节点。 b)晋升选出的从节点为主节点。 c)命令其余从节点复制新的主节点。 d)等待原主节点恢复后命令它去复制新的主节点。failover-timeout的作用具体体现在四个方面: 1)如果Redis Sentinel对一个主节点故障转移失败,那么下次再对该主节点做故障转移的起始时间是failover-timeout的2倍。 2)在b)阶段时,如果Sentinel节点向a)阶段选出来的从节点执行slaveof no one一直失败(例如该从节点此时出现故障),当此过程超过failover-timeout时,则故障转移失败。 3)在b)阶段如果执行成功, Sentinel节点还会执行info命令来确认a)阶段选出来的节点确实晋升为主节点,如果此过程执行时间超过failover-timeout时,则故障转移失败。 4)如果c)阶段执行时间超过了failover-timeout (不包含复制时间),则故障转移失败。注意即使超过了这个时间, Sentinel节点也会最终配置从节点去同步最新的主节点。 (5) sentinel auth-pass 配置如下: sentinel auth-pass 如果Sentinel监控的主节点配置了密码, sentinel authpass配置通过添加主节点的密码,防止Sentinel节点对主节点无法监控。 (6) sentinel notification-script 配置如下:sentinel notification-script sentinel notification-script的作用是在故障转移期间, 当一些警告级别的sentinel事件发生(指重要事件,例如-sdown :客观下线、-odown : 主观下线)时,会触发对应路径的脚本,并向脚本发送相应的事件参数。 (7) sentinel client-reconfig-script 配置如下: sentinel client-reconfig-script sentinel client-reconfigscript的作用是在故障转移结束后,会触发对应路径的脚本,并向脚本发送故障转移结果的相关参数。

部署技巧
到现在有关Redis Sentinel的配置和部署方法相信你们已经基本掌握了,但在实际生产环境中都有哪些部署的技巧？

1. Sentinel节点不应该部署在一台物理“机器”上。 这里特意强调物理机是因为一台物理机做成了若干虚拟机或者现今比较流行的容器,它们虽然有不同的IP地址,但实际上它们都是同一台物理视,同一台物理机意味着如果过台机器有什么硬件故障,所有的虚拟机都会受到影响,为了实现Sentinel节点集合真正的高可用,请勿将Sentinel节点部署在同一台物理机器上。 2)部署至少三个且奇数个的sentinel点。 3个以上是通过增加第六章sentinel.md2020/3/134 / 4Sentinel节点的个数提高对于故障判定的准确性,因为领导者选举需要至少一半加1个节点,奇数个节点可以在满足该条件的基础上节省一个节点。 3)只有一套Sentinel,还是每个主节点配置一套Sentinel? Sentinel节点集合可以只监控一个主节点,也可以监控多个主节点那么在实际生产环境中更偏向于哪一种部署方式呢,下面分别分析两种方案的优缺点。 方案一:一套Sentinel,很明显这种方案在一定程度上降低了维护成本,因为只需要维护固定个数的Sentinel节点,集中对多个Redis数据节点进行管理就可以了。但是这同时也是它的缺点,如果这套Sentinel节点集合出现异常,可能会对多个Redis数据节点造成影响。还有如果监控的Redis数据节点较多,会造成Sentinel节点产生过多的网络连接,也会有一定的影响。 方案二:多套Sentinel,显然这种方案的优点和缺点和上面是相反的,每个Redis主节点都有自己的Sentinel节点集合,会造成资源浪费。但是优点也很明显,每套Redis Sentinel都是彼此隔离的。

API
Sentinel节点是一个特殊的Redis节点，它有自己专属的API。
1、sentinel master 展示所有被监控的主节点状态以及相关的统计信息
2、sentinel master 展示指定的主节点状态以及相关的统计信息
3、sentinel slaves 展示指定的从节点状态以及相关的统计信息
4、Sentinel sentinel 查看指定 上面哨兵相关的信息
5、Sentinel get-master-addr-by-name 返回指定 主节点的IP地址和端口
6、Sentinel reset 当前sentinel节点对符合（通配符风格）主节点的配置进行重置，包括清除主节点的相关状态（例如故障转移），重新发现从节点和sentinel节点。
7、Sentinel failover 对指定进行强制故障转移（没有和其他sentinel节点协商），当故障转移完成之后，其他的sentinel节点按照故障转移的结果更新自身配置。
8、Sentinel ckquorum 检测当前主节点的哨兵是否到达quorum的个数，Ckquorum 填写个数和quorum对比
9、Sentinel flushconfig 将sentinel节点的配置信息强制写道磁盘上
10、Sentinel remove 取消当前sentinel节点对于指定主节点的监控

安装部署：