Redis哨兵机制原理浅析

　　一、前言
　　上一篇文章Redis主从复制原理中简要地说明了主从复制的一个基本原理，包含全量复制、复制积压缓冲区与增量复制等内容，有兴趣的同学可以先看下。
　　利用主从复制，可以实现读写分离、数据备份等功能。但如果主库宕机后，需要运维人员手动地将一个从库提升为新主库，并将其他从库slaveof新主库，以此来实现故障恢复。
　　因此，   主从模式的一个缺点，就在于无法实现自动化地故障恢复   。Redis后来引入了哨兵机制，哨兵机制大大提升了系统的高可用性。  二、什么是哨兵
　　哨兵，就是站岗放哨的，时刻监控周围的一举一动，在第一时间发现敌情并发出及时的警报。
　　Redis中的哨兵（Sentinel），   则是一个特殊的Redis实例   ，不过它并不存储数据。也就是说，哨兵在启动时，不会去加载RDB文件。
　　关于Redis的持久化，可以参考我的另外一篇文章 谈谈Redis的持久化——AOF日志与RDB快照
　　上图就是一个典型的哨兵架构，由数据节点与哨兵节点构成，通常会部署多个哨兵节点。
　　哨兵主要具有三个作用，   监控、选主与通知   。
　　监控：哨兵会利用心跳机制，周期性不断地检测主库与从库的存活性
　　选主：哨兵检测到主库宕机后，选择一个从库将之切换为新主库
　　通知：哨兵会将新主库的地址通知到所有从库，使得所有从库与旧主库slaveof新主库，也会将新主库的地址通知到客户端上
　　我会在下文详细讲一下监控与选主的过程  三、监控
　　哨兵系统是通过3个定时任务，来完成对主库、从库与哨兵之间的探活。  哨兵如何拿到从库地址
　　首先我们会在配置文件中配置主库地址，这样哨兵在启动后，会以   每隔10秒   的频率向主库发送info命令，从而获得当前的主从拓扑关系，这样就拿到了所有从库的地址。  哨兵如何感知到其他哨兵的存在
　　接着   每隔2秒   ，会使用pub/sub（发布订阅）机制，在主库上的_sentinel_:hello的频道上发布消息，消息内容包括哨兵自己的ip、port、runid与主库的配置。
　　每个哨兵都会订阅该频道，在该频道上发布与消费消息，从而实现哨兵之间的互相感知。  哨兵是如何实现对节点的监控
　　利用启动配置与info命令可以获取到主从库地址，利用发布订阅可以感知到其余的哨兵节点。
　　在此基础上，哨兵会   每隔1秒   向主库、从库与其他哨兵节点发送PING命令，因此来进行互相探活。  主观下线与客观下线
　　当某个哨兵在   down-after-milliseconds（默认是30秒）   配置的连续时间内，仍然没有收到主库的正确响应，则当前哨兵会认为主库   主观下线   ，并将其标记为sdown（subjective down）
　　为了避免当前哨兵对主库的误判，因此这个时候还需要参考其他哨兵的意见。
　　接着当前哨兵会向其他哨兵发送   sentinel is-master-down-by-addr   命令， 如果有半数以上（由quorum参数决定）的哨兵认为主库确实处于主观下线状态，则当前哨兵认为主库客观下线 ，标记为odown（objective down）  四、选主
　　一旦某个主库被认定为客观下线时，这个时候需要进行哨兵选举，选举出一个领导者哨兵，来完成主从切换的过程。  哨兵选举
　　哨兵A在向其他哨兵发送   sentinel is-master-down-by-addr   命令时，同时要求其他哨兵同意将其设置为Leader，也就是想获得其他哨兵的投票。
　　在每一轮选举中，每个哨兵仅有一票。投票遵循先来先到的原则，如果某个哨兵没有投给别人，就会投给哨兵A。
　　首先获得半数以上投票的哨兵，将被选举称为Leader。
　　这里的哨兵选举，采用的是Raft算法。这里不对Raft做详细的探讨，有兴趣的同学，可以参考我的另外一篇文章 22张图，带你入门分布式一致性算法Raft
　　该文章采用大量的图例，相信你可以从中学习到全新的知识，从而打开分布式一致性算法的大门，大伙们记得等我搞完Paxos与Zab。
　　过半投票机制也常用于很多算法中，例如RedLock，在半数以上的节点上加锁成功，才代表申请到了分布式锁，具体可参考这篇文章的最后 我用了上万字，走了一遍Redis实现分布式锁的坎坷之路，从单机到主从再到多实例，原来会发生这么多的问题
　　在Zookeeper选举中，同样也用到了过半投票机制，在这篇文章中 面试官：能给我画个Zookeeper选举的图吗？ 我从源码角度分析了Zookeeper选举的过程。  故障恢复
　　在选举到领导者哨兵后，将由该哨兵完成故障恢复工作。
　　故障恢复分为以下两步：  首先需要在各个从库中，选出一个健康的且数据最新的从库出来。  将该从库提升为新主库，即执行slaveof no one，其他从节点slaveof新主库。
　　详细说一下第一步，挑选是有条件的。首先要过滤出不健康的节点，再按某种规则排序，最后取第一个从库，我们直接从源码入手：  sentinelRedisInstance *sentinelSelectSlave(sentinelRedisInstance *master) {     sentinelRedisInstance **instance =         zmalloc(sizeof(instance[0])*dictSize(master->slaves));     sentinelRedisInstance *selected = NULL;     int instances = 0;     mstime_t max_master_down_time = 0;      if (master->flags & SRI_S_DOWN)         max_master_down_time += mstime() - master->s_down_since_time;     max_master_down_time += master->down_after_period * 10;      di = dictGetIterator(master->slaves);     while((de = dictNext(di)) != NULL) {         sentinelRedisInstance *slave = dictGetVal(de);         mstime_t info_validity_time;         //处于主观下线与客观下线的状态         if (slave->flags & (SRI_S_DOWN|SRI_O_DOWN)) continue;         //断开连接         if (slave->link->disconnected) continue;         //5秒内没有回应哨兵的ping命令         if (mstime() - slave->link->last_avail_time > SENTINEL_PING_PERIOD*5) continue;         //优先级为0         if (slave->slave_priority == 0) continue;         //没在3秒或5秒（依据主库状态）内完成对info命令的回应         if (mstime() - slave->info_refresh > info_validity_time) continue;         //与主库的断开时间，超过max_master_down_time         if (slave->master_link_down_time > max_master_down_time) continue;         //健康的节点加入到instance数组中         instance[instances++] = slave;     }     //按照某种规则进行快速排序     qsort(instance,instances,sizeof(sentinelRedisInstance*),compareSlavesForPromotion);     //选取第一个     selected = instance[0];     return selected; }  int compareSlavesForPromotion(const void *a, const void *b) {     sentinelRedisInstance **sa = (sentinelRedisInstance **)a,                           **sb = (sentinelRedisInstance **)b;     char *sa_runid, *sb_runid;     //首先比较优先级，谁的优先级越小（除了0），就选谁     if ((*sa)->slave_priority != (*sb)->slave_priority)         return (*sa)->slave_priority - (*sb)->slave_priority;     //当优先级一样时，比较复制偏移量。谁的偏移量大，就选谁     if ((*sa)->slave_repl_offset > (*sb)->slave_repl_offset) {         return -1; /* a < b */     } else if ((*sa)->slave_repl_offset < (*sb)->slave_repl_offset) {         return 1; /* a > b */     }     //优先级与复制偏移量一致时，比较runid     sa_runid = (*sa)->runid;     sb_runid = (*sb)->runid;     //低版本的Redis，在info命令中不存在runid，因此可能为null     //为null的runid，认为它比任何runid都大     if (sa_runid == NULL && sb_runid == NULL) return 0;     else if (sa_runid == NULL) return 1;  /* a > b */     else if (sb_runid == NULL) return -1; /* a < b */     //按照字母顺序排序，谁靠前，则选谁     return strcasecmp(sa_runid, sb_runid); }
　　因此，以下从库会被过滤出：  主观下线、客观下线或断线  没在5秒内完成对哨兵ping命令的回应  priority=0  没在3秒或5秒内（由主库状态决定）内完成对info命令的回应  与主库的断开时间，超过max_master_down_time
　　剩下的节点，就是健康的节点，此时再执行一次快速排序，排序的规则如下：  比较优先级（priority），谁的优先级越小（除了0），就选谁  比较复制偏移量。谁的偏移量大，就选谁  比较runid，按照字母顺序排序。谁靠前，则选谁  五、总结
　　本文算是Redis哨兵的一个入门文章，主要讲了哨兵的作用，例如监控、选主和通知。
　　在Redis读写分离的情况下，使用哨兵可以很轻松地做到故障恢复，提升了整体的可用性。
　　但哨兵无法解决Redis单机写的瓶颈，这就需要引入集群模式，相应的文章也被列为明年的写作计划中。