16.哨兵（sentinel）

1.解决的问题

哨兵解决的问题：可用性
主从复制，最大的问题在主节点上，主节点挂了，从节点不会自动变成主节点，需要人工干预；
从节点和主节点之间断开连接，有两种情况：
1）从节点主动与主节点断开连接 -> slaveof no one，从节点晋升为主节点，脱离原有结构；
2）主节点挂了，从节点不会自动进行晋升，需要人工干预；
Redis哨兵：自动地对挂了的主节点进行替换；

2.哨兵原理

哨兵机制是通过独立的进程体现的，和之前redis-server是不同的进程；
redis-sentinel不负责存储数据，只是对其他的redis-server进程起到监控的效果；

哨兵节点会监督当前整个主从结构，但哨兵节点挂了情况依旧会影响可用行，因此通常采用哨兵节点集合（对于服务器后端开发，监控程序至关重要）；

程序员恢复过程缓慢且不及时；

1.主节点挂了，哨兵发挥作用
一个哨兵发现主节点挂了，不够，需要多个哨兵节点来共同认定这件事，为了防止误判；
2.主节点确实挂了，这些哨兵节点中会选举出一个leader，来执行选择从节点作为新主节点
3.挑选出新的主节点后，哨兵节点控制该节点，slaveof no one，然后让其他从节点slaveof这个新主节点；

4.哨兵节点会自动通知客户端程序，告知新的主节点是谁，后续客户端进行写操作时就写到新主节点上；

Redis哨兵核心功能：
1）监控
2）自动故障转移
3）通知

3.部署哨兵

docker可以理解成一个轻量级的"虚拟机"，起到了隔离环境效果，又没那么吃资源；

docker中"镜像"和"容器"概念，类比"可执行程序"和"进程"关系，镜像可自己制作也可用现成的，docker hub（github），redis官方已经制作好了；
环境安装：
1）安装docker 和 docker-compose
2）停止之前的redis服务器
3）使用docker获取redis镜像（docker pull是从docker hub镜像仓库进行下载）
docker pull mirror.ccs.tencentyun.com/library/redis:5.0.7-alpine
注：包含一个精简的Linux操作系统环境Alpine Linux，但与主机共享内核
docker images 查看镜像

基于docker搭建哨兵环境（docker-compose来进行容器编排）：
此处涉及到多个redis sever也有多个redis哨兵节点；通过一个配置文件，把具体创建哪些容器，每个容器的运行参数，描述清楚，后续就你批量启动/停止；
yml格式作为配置文件，xml，json
配置：
1）创建三个容器，作为redis的数据节点（一主两从）docker-compose.yml

services的子节点名字可由自己设定（master，slave1，slave2）；
docker容器可以理解成一个轻量级的虚拟机，端口号和外面宿主机是两套体系；

--slaveof 后面直接跟容器名即可，容器名类似域名，docker自动解析替换成对应ip；
docker-compose up -d 启动，docker-compose logs 查看日志
配置docker-hub镜像下载源；
复制代码
1）追加写镜像源
sudo tee /etc/docker/daemon.json << 'EOF'
{
  "registry-mirrors": [
    "https://mirror.ccs.tencentyun.com",
    "https://docker.mirrors.ustc.edu.cn",
    "https://hub-mirror.c.163.com"
  ],
  "max-concurrent-downloads": 10
}
EOF
2）重启
sudo systemctl daemon-reload
sudo systemctl restart docker
2）创建三个容器，作为redis哨兵节点

注意：哨兵节点会在运行过程中，对配置文件进行自动修改，因此一个哨兵一个配置文件

sentinel monitor 主节点名主节点ip 主节点端口法定票数

docker-compose分别启动的主从复制结构和哨兵处于两个不同局域网中，哨兵需要与主从复制结构通信，需要指定网络名；（docker network ls 查看docker启的网络名）；

可以观察到，每个哨兵节点的配置文件都是被修改过的；

4.哨兵机制

哨兵存在的意义：在redis主从结构出现问题的时候（主节点挂了），哨兵节点自动选择主节点，保持整个redis是可用状态；
复制代码
# +new-epoch 1                      # 新纪元开始
# +try-failover master ...          # 开始故障转移
# +vote-for-leader ...              # 投票选举领导者
# +elected-leader master ...        # 选举成功
# +failover-state-select-slave ...  # 选择从节点提升为主
# +selected-slave slave 172.18.0.2:6379  # 选择了 slave1
sdown（subjectively down）：主观下线
odown（objectively down）：客观下线
哨兵重新选取主节点流程：
1）主观下线，哨兵节点通过心跳包，判断redis是否正常工作；

2）客观下线，主观下线个数达到法定票数；
3）多个哨兵节点投票选出leader节点，票数最多的成为leader；
4）leader选举完毕，leader需要选出一个从节点，作为新的主节点；

优先级：每个redis数据节点都会在配置文件中有一个优先级设置，slave-priority，优先级高的胜出

offset：offset最大，胜出，同步进度多；

run id：随机选

5）选出新的主节点，新的主节点slaveof no one，其他从节点slaveof这个从节点；
6）通知客户端程序新的主节点信息；