一、概述
Redis的一主多从的主从复制集群模式无法实现集群的高可用特性（主节点宕机会导致整个集群不可用）。为了解决这一个问题，Redis提出了哨兵模式。
二、哨兵模式
Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。
2.1 哨兵的作用
- 监控：Sentinel会不断检查master和slave是否按预期工作。
- 自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新master为主。
- 通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。
2.2 服务状态监控
Sentinel基于心跳机制监测服务状态，每隔1秒向集群的每个实例发送pin命令：
- 主观下线：如果某Sentinel节点发现某实例未在规定时间响应，则认为该实例主观下线。
- 客观下线：若超过指定数量（quorum）的Sentinel都认为该实例主观下线，则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。quorum可以在redis.conf文件中配置。
2.2 自动故障恢复
哨兵选主规则
- 首选判断主节点与从节点断开连接时间的长短，如超过指定值就排除该从节点。
- 然后判断从节点的slave-priority值，越小优先级越高。
- 如果slave-priority一样，则判断slave节点的offset值，越大优先级越高。
- 最后是判断slave节点的运行ID大小，越小优先级越高。
三、脑裂问题
3.1 脑裂问题是怎么产生的？
集群脑裂是由于主节点和从节点和Sentinel处于不同的网络分区，使得Sentinel没有心跳感知到主节点，所以通过选举的方式提升了一个从节点为主，这样就存在了两个master，就像大脑分裂了一样。
3.2 脑裂问题产生了什么影响？
脑裂导致客户端还在老的主节点那里写入数据，新节点无法同步数据，当网络恢复后，Sentinel会将老的主节点降为从节点，这时老的master实例会清空原数据，再从新master同步数据，导致数据丢失。
3.3 脑裂问题应该如何解决？
redis中有两个配置参数，通过这两个参数来解决脑裂问题。
- min-replicas-to-write 1 表示最少的slave节点为1个
- min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5s
如果达不到配置的要求，则拒绝请求，可以避免大量的数据丢失。
