Redis哨兵（Sentinel）
Redis Sentinel，在Redis2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。
哨兵的作用
- 监控（Monitoring）：Sentinel会不断检查主节点和从节点是否按预期工作。
- 通知（Notification）：Sentinel可以通过API向系统管理员或其他计算机程序通知其监控的Redis实例出现的问题。
- 自动故障转移（Automatic failover）：如果主节点无法按预期工作，Sentinel会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，重新配置其他从节点使用新主节点，并通知使用Redis服务的应用程序要使用的新地址。
- 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。
监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。
哨兵的运行流程和原理
当一个主从配置中的Matser的失效之后，Sentinel可以选举出一个新的Master用于自动接替原本Master的工作，主从配置中的其他Redis服务器自动指向新的Master同步数据。
一般建议Sentinel使用奇数个，这样防止某一台Sentinel无法连接到Master导致切换错误。
哨兵监控Redis库
哨兵通过向主库发送INFO命令，然后主库将从库列表返回给哨兵。哨兵就能根据这些从库信息和从库建立连接，并在这个连接上持续地对从库进行监控。其他哨兵有也是用同样的方法和从库建立连接。
主库下线
首先这里主库下线分为两个概念SDown主观下线（Subjectively Down）和ODwon客观下线（Objectively Down）。
-
所谓主观下线指的就是单个Sentinel实例对服务器做出的下线判断，即单个Sentinel认为某个服务下线（有可能是接收不到订阅消息、网络不通等原因）。主观下线就是如果服务器在配置的（
down-after-milliseconds）时间之内没有回应或者返回错误消息，那么这个Sentinel就会单方面的认为这个服务不可用了。 -
quorum这个参数就是进行客观下线的依据，也就是至少要有quorum个Sentinel认为这个Master有故障才会对这个Master进行下线以及故障转移。因为有的时候，某个Sentinel节点可能因为自己的网络原因导致无法连接Master（但是实际这个Master并没有出现问题），所以就需要多个Sentinel都一致认为该Master有问题，才能继续下一步操作。从而保证了公平性和高可用。当某个哨兵判断主库“主观下线”后，就会给其他哨兵发送
is-master-down-by-addr命令。接着，其他哨兵会根据自己和主库的连接情况，做出 Y 或 N 的响应，Y 相当于赞成票，N 相当于反对票。
选举出领导者哨兵
当判断出出库下线后，需要一个哨兵进行故障转移，于是哨兵内部会进行选举，选举出一个领导者哨兵来做故障转移。
哨兵的选举机制
哨兵的选举机制就是一个Raft选举算法：选举的票数大于等于num(sentinels)/2+1时，将成为领导者，如果没有超过，继续选举。
Raft算法的基本思路是先到先得，即在一轮选举中，哨兵A向B发送成为领导者的申请，如果在之前B没有同意过其他哨兵的申请，那么就会同意A的申请。
成为领导者的哨兵，要满足两个条件：
-
拿到半数以上的赞成票。
-
拿到的票数同时还需要大于等于哨兵配置文件中的quorum值。
以3个哨兵为例，假设此时的
quorum设置为2，那么只需要拿到两张赞成票就可以成为领导者哨兵。
选举出新的Mater
- 首先过滤掉不健康的（下线或断线），没有回复过哨兵ping响应的从节点。
- redis.conf配置文件中
salve-priority（replica-priority）从节点优先级最高的（数字越小优先级越高）。 - 选择复制偏移量最大的。
- 选择Run ID最小的。
重新排列主从
- 哨兵领导者首先对选举出来的新Master执行
slaveof no one命令 ，时期成为新的Master。 - 哨兵领导者向其他Slave发送命令，让剩下的其他Slave节点成为新的Master节点的Slave。
- 当之前下线的Master重新启动之后，哨兵领导者会让原来的Master降级为Slave并恢复正常。
哨兵使用建议
- 哨兵节点的数量应该是多个，哨兵本身应该是集群部署，保证高可用。
- 哨兵节点的数量应该是奇数。
- 每个哨兵的配置应该保持一致。
- 哨兵集群加上主从复制实际并不能保证数据的完全不丢失。