今晚是除夕夜，我还在整理文档，真是位可爱又认真的小仙女呀。
之前我们学习了redis的主从复制，效果非常好，能够分担主服务器的压力，提高redis的整体吞吐量。（嗯，虽然“吞吐量”这个词可能不太恰当）
但是在这个过程中也存在一些问题，比如如果主节点突然挂了，该怎么办呢？
当然是需要人工干预啦。我们可以在其他从节点中手动选择一个新的主节点，然后让其他节点成为这个新主节点的从节点。
具体步骤如下：
1.启动从节点为主节点。命令为slaveof no one。
2.旧主节点的其他从节点变成新主节点的从节点。命令为slaveof new master。
3.通知应用方Redis主节点已经变更，修改客户端调用的地址并重启客户端。
4.当已经挂掉的主节点重新上线后，旧主节点变成新主节点的从节点。命令为slaveof new master。
请原谅我手机的画质，因为穷，没有其他原因啦。
但这都是人工操作的，大家都知道，程序员都很懒，能自动监控的，绝不自己动手。
所以接下来我们要学习Redis的哨兵，也就是自动切换，无需自己动手。
在windows上搭建哨兵
上次主从复制因为懒，没有写具体过程，这次得一次还清。所以哦，不要拖延，及时完成任务，不然拖到最后还是得自己干。
今天我们先下载Windows版本的Redis，再搭建主从复制（一主二从），最后搭建监控Redis的哨兵（三个，这里为什么要3个，后面会解释的，所以啊，我们不急，慢慢来，因为这是一块大骨头）。
1.下载Windows版本的Redis
因为Redis官方并不支持Windows，所以我们去gitHub下载，https://www.php.cn/link/ecd610837c2670b1acbe1d57821055b8
2.搭建主从复制（一主二从）
将redis.windows.conf重命名为redis6379.conf，然后复制两个分别为redis6380.conf，redis6381.conf。
redis6380的配置文件为：
port 6380 bind 127.0.0.1 slaveof 127.0.0.1 6379
redis6381的配置文件为：
port 6381 bind 127.0.0.1 slaveof 127.0.0.1 6379
这些配置文件的意思非常明确，如果不明白，可能得挨打了。
port为当前Redis的端口号。
bind为绑定的服务器。
slaveof为该从服务器跟随哪个主服务器及其端口号。
配置文件准备好后，就可以启动它们了。
如下启动其他两个从服务器，具体操作就交给你们啦。
三个都启动完毕后，我们来看一下主节点的状态，很明显，6379为主节点，下面有两个从节点，分别是6380和6381。
3.搭建哨兵（3个）
主从复制搭建好后，我们来搭建哨兵。
新建三个哨兵配置文件：
这些配置文件的含义是什么呢？
port为当前哨兵服务运行的端口。
sentinel monitor mymaster 127.0.0.1 6379 2为哨兵监视一个名为mymaster的主Redis实例，这个主实例的IP地址为127.0.0.1，端口号为6379。
sentinel down-after-milliseconds mymaster 5000为自动失效时间。
sentinel parallel-syncs mymaster 1为指定执行故障转移时，最多可以有几个从Redis实例在同步新的主实例。
sentinel failover-timeout mymaster 15000为如果在该时间内未完成节点切换，则认为失败。
接下来我们来分别启动三个哨兵：（照猫画虎）
4.测试哨兵
如果此时我再启动6239服务器，它是重新成为主节点，还是成为新节点6381的从节点？结论是它成为了从节点。
哨兵进行故障转移的过程
哨兵Sentinel初始化的过程
步骤如下：
1.初始化服务器（哨兵也是一个正常的Redis服务器）
2.将普通的Redis使用的代码替换为哨兵Sentinel专用代码
不需要RDB/AOF文件（因为不需要加载数据，它是监控节点，而不是数据节点）
端口号不一样（哨兵的端口号为26379，而默认的Redis端口为6379）
普通Redis命令：set/get/dbsize
哨兵命令：ping/sentinel
3.初始化哨兵状态sentinel
4.向Redis服务器创建连接
一个命令连接：向主服务器发送命令，并接受回复
一个订阅连接：_sentinel_:hello频道
在发送与订阅功能中，被发送的消息不会保存在服务器中。当客户端不在线/断线中，为了不丢失这条消息，Redis就用了一个订阅频道来接受这条消息。
为什么哨兵是3个？
哨兵集群必须部署两个以上节点，如果哨兵集群仅仅部署了两个哨兵实例，那么他的大多数为2（2的大多数为2，3的大多数为2，5的大多数为3，4的大多数为2），如果其中一个哨兵宕机，就无法满足大多数大于等于2，那么在master发生故障的时候就无法进行主从切换。
哨兵如何监控？
检测实例是否下线：
主观下线：哨兵与服务器断开时间超过指定时间
客观下线：客观下线数量超过半数
整个故障转移流程
1.哨兵领导节点的选举
相互发送信息：要求对方设置自己为局部零头哨兵
Raft算法 先到先得 Leader只是故障转移中出现的角色
可参考：https://www.php.cn/link/f230954603f7a3eea4a0884c786f1ae2
2.新的主服务器怎么选？
由领导节点将所有的从服务器保存在列表中，然后一项项过滤
A.去除所有处于下线的
B.去除近5s内没有回复的
C.优先级+复制偏移量最大（要求数据为最新的）
D.排序，选择运行ID最小的。
