哨兵
1、哨兵简介
1.1、主机宕机
在开启主从复制后，master宕机了，哪个slave来代替master，需要做哪些事情?
- 关闭master和所有slave
- 找一个slave作为master
- 修改其他slave的配置，连接新的master
- 启动新的master与slave
- 全量复制* N+部分复制* N
上面步骤存在的问题：
- 谁来确认master宕机了？
- 关闭期间的数据服务谁来承接？
- 找一个主？怎么找法？
- 修改配置后，原始的主恢复了怎么办？
谁来负责上面这些事情？哨兵！（可以看成是一双眼睛盯着它们干活！）
1.2、哨兵
哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。
1.3、哨兵的作用
1、监控：
- 不断的检查master和slave是否正常运行；
- master存活检测、master与slave运行情况检测。
2、通知（提醒）
- 当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。
3、自动故障转移
- 断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址。
注意：
- 哨兵也是一台redis服务器，只是不提供数据服务；
- 通常哨兵配置数量为单数（双数投票竞选会出现打平）
2、哨兵模式搭建
- 配置一拖二的主从结构
- 配置三个哨兵（配置相同，端口不同） 参看sentinel.conf
- 启动哨兵
redis-sentinel sentinel-端口号.conf
port： 哨兵本身也是一个服务，对外也是有一个端口的！
dir： 对应的哨兵的工作信息存储在这个文件夹中
sentinel monitor mymaster 127.0.0.1 6379 2 ：表示哨兵监控的服务器，2表示有两个哨兵认为这个服务器挂了！（mymaster是主服务器master）
sentinel sentinel down-after-milliseconds mymaster 30000：表示主master服务器mymaster连接30s不响应，哨兵就认为你这个服务器挂了！sentinel parallel-syncs mymaster 1： mymaster挂掉后，将 slave 中的某个节点中提升为 master 后，剩余节点立即重连新 master 的数量，进行数据同步！（数值越大，要求网络资源越高，要求约小，同步时间约长）sentinel failover-timeout mymaster 9000：在进行同步时，太慢也不能接收，这个值表示多长时间同步完成是有效的！没有完成超过时间就无效了。
将上面的配置复制一下并移动下位置：
将哨兵工作信息的存储位置修改下：
再复制修改另外两个哨兵配置文件：
再看看master和salve1、slave2：
我们再创建一个6381也就是slave2：
清除其他文件，现在conf文件夹只剩下这6个配置文件：
将data文件夹中也清空：
下面我们就可以测试哨兵了！
先启动主机master，再启动从机slave1、slave2，最后启哨兵！
1、启动master：
2、启动slave1和slave2：
slave1:
slave2：
哨兵1：
可以看到master和slave的信息；可以使用客户端连接哨兵1的服务器：（注意更换端口为哨兵所在的端口）
get和set是不允许的，只能执行哨兵的指令！输入info：
可以看到sentinel = 1，表示只用1个哨兵！再次查看下哨兵1的配置文件：
加入了id和一些主从的信息！（可以知道，一旦启动哨兵，主从信息是会发生变化的！）
我们再启动第2个哨兵：
每启动一个新哨兵，哨兵之间是能相互识别的！可以看到在哨兵2中有哨兵1的id信息：
哨兵1的服务器上也有哨兵2的ID信息，哨兵之间相互识别：
我们此时再打开哨兵1的配置文件，可以看到配置文件中又加入了一个新的ID，就是哨兵2的ID信息：
我们再启动哨兵3：
可以看到哨兵3识别到了哨兵1和哨兵2！哨兵123都互相识别了！在哨兵1的配置文件中，又会增加哨兵2、3的ID信息：
检查主从复制是否运行正常：
OK的！
哨兵怎么操作？
当主master挂掉的时候，从slave会接手它的工作；
1、ctrl + c将主服务器停掉；
此时因为设置的响应时间30s，过了30s master不响应，哨兵就认为master挂掉了哨兵1上服务器上新的日志信息：
- 1、sdown：表示其中有一个人认为6379这个服务器下线了；
- 2、odown：所有哨兵都去看，然后都认为它下线了；
- 3、发起了一轮投票，来选择哪个slave服务器作为master；
- 4、推选出了6381为新的master；
- 5，6、将6381作为master，设置6379、6380为其slave；
- 7、sdown：将6379下线！
3、哨兵工作原理
哨兵主要做的事是 主从切换。
哨兵在进行主从切换过程中经历三个阶段：
- 监控
- 通知
- 故障转移
3.1、阶段一：监控阶段
哨兵 先连接 master，给master发送info，就可以获得master的信息，同时也可以获得slave中的信息；
根据上面获得的salve信息，再给slave发送info，获取slave详细信息！
上图中的过程：
1、获取master信息，当然也获得了slave的部分信息；
2、为了方便哨兵和master以及slave命令交换，建立了一个cmd连接！
还保存了所有的哨兵状态：
还保存了Redis实例的信息：
3、根据第2步中获取的slave信息，再取获取每个slave的详细信息！
4、又一个哨兵连接进来了，会建立cmd通道，获取master和slave的信息，
同时，自己保存的哨兵状态会更新为2个，会加上之前的那个哨兵信息：
5、各个哨兵之间会建立一个发布-订阅机制，用来同步各自获得的信息，且会互相ping，看看对方是否在线！
简单小结：
- 哨兵会向master、slave、以及其他哨兵 要状态；
- 哨兵之间会有一个发布-订阅通道，哨兵会在里面发布信息、订阅信息、收信息、同步信息！
3.2、阶段二：通知阶段
- 三个哨兵组成了一个群体，它们之间进行信息互通；
- master和slave之间正常干活；
- 哨兵会根据它们和master、slave之间建立的cmd连接获取master和slave状态信息！不管是哪个哨兵获取到，都会将信息回传，然后再哨兵之间共享信息！
3.3、阶段三：故障转移阶段
现在是出现故障了：
1、sentinel1给master发消息，master不理他，sentinel1不停的一直在发；
哨兵1就标记master已经断开连接了：
哨兵1会在哨兵组成的内网中通知master已经挂了！
其他哨兵接到通知后，自己也会尝试发送hello，看看到底有没有掉线！确认下哨兵1的消息对不对！
此时master的状态标记为O_DOWN，一个哨兵认为master下线称为S_DOWN（主观下线），只要超过半数的哨兵都认为下线，就记为O_DOWN（客观下线）！
确定master出错后，现在就要派哨兵去解决问题了，派谁去？
竞选投票机制，其他没参选的哨兵，先收到谁的竞选信息，就将票投给谁！
假如得到的票数是哨兵总数量的一半及以上，就是这个哨兵，没有的话继续投票！
这样就选取出来一个出来故障信息的哨兵了！
接下来，正式处理故障信息，也就是挑选slave作为master；
挑选salve作为master的原则：
- 在线的
- 响应快的（网络好）
- 与原master断开时间久的（也表示网络好，master一断开slave就知道了）
- 优先原则
- 优先级
- offset（越大，说明之前同步的效果好）
- runid（offset一样，就看runid谁小！）
接下来：
- 就是告诉新master你是master，不要再做任何服务器的slave了；
- 再向其他机器说明那个机器是master，让这些slave去连接master！
4、总结
1、监控
- 同步信息
2、通知
- 保持联通
3、故障转移
- 发现问题
- 竞选负责人（选出一个哨兵去处理故障）
- 优选新master
- 新master上任，其他slave切换master，原master作为slave故障回复后连接
重新启动6379这个服务器：
可以看到6379是以slave的身份连接上来了！
