1. 是什么一
1.1 吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务
1.2 作用
俗称，无人值守运维
哨兵的作用：
1、监控redis运行状态，包括master和slave
2、当master down机，能自动将slave切换成新master
1.3 官网理论, https://redis.io/docs/manual/sentinel
2. 能干嘛
2.1 主从监控 , 监控主从redis库运行是否正常
2.2 消息通知 , 哨兵可以将故障转移的结果发送给客户端
2.3 故障转移 , 如果Master异常，则会进行主从切换将其中一个slave作为新Master
2.4 配置中心 , 客户端通过连接哨兵来获得当前Redis服务的主节点地址址
3. 怎么玩(案例演示实战步骤)
3.1 Redis Sentinel架构，提前说明
3.1.1 3个哨兵 自动监控和维护集群不存放数据，只是吹哨人
3.1.2 1主2从 用于数据读取和存放
3.2 案例步骤, 不服就干
3.2.1 /myredis目录下新建或者拷贝sentinel.conf文件，名字绝不能错
3.2.2 先看看/opt目录下默认的sentinel.conf文件的内容
3.2.3 重点参数项说明
1. bind 服务监听地址，用于客户端连接，默认本机地址
2. daemonize 是否以后台daemon方式运行
3. protected-mode 安全保护模式
4. port 端口5. logfile 日志文件路径
6. pidfilepid 文件路径
7. dir 工作目录8. sentinel monitor <master-name> <ip> <redis-port> <quorum>
~ 设置要监控的master服务器
~ quorum表示最少有几个哨兵认可客观下线同意故障迁移的法定票数。行尾最后的quorum代表什么意思呢？quorum：确认客观下线的最少的哨兵数量
我们知道，网络是不可靠的，有时候一个sentinel会因为网络堵塞而误以为一个master redis已经死掉了，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
9. sentinel auth-pass <master-name> <password>master设置了密码，连接master服务的密码
10. 其它
sentinel down-after-milliseconds <master-name> <milliseconds>：
指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
sentinel parallel-syncs <master-name> <nums>：
表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
sentinel failover-timeout <master-name> <milliseconds>：
故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
sentinel notification-script <master-name> <script-path> ：
配置当某一事件发生时所需要执行的脚本
sentinel client-reconfig-script <master-name> <script-path>：
客户端重新配置主节点参数脚本
3.2.4 本次案例哨兵sentinel文件通用配置
1. 由于机器硬件关系，我们的3个哨兵都同时配置进192.168.111.169同一台机器
2. sentinel26379.conf
bind 0.0.0.0
daemonize yesprotected-mode noport 26379logfile "/myredis/sentinel26379.log"pidfile /var/run/redis-sentinel26379.piddir /myredissentinel monitor mymaster 192.168.111.169 6379 2sentinel auth-pass mymaster 111111
3. sentinel26380.confbind 0.0.0.0
daemonize yesprotected-mode noport 26380logfile "/myredis/sentinel26380.log"pidfile /var/run/redis-sentinel26380.piddir "/myredis"sentinel monitor mymaster 192.168.111.169 6379 2sentinel auth-pass mymaster 111111
4. sentinel26381.confbind 0.0.0.0
daemonize yesprotected-mode noport 26381logfile "/myredis/sentinel26381.log"pidfile /var/run/redis-sentinel26381.piddir "/myredis"sentinel monitor mymaster 192.168.111.169 6379 2sentinel auth-pass mymaster 111111
5. 请看一眼sentinel26379.confsentinel26380.conf、 sentinel26381.conf我们自己填写的内容
6. master主机配置文件说明
3.2.5 先启动一主二从3个redis实例，测试正常的主从复制
1. 架构说明
2. 请看一眼redis6379.conf、 redis6380.conf、 redis6381.conf我们自己填写主从复制相关内容
主机 63796379后续可能会变成从机，需要设置访问新主机的密码， 请设置masterauth项访问密码为111111，
不然后续可能报错master_link_status:down
6380
6381
3. 3台不同的虚拟机实例，启动三部真实机器实例并连接4. 具体查看当堂动手案例配置并观察文件内容
3.2.6 三以下是哨兵内容部分
3.2.7 再启动3个哨兵，完成监控
1. redis-sentinel sentinel26379.conf --sentine
2. redis-sentinel sentinel26380.conf --sentine
3. redis-sentinel sentinel26381.conf --sentinel
3.2.8 启动3个哨兵监控后再测试一次主从复制， 岁月静好一切OK
3.2.9 原有的master挂了对比配置文件
1. 我们自己手动关闭6379服务器，模拟master挂了
2. 问题思考
~ 两台从机数据是否OK~ 是否会从剩下的2台机器上选出新的master
~ 之前down机的master机器重启回来谁将会是新老大? 会不会双master冲突?
3. 揭晓答案
~ 数据OK
两个小问题
6380
6381
了解 Broken Pipe
~ 投票新选
sentinel26379.log
sentinel26380.log
sentinel26381.log
~ 谁是master，限本次案例
6381被选为新master，上位成功
以前的6379从master降级变成了slave
6380还是slave，只不过换了个新老大6381(6379变6381)，6380还是slave
3.2.10 对比配置文件
1. vim sentinel26379.conf
2. 老master，vim redis6379.conf3. 新master，vim redis6381.conf
4. 结论~ 文件的内容，在运行期间会被sentinel动态进行更改
~ Master-Slave切换后，master redis.conf、slave redis.con和sentinel.con的内容都会发生改变即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换
3.3 其它备注
1. 生产都是不同机房不同服务器，很少出现3个哨兵全挂掉的情况
2. 可以同时监控多个master，一行一个
4. 哨兵运行流程和选举原理
4.1 当一个主从配置中的master失效之后，sentinel可以选举出一个新的master用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
4.2 运行流程，故障切换
4.2.1 三个哨兵监控一主二从，正常运行中....
4.2.2 SDown主观下线(Subjectively Down)
1. SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。
2. sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
3. 说明所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息， 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了，o(╥﹏╥)o
sentinel down-after-milliseconds <masterName> <timeout>
表示master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据
master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。
4.2.3 ODown客观下线(Objectively Down)
1. ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经岩掉
2. 说明四个参数含义：
masterName是对某个master+slave组合的一个区分标识(一套sentinel可以监听多组master+slave这样的组合)
quorum这个参数是进行客观下线的一个依据，法定人数/法定票数
意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
4.2.4 选举出领导者哨兵(哨兵中选出兵王)
1. 当主节点被判断客观下线以后，各个哨兵节点会进行协商先选举出一个领导者哨兵节点 (兵王) 并由该领导者节点也即被选举出的兵王进行failover (故障迁移)
sentinel26379.log
sentinel26380.log
sentinel26381.log
2. 哨兵领导者，兵王如何选出来的? Raft算法
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：
即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意成为领导者
4.2.5 由兵王开始推动故障切换流程并选出一个新master
1. 3步骤
~ 新主登基
1) 某个Slave被选中成为新Master
2) 选出新master的规则，剩余slave节点健康前提下
redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )
复制偏移位置offset最大的从节点
最小Run ID的从节点 字典顺序，ASCII码
~ 群臣俯首
1) 一朝天子一朝臣，换个码头重新拜
2) 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点3) Sentinelleader会对选举出的新master执行slaveof no one操作，将其提升为master节点
4) Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave
~ 旧主拜服
1) 老master回来也认怂
2) 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点3) Sentinel leader会让原来的master降级为slave并恢复正常工作
2. 小总结
上述的failover操作均由sentinel自己独自完成，完全无需人工干预
5. 哨兵使用建议
哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
哨兵节点的数量应该是奇数
各个哨兵节点的配置应一致
如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射哨兵集群+主从复制，并不能保证数据零丢失
承上启下引出集群
