Redis的哨兵 Sentinel
一.哨兵概念
通过自动化的方式来解决主节点挂了的问题，哨兵机制是通过独立的进程来体现的，与redis-server是不同的进程，redis-sentinel不负责存储数据，只是对其他的redis-server进程起到监控的效果。
1.相关名词解释图
二.主节点恢复方式
1.人工恢复主节点故障流程图
下图中的用户监控一般是通过用户自己写的程序对服务器进行监控，当发生异常时，对用户进行报警。
2.哨兵自动恢复主节点流程
哨兵节点集合中是单独的多个redis sentinel进程，并且这三个哨兵进程会监控现有的redis master和slave（监控：这些进程之间会建立TCP长连接，通过这样的长连接，定期发送心跳包）
借助上述的监控机制就可以即使发现某个主机是否挂了，如果从节点挂了没什么关系，如果主节点挂了，哨兵就会发挥作用了。
此时一个哨兵节点发现主节点挂了还不能够判定主节点是否真的挂了，此时还需要多个哨兵共同认为主节点挂了，才是真的挂了，主要是为了防止误判，毕竟有时候哨兵也会出现网络问题。
主节点真的挂了之后，这些哨兵节点中就会推举出一个leader，由这个leader负责从现有的从节点中，挑选一个座位新的主节点。
挑选出新的主节点之后，哨兵节点就会自动控制该被选中的节点，执行slaveof no one，并且控制其他从节点，修他们的主节点对象，通过slaveof改到新的主节点上。
哨兵节点会自动通知客户端程序，告知新的主节点是谁，并且后续客户端再进行写操作时，就会针对新的主节点进行操作了。
三.使用docker搭建环境
按理来说肯定要将这些单独的redis-sentinel放在不同的服务器主机上，但是吃拼好饭的我，怎么敢奢求多个云服务器呢，所以只能在一个云服务器上搞几个哨兵了，呜呜呜。在实际工作中是不会这样做的，因为是没有意义的。所以此时使用docker来解决这个问题。
1.安装docker-compose
安装docker-compose只需要一个命令：apt install docker-compose（Ubantu环境），成功后输入docker-compose会出现下面的一些列options：
2.安装docker
询问AI获取命令，出现的问题也可以直接问AI就能够解决，或者在网上去查询一下基本上都能够解决这些问题，详细的就不再赘述了。：
3.停止之前的redis服务器
通过kill来杀死从节点的redis服务器，通过service redis-server stop的命令关闭主节点的服务器
4.使用docker获取到redis的镜像
可能此时拉不下来需要在配置文件中修改一下，首先通过vim /etc/docker/daemon.json进入docker的配置文件：
使用命令docker pull redis:5.0.9获取redis的镜像：
5.使用docker-compose进行容器编排
通过一个配置文件(yml)，把具体要创建那些容器，每个容器的各种参数，描述清楚。后续通过一个简单的命令，就能够批量的启动/停止这些容器了。
创建三个容器，作为redis的数据点（一个主节点两个从节点） yml配置文件
创建三个容器，作为redis的哨兵节点 yml配置文件
其实也可以通过一个yml文件直接启动6个容器，如果把这6个容器同时启动，可能是哨兵先启动完成，数据节点后启动完成，哨兵可能就会认为是数据节点挂了，虽然对于大局不影响，但是会影响到观察执行日志的过程。
创建目录
打开yml文件
写配件文件
启动数据节点：
搞哨兵节点
先计入redis-sentinel的目录中，在进行vim docker-compose.yml，然后进行配置文件的书写：
此处还需要创建 sentinel1.conf sentinel2.conf sentinel3.conf 。三份文件的内容是完全相同的配置文件：
此时进行复制两份就行了：
再通过命令docker-compose up -d启动：
但是此时通过命令docker-compose logs看到有错误出现：
这是因为docker-compose一下启动了N个容器，此时N个容器都处于同一个局域网当中，就可以使这N个容器之间可以互相访问。但是，这N个容器是一起启动的所以会在一个局域网中，如果想刚才是分别启动的N个容器，则不会在同一个局域网中，则无法互通。
此时通过docker-compose把此处两组服务器给放到同一个局域网当中，在使用docker network ls列出当前docker中的局域网。
此时应该将后面创建的3个哨兵节点加入到上面数据节点的局域网当中，而不是创建新的局域网，此时就需要回到哨兵节点的目录去增加一些配置文件信息：
修改好配置文件后需要重新启动docker：
其中sentinel1.conf的配置文件也被自动给改写了：
四.哨兵节点作用演示
哨兵节点存在的意义就是为了redis主从结构出现问题时（主节点挂了），此时哨兵节点能够自动的帮我们重新选择出一个主节点，来替代之前挂了的节点，保证整个redis仍然是 可以用的状态。
1.先停止主节点
sdown：主观下线，这个哨兵节点认为该主节点挂了。
odown：客观下线，几个哨兵都认为该节点挂了，是通过法定票数决定的也就是(quorum 3/2)，此时主节点挂了这件事儿就是真实的。
此时就需要哨兵选出一个从节点作为新的主节点(redis-master的IP地址就发生了改变)
2.主节点停止后的情况
主节点停止后，此时原来从节点的6380成为了现在新的主节点了(要进入redis的客户端，需要在docker原来创建的目录下才能进去)
3.启动之前关闭的主节点
使用docker start redis-master的命令启动之前关闭的主节点：
此时进入之前主节点的客户端，查看它的详细信息，就看到它现在已经是从节点，不再是主节点了。
新的主节点6380的从节点此时就有两个了：
五.哨兵重选主节点流程
1.主观下线
哨兵节点通过心跳包判定redis服务器是否正常工作，如果心跳包没有如约而至，就说明redis服务器挂了，此时还不能排除网络波动的影响，因此只能单方面认为这个redis 节点挂了。
2.客观下线
多个哨兵都认为主节点挂了(认为挂了的哨兵节点数目达到了法定票数)哨兵们就认为这个主节点是客观下线的。当然也可能存在非常严重的网络波动导致所有的哨兵都联系不上redis主节点，此时出现这个情况主节点基本上就无法工作了，因为用户无法连接上redis主节点的客户端了，此时也被视为挂了。
3.选举主节点
此时主节点挂了之后，需要让多个哨兵节点选择出一个leader节点出来，由这个节点负责选一个从节点作为新的主节点。
哨兵1、2、3：
1号哨兵给自己进行了投票：
2号和3号哨兵也给1号哨兵进行了投票： 
此时就能够让1号哨兵成为leader（此处leader的选举类似于RabbitMQ中的主节点选举（个人理解））
4.挑选新的主节点
- 先进行比较优先级。每个redis数据节点，都会在配置文件中有一个优先级的设置(slave-priority)
- 比较offset大小，最大就胜出。offset代表从节点从主节点这边数据同步的进度，数值越大，说明主从节点的数据就越接近。
- 通过run id 来进行挑选一个。每个redis节点启动的时候都会随机生成一串数字（大小全随缘分）
此时就把新的主节点指定好之后，leader就会控制这个节点，执行slave no one 称为master，在控制其他节点执行slave of让这些其他节点以新的master作为主节了。