Redis哨兵

定义

吹哨人巡查监控后台master主机是否故障，如果故障自动根据投票数自动将某一个从库转成成新主库，继续对外服务。

作用

主从监控：监控主从redis库运行是否正常
消息通知：哨兵可以将故障转移的结果发送给客户端
故障转移：如果Master异常，则会进行主从切换，将其中一个Slave作为新Master
配置中心：客户端通过连接哨兵来获得当前redis服务的主节点地址

使用演示

Redis Sentinel架构

3个哨兵：自动监控和维护集群，不存放数据，只是吹哨人。
一主二从：用于数据读取和存放。

案例步骤

redis目录下新建或者拷贝sentinel.conf文件，名字不能错。
重点参数说明：

首先我们知道网络是不可靠的，有时候一个sentinel会因为网络堵塞误以为一个master redis死了，这时候我们要依赖客观下限作为依据，就是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移、
三台哨兵的配置：

先配置一主二从：

主机6379后续可能会变成从机，需要设置访问新主机的密码，请设置masterauth项
先启动一主二从，在启动哨兵监控
启动监控的命令:
redis-sentinel sentinel26379.conf --sentinel
我们自己手动关闭6379服务器，模拟master挂了

• 两个从机数据是否ok？
  数据ok

• 是否会从剩下的2台机器上选出新的master？

• 之前down机的master机器重启回来，谁会成为新主机？

broken pipe：通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时，会发生数据突然中断，即broken。对于socket来说，可能是网络被拔出或另一端的进程崩溃。
这个broken pipe异常是客户端读取超时关闭了连接，这时服务器端再向客户端已经断开的数据写数据时就发生了这个异常。

6379.conf和6380.conf文件内容在运行期间会被sentinel动态进行改变
Master-Slave切换后，master_redis,conf，slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf会多一行slaveof的配置，sentinel.conf的监控目标会随之调换。
注意：
哨兵可以同时监控多个master，一行一个。
生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况。

运行流程和原理

主观下线（SDown）：
单个sentinel自己主观上检测到的关于master的状态，从哨兵角度如果发送PING心跳后，在一定时间内没有回应PING命令或返回一个错误消息，那么这个哨兵会主观的认为这个master不可用了。

客观下线（oDown）：
需要一定数量哨兵的sentinel，多个哨兵达成一致意见才能认为一个master客观已经宕掉。
quorum这个参数是进行客观下线的一个依据。

选出领导者哨兵：
当主节点被判断客观下线后，各个哨兵节点会协商选举出一个领导者哨兵节点也就是兵王并由兵王进行故障转移，下图是哨兵日志：

兵王是怎么被选出来的：
Raft算法（先到先得）
比如在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。

兵王开始推动故障切换流程并选出一个新master步骤：
某个Slave被选中成为新Master
选出新的Master的规则，剩余slave节点健康前提下：
RunID就是字典排序，即ASCII码


无需人工干预

使用建议

哨兵节点数量应为多个，哨兵本身应该集群，保证高可用。
哨兵节点数量应为奇数。
各个哨兵节点的配置应一致。
哨兵+主从复制也不能保证数据零丢失。丢失宕机前未复制到新的主节点上的那部分数据。