redis哨兵

在主从复制模式下， 一旦主节点宕机， 需要人工干预进行故障转移， 给应用方和运维带来了使用的不便。 引入哨兵， 主节点故障后，重新选举新的主节点， 实现了风险转移。

9.1 基本概念

redis数据节点： 主节点和从节点
sentinel节点： 用来监控redis数据节点
sentinel节点集合：若干 sentinel 节点组成的抽象组合

1 sentinel的架构

sentinel架构和主从复制的区别是， sentinel是在主从复制的基础上引入了sentinel节点集合，对主从节点进行监控，当发现主节点宕机后， 会重新从子节点中选举一个新主节点， 其余从节点都转连接新的主节点。具体步骤如下：

1） sentinel节点集合对主从节点进行监控；
2） 当所有sentinel节点都监控到master节点宕机了，或者失去联系了， 会内部选举一个sentinel领导者，
由这个sentinel领导者去进行自动故障转移；
3）自动故障转移的步骤为， 先断掉所有从节点和master节点的连接， 重新选举一个从节点作为新的主节点，其余从节点都转连新主节点。

2 sentinel的功能

1）监控
sentinel节点集合会监控主从节点和其余sentinel节点

2）故障转移
sentinel识别到主节点不可用后，会重新选举新的主节点

3）通知
sentinel会把故障转移的情况通知给应用方

4）配置提供者
客户端连接的是redis sentinel节点集合，这样的好处有2点，如下：
a 通过sentinel节点结合来获取主节点，防止误判；
b sentinel有多个节点，防止某个节点出现故障， 保证其余sentinel节点仍然可用。

9.2 部署

1 部署结构：一主两从三哨兵模式

2 sentinel常用配置

1）sentinel monitor {myMasterName} {ip}{port} {quorom} 监控主节点
{myMasterName} 表示主节点的别名；
{ip}{port} 表示主节点的ip和端口号；
{quorom} 表示至少几个sentinel节点同意主节点不可用则认为主节点故障；

2）sentinel down-after-milliseconds {myMasterName}{senconds} 监控任意节点超时的时间设置，单位毫秒
{myMasterName} 表示主节点的别名， 也可以是其他从节点或者sentinel节点；
sentinel节点会定期的发送ping命令去监控主从节点或者sentinel节点是否可用，如果时间超过了down-after-milliseconds配置，则认为节点不可用；

3）sentinel parallel-syncs 选举新节点后，同一时间从节点复制的个数

4）sentinel failover-timeout {myMasterName} {senconds} 故障转移超时时间
故障转移的四个阶段：
a 所有从节点断掉与主节点的联系；
b 新选举出的从节点设置为主节点；
c 其余从节点从主节点进行数据同步；
d 旧的主节点重启后与新主节点建立复制关系，进行数据同步

sentinel对一个主节点故障转移失败， 那么下次在对这个主节点进行故障转移的起始时间为failover-timeout的2倍

3 sentinel部署技巧

1）sentinel 节点不要部署在同一台物理机上
如果同一台物理机出现故障， 所有的sentinel节点都会受到影响， 为了实现真正的高可用， 需要把sentinel节点部署在不同物理机上。

2）sentinel 部署的个数至少3个且是奇数个节点
因为sentinel领导者的选举至少一半加1个节点通过才可以

3）每个主节点建议只用独立的一套sentinel 节点群
实现资源的隔离， 避免与其他主节点复用同一套 sentinel 节点， 出现故障时， 影响范围较大。

9.3 客户端

1 redis sentinel 客户端实现基本原理

1）客户端遍历sentinel集合，获取一个可用的sentinel节点， 因为所有的sentinel节点会共享数据；
2）客户端调用 get-master-addr-by-name API命令来获取主节点的信息， 需要用mastername来查询
对应主节点，避免同一套sentinel节点监控了多个主节点；
3）客户端配置的mastername与步骤2获取的主节点比较， 验证获取的是否真正的主节点；
4）sentinel集合重新选举新的主节点后， 会通知客户端更新本地的mastername;

通过客户端和sentinel交互原理图可知， 总结：
1）客户端和sentinel节点交互的时间点为客户端初始化、主节点信息发生变化通知客户端；
2）客户端需要维护mastername和sentinel节点集合两个参数，就可以与sentinel进行交互。

2 java 操作 redis sentinel

1） 使用jedisSentinelPool与sentinel建立连接

jedisSentinelPool最全的构造方法如下：

常用的构造方法为：

JedisSentinelPool jedisSentinelPool= new JedisSentinelPool(masterName,sentinels,poolConfig,connectTimeout);

9.4 实现原理

1 sentinel 的三个定时监控任务

1）每隔1s sentinel会向主节点、从节点、其他sentinel节点发送ping 命令，以检测各个节点是否
可达。 通过此定时任务，sentinel与各个节点建立起了监控和连接，这个定时任务是判断各个节点
是否不可用的最重要的指标。

2）每隔2s sentinel会向master节点的 sentinel:hello 频道上，发布自身的节点信息和对主节点的判断，
同时也可以对该频道进行订阅；

作用：
a 可以获取同一频道上其他 sentinel节点， 如果有新增的sentinel 节点，可以及时的发现并保存起来，与之建立连接；
b 分享对主节点的判断，以便sentinel领导者的选举和对主节点客观下线。

3） 每隔10s sentinel节点会向主节点、从节点发送info 命令，获取最新的拓扑结构
作用：
通过向主节点发送info 命令，可以获取最新从节点的情况，判断是否有新加的从节点或者不可用的从节点

2 主观下线和客户下线

1）主观下线
当sentinel 每秒的定时任务执行时， 会向主节点、从节点、其余sentinel节点发送ping命令， 当ping用时超过 down-after-senconds配置时，会认为节点不可达。 如果ping的节点是主节点， 则sentinel主观上认为主节点下线， 这种主观的判断有时候会误判。
(sentinel 每秒执行的定时任务来完成的)

2）客观下线
当sentinel 识别主节点主观下线时， 会向其余sentinel 节点发送命令一起判断主节点是否不可达，如果认为主节点不可达的数量达到了quonum， 则主节点客观下线， sentinel 节点会选举出领导者， 进行故障转移。（sentinel 节点共同判断主节点是否下线是用sentinel每2秒执行的定时任务来完成的）

9.5 读写分离架构

通过维护slave节点资源池， 从节点添加或者删除时及时同步维护好slave资源池， 这样客户端获取slave节点读操作时，只需要从slave资源池获取一个可用的slave节点即可。