Redis哨兵模式原理讲解

Linux下Redis主从+哨兵搭建：https://blog.csdn.net/Ye_GuoLin/article/details/116153197

1、哨兵机制图解

2、哨兵机制的原理

1. Sentinel相关配置

# 哨兵sentinel实例运行的端口 默认26379  
port 26379 
# 守护进程模式
daemonize yes
# 开启守护进程时，哨兵进程id记录地址(自定义)
pidfile /var/run/redis-sentinel.pid
# 指明日志文件名(自定义)
logfile "./sentinel.log"
# 进程工作目录(自定义)
dir "./"

############## 与sentinel监控，故障转移等主要功能息息相关的重要配置 ########################
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
sentinel auth-pass mymaster 123456

#避免脚本重置，默认值yes，避免一个简单的安全问题
sentinel deny-scripts-reconfig yes
# 重命名你认为危险的命令，使之更安全
# SENTINEL rename-command mymaster CONFIG GUESSME

• sentinel monitor master-name master-ip master-port quorum：哨兵节点定期监控,master-name为自定义的主节点名称，master-ip为主节点ip，master-port为主节点端口号， quorum设置为2就代表至少要有两个哨兵认为主节点故障了，才算主节点客观下线了，一般设置为sentinel节点数的一半加一。
• sentinel down-after-milliseconds master-name times：每个哨兵节点会定期发送ping命令来判断Redis节点和其余的哨兵节点是否是可达的，如果超过了配置的times时间没有收到pong回复，就主观判断节点是不可达的,times的单位为毫秒。
• sentinel parallel-syncs master-name nums： 当哨兵节点都认为主节点故障时，哨兵投票选出的leader会进行故障转移，选出新的主节点，原来的从节点们会向新的主节点发起复制，这个配置就是控制在故障转移之后，每次可以向新的主节点发起复制的节点的个数，最多为nums个，因为如果不加控制会对主节点的网络和磁盘IO资源很大的开销。
• sentinel failover-timeout master-name times：这个代表哨兵进行故障转移时如果超过了配置的times时间就表示故障转移超时失败。
• sentinel auth-pass master-name password：如果主节点设置了密码，则需要这个配置，否则哨兵无法对主节点进行监控。

2. 主观下线与客观下线

• 主观下线（Subjectively Down， 简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
• 客观下线（Objectively Down， 简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断。（这里的多个就是上面sentinel monitor中配置的数字）
  如果一个服务器没有在 master-down-after-milliseconds 选项所指定的时间内， 对向它发送 PING 命令的 Sentinel 返回一个有效回复（valid reply）， 那么 Sentinel 就会将这个服务器标记为主观下线。
  注意： 只有主节点才有客观下线，对于任何其他类型的 Redis 实例， Sentinel 在将它们判断为下线前不需要进行协商

3. sentinel的作用

• 监控(Monitoring)： 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
  1 ) 每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到
  2 ）每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的
  3 ）每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据
• 提醒(Notification): 当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移(Automatic failover）： 当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用新Master代替失效Master。
  故障转移机制：
  1 ）过滤掉主观下线的节点
  2 ）选择slave-priority最高的节点，如果由则返回没有就继续选择
  3 ）选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整
  4 ）选择run_id最小的节点
  更新主从状态：
  通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
  将已下线的主节点设置成新的主节点的从节点，当其回复正常时，复制新的主节点，变成新的主节点的从节点
  同理，当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从**（如果在没有配置Sentinel的情况下，以上更新主从状态的操作也可以通过手动输命令达成）**