redis的哨兵模式

上篇我们讲了主从同步。有一个问题无法解决，细想如果主节点宕机了，从节点升为主节点，这需要手工进行主从切换，程序也需要手动去修改节点地址。如果是大半夜发生，这就是一场严重的事故了。

针对这种场景咱们的Redis提供了一套高可用的方案，Redis sentinel。
Redis 的 Sentinel 可以用来管理多个 Redis 服务器，会执行以下四个任务：
1.监控
Sentinel 会不断的检查 主服务器 和 从服务器 是否正常运行。
2.通知
当被监控的某个 Redis 服务器出现问题，Sentinel 通过 API 脚本 向 管理员 或者 其他的 应用程序 发送通知。
3.自动故障转移
当 主节点 不能正常工作时，Sentinel 会开始一次 自动的 故障转移操作，它会将 与 失效主节点 是 主从关系 的其中一个 从节点 升级为新的 主节点，并且将其 他的 从节点 指向 新的主节点。
4.配置提供者
在 Redis Sentinel 模式下，客户端应用 在初始化时连接的是 Sentinel 节点集合， 从中获取 主节点 的信息。

网络波动无法避免，主节点有时候会突然出现问题，过一伙又会自动好起来而不是真的挂掉。为此进行故障转移就得不偿失了。就此我们引入两个概念，主观下线和客观下线。

主观下线和客观下线
默认情况下，每个 Sentinel 节点会以 每秒一次 的频率对 Redis 节点和 其它 的 Sentinel 节点发送 PING 命令，并通过节点的 回复 来判断节点是否在线。
主观下线 适用于所有 主节点 和 从节点。如果在 down-after-milliseconds 毫秒内，Sentinel 没有收到 目标节点 的有效回复，则会判定 该节点 为 主观下线。
客观下线 只适用于 主节点。如果 主节点 出现故障，Sentinel 节点会通过 sentinel is-master-down-by-addr 命令，向其它 Sentinel 节点询问对该节点的 状态判断。如果超过 个数的节点判定 主节点 不可达，则该 Sentinel 节点会判断 主节点 为 客观下线。

工作原理：

1. 每个Sentinel以每秒钟一次的频率，向它所知的主服务器、从服务器以及其他Sentinel实例发送一个PING 命令 。
2. 如果一个实例（instance）距离最后一次有效回复PING命令的时间超过down-after-milliseconds所指定的值，那么这个实例会被 Sentinel 标记为主观下线。
3. 如果一个主服务器被标记为主观下线，那么正在监视这个主服务器的所有Sentinel节点，要以每秒一次的频率确认主服务器的确进入了主观下线 状态。
4. 如果一个主服务器被标记为主观下线，并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断，那么这个主服务器被标记为客观下线。
5. 在一般情况下，每个Sentinel会以每10秒一次的频率，向它已知的所有主服务器和从服务器 发送INFO命令。当一个 主服务器被Sentinel标记为客观下线时，Sentinel向下线主服务器 的所有 从服务器发送 INFO 命令的频率，会从 10 秒一次改为每秒一次。
6. Sentinel和其他Sentinel协商主节点的状态，如果主节点处于SDOWN状态，则投票自动选出新的主节点。将剩余的从节点指向新的主节点进行数据复制。
7. 当没有足够数量的Sentinel 同意主服务器下线时，主服务器的客观下线状态就会被移除。当主服务器重新向Sentinel的PING命令返回有效回复时，主服务器的主观下线状态就会被移除。

哨兵机制也是有缺点的：
　　1.主从服务器的数据要经常进行主从复制，这样造成性能下降。
　　2.当主服务器宕机后，从服务器切换成主服务器的那段时间，服务是不能用的。

题外话：至此我们redis系列暂告一段落（断断续续的写了一个多月，忍不住全发了哈哈哈）。本系列主要是给大家呈现一个较为完整的redis内容，以及常见的redis问题和解决思路。希望大家看完能打开redis的大门，对redis并不陌生了。