哨兵是什么？能干嘛？
sentinel 官网

吹哨人巡查监控后台master主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。作用就是无人值守运维

• 主从监控 监控主从redis库运行是否正常
• 消息通知 哨兵可以将故障转移的结果发送给客户端
• 故障转移 如果Master异常，则会进行主从切换，将其中1个Slave作为新的master
• 配置中心 客户端通过连接哨兵来获得当前Redis服务的主节点的地址

哨兵模式集群搭建

架构说明：3个哨兵（自动监控和维护集群，不存放数据，只是吹哨人）。1主2从 （用于数据读取和存放）

docker-compose 部署

version: '3.8'

services:
  # 主节点
  redis-master:
    image: docker.1ms.run/library/redis:7.0.0  # 镜像替换
    container_name: redis-master
    ports:
      - "6379:6379"
    command: 
      - redis-server 
      - --requirepass root
      - --masterauth root
      - --appendonly yes
    networks:
      - redis-net
    restart: always

  # 从节点1
  redis-slave1:
    image: docker.1ms.run/library/redis:7.0.0  # 镜像替换
    container_name: redis-slave1
    ports:
      - "6380:6379"
    command: 
      - redis-server 
      - --replicaof redis-master 6379
      - --masterauth root
      - --requirepass root
      - --appendonly yes
    networks:
      - redis-net
    restart: always
    depends_on:
      - redis-master

  # 从节点2
  redis-slave2:
    image: docker.1ms.run/library/redis:7.0.0  # 镜像替换
    container_name: redis-slave2
    ports:
      - "6381:6379"
    command: 
      - redis-server 
      - --replicaof redis-master 6379
      - --masterauth root
      - --requirepass root
      - --appendonly yes
    networks:
      - redis-net
    restart: always
    depends_on:
      - redis-master

  # 哨兵节点
  sentinel1:
    image: docker.1ms.run/library/redis:7.0.0  # 镜像替换
    container_name: sentinel1
    ports:
      - "26379:26379"
    command: 
      - redis-sentinel 
      - /usr/local/etc/redis/sentinel.conf
    volumes:
      - ./sentinel1.conf:/usr/local/etc/redis/sentinel.conf
    networks:
      - redis-net
    restart: always

  sentinel2:
    image: docker.1ms.run/library/redis:7.0.0  # 镜像替换
    container_name: sentinel2
    ports:
      - "26380:26379"
    command: 
      - redis-sentinel 
      - /usr/local/etc/redis/sentinel.conf
    volumes:
      - ./sentinel2.conf:/usr/local/etc/redis/sentinel.conf
    networks:
      - redis-net
    restart: always

  sentinel3:
    image: docker.1ms.run/library/redis:7.0.0  # 镜像替换
    container_name: sentinel3
    ports:
      - "26381:26379"
    command: 
      - redis-sentinel 
      - /usr/local/etc/redis/sentinel.conf
    volumes:
      - ./sentinel3.conf:/usr/local/etc/redis/sentinel.conf
    networks:
      - redis-net
    restart: always

networks:
  redis-net:
    driver: bridge

三个sentinel.conf的配置说明，只有端口的不同，具体的配置信息如下：
基础模板

# 基本参数
port 26379                                             # 哨兵监听端口（需差异化）
daemonize no                                           # 禁止后台运行（容器需前台运行）
logfile "/var/log/redis/sentinel.log"                  # 日志路径（需差异化）
pidfile "/var/run/redis/sentinel.pid"                  # PID文件路径（需差异化）
dir "/tmp"                                             # 哨兵工作目录

# 主节点监控

sentinel resolve-hostnames yes  # 显式启用主机名解析（Redis 6.2+ 必需）
sentinel announce-hostnames yes # 可选：向客户端返回主机名而非IP
sentinel monitor mymaster redis-master 6379 2          # 主节点服务名+端口，quorum=2
sentinel auth-pass mymaster root                       # 主节点密码（与requirepass一致）
sentinel down-after-milliseconds mymaster 5000         # 5秒无响应判定主观下线
sentinel parallel-syncs mymaster 1                     # 故障转移时并行同步数
sentinel failover-timeout mymaster 15000               # 故障转移超时时间（毫秒）

# 安全加固
sentinel deny-scripts-reconfig yes                     # 禁止运行时修改危险配置
protected-mode no                                       # 允许外部网络访问

特殊说明：redis的注释# 不能与配置放在同一行

差异化的配置

docker部署后启动集群

检查主从状态

docker exec -it redis-master redis-cli -a root info replication
# 应显示两个从节点连接

相关日志：

模拟redis中主从集群中的master节点挂了后，查看集群的状态。

原先的slave从节点被选举为主节点master
这个地方有点问题，docker stop redis-master 节点的容器服务后，在sentinel进行选举的过程中出现了 unknown host name的域名无法解析的异常，也即sentinel.conf中的redis-master无法解析该域名！！！！这个问题还没解决，在单机上部署集群，希望看到的大佬给出答案=><=

redis中sentinel.conf配置文件中的主要配置参数说明


重要的参数quorum
quorum表示最少有几个哨兵认可客观下线。

sentinel的启动命令以及端口说明
票数为quorum2

面试高频–哨兵运行流程和选举原理
当一个主从配置中的master失效之后，sentinel可以选举出一个新的master,用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据。一般建议sentinel采用奇数台，防止某一台sentinel无法连接到master导致误切换。
运行流程，故障切换

• 三个哨兵监控一主而从，正常运行中
  
• SDown主观下线（Subjectively Down）
  SDOWN(主观不可用)是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件。sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度
  
• ODown客观下线（Objectively Down）
  ODOWN需要一定数量的sentinel,多个哨兵达成一致意见才能认为一个master客观上已经宕掉。
  
  选举出领导者哨兵（哨兵中选出兵王）
  当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王） 并由该领导者节点，也即被选举出的兵王进行failover(故障转移)
  三哨兵日志文件两次解读分析
  sentinel26379.log
  
  sentinel26380.log
  
  sentinel26381.log
  
  哨兵领导者，兵王如何选举出来的？
  Raft一致性算法
  
  由兵王开始推动故障切换流程并选出一个新master
• 新王登基 （某个Slave被选中成为新Master,选出新master的规则，剩余slave节点健康前提下）
  从多个slave节点中选出master的过程以及判断逻辑根据优先级的配置以及复制偏移量offset
  

• 群臣俯首
  一朝天子一朝臣，换个码头重新拜
  1.执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点。2.Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点。3.Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave
• 旧主拜服
  老master回来也认怂

1.将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点。2.Sentinel leader会让原来的master降级为slave并恢复正常工作。

Raft 选举总结
上述的faliover操作均由sentinel自己独自完成，完全无需人工干预。

哨兵模式使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数
• 各个哨兵节点的配置应一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据零丢失

承上启下引出集群模式

视频链接
Redis Sentinel