Redis | 哨兵 Sentinel

是什么

• Redis主从复制在主节点故障时，需手动将从节点提升为主节点，过程复杂且易出错。
• 哨兵机制自动监控主节点状态，故障时自动进行主从切换，减少人工干预。

• 吹哨人巡查监控后台master主机是否故障，如果故障了根据 投票数 自动将某一个从库转换为新主库，继续对外服务
• 作用：无人值守的运维机制
• 官网理论：https://redis.io/docs/management/sentinel/
  

能干嘛

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

怎么玩（案例演示实战步骤）

Redis Sentinel 架构前提说明

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

案例步骤

1. /myredis 目录下新建或者拷贝 sentinel.conf 文件，名字绝对不能错

2. 先看看 /opt 目录下默认的 sentinel.conf 文件的内容

3. 重要参数项说明：

   • bind：服务监听地址，用于客户端连接，默认本机地址
   • daemonize：是否以后台daemon方式运行
   • protected-model：安全保护模式
   • port：端口
   • logfile：日志文件路径
   • pidfile：pid文件路径
   • dir：工作目录
   • sentinel monitor <master-name> <ip> <redis-port> <quorum>：
     • 设置要监控的master服务器
     • quorum 表示最少有几个哨兵认可客观下线，同意故障迁移的法定票数
     • 行尾最后的 quorum，表示确认客观下线的最少哨兵数量
     • 我们知道，网络是不可靠的（网络抖动，网络闪断，防火墙限制，黑客攻击等），有时候一个sentinel会因为网络堵塞而误以为master redis已经死掉，在sentinel集群环境下需要多个sentinel互相沟通来确认某个master是否真的死掉了，quorum这个参数是进行客观下线的一个依据，意思是至少有quorum个sentinel认为这个master有故障，才会对这个master进行下线以及故障转移。
     • 因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以，这就需要多个sentinel都一致认为改master有问题，才可以进行下一步操作，这就保证了公平性和高可用。
   • sentinel auth−pass <master-name> <password>：master设置了密码，连接master服务的密码
   • 其他
     • sentinel down-after-milliseconds <master-name> <milliseconds>：指定多少毫秒之后，主节点没有应答哨兵，此时哨兵主观上认为主节点下线
     • sentinel parallel-syncs <master-name> <nums>：表示允许并行同步的slave个数，当Master挂了后，哨兵会选出新的Master，此时，剩余的slave会向新的master发起同步数据
     • sentinel failover-timeout <master-name> <milliseconds>：故障转移的超时时间，进行故障转移时，如果超过设置的毫秒，表示故障转移失败
     • sentinel notification-script <master-name> <script-path>：配置当某一事件发生时所需要执行的脚本
     • sentinel client-reconfig-script <master-name> <script-path>：客户端重新配置主节点参数脚本

4. 本次案例哨兵 sentinel 文件通用配置

   • 由于机器硬件关系（内存不够开更多虚拟机了 ），我们的3个哨兵都同时配置进192.168.111.169同一台机器

   • sentinel26379.conf
     、sentinel26380.conf
     、sentinel26381.conf

   • 瞄一眼上面3个配置文件中我们自己填写的内容

   • master主机配置文件说明

5. 先启动1主2从3个redis实例，测试正常的主从复制

   • 架构说明
   • 主机6379配置修改6379后续可能会变成从机，需要设置访问新主机的密码，所以此处会设置masterauth，不然后续可能会报错 master_link_status:down
   • 具体的IP地址和密码根据本地真实情况酌情修改
   • 3台不同的虚拟机实例，启动三部真实机器实例并连接

6. 再启动3个哨兵，完成监控

   • sentinel的两种启动方式
   • redis-server sentinel26379.conf --sentinel
   • redis-server sentinel26380.conf --sentinel
   • redis-server sentinel26381.conf --sentinel

7. 启动3个哨兵监控后再测试一次主从复制：

   • 岁月静好，一切OK
   • 启动后我们会发现sentinel配置文件会自动在配置文件中加上部分配置，其实就是哨兵之间通过主节点获取从节点和其他哨兵的信息,然后分别与他们通信

8. 原有的master挂了

   • 自己手动关闭6379服务器，模拟master挂了
   • 问题思考：

     • 两台从机数据是否OK？

       • 两台从机数据OK
       • 两个小问题，出现在master刚宕机的一段时间内
         • 
         • 
         • 了解broken pipe

     • 是否会从剩下的2台机器上选出新的master？会投票选出新的master主机

     • 之前down机的master机器重启回来，谁将会是新老大？会不会双master冲突？谁是master，限本次案例：

       • 6381被选举为新的master，上位成功
       • 重启6379之后，它会从原来的master降级为slave
       • 6380还是slave，只不过是换了一个新老大6381(从跟随6379变成跟随6381)

9. 对比配置文件：

   • vim sentinel26379.conf

   • 老master，vim redis6379.conf

   • 新master，vim redis6381.conf

   • 结论：

     • 文件的内容，在运行期间会被sentinel动态进行更改
     • Master−Slave切换后，master_redis.conf、slave_redis.conf、sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，而升级为master的主机会去掉原来的slaveof配置，sentinel.conf的监控目标会随之调换

其他备注

• 生产上都是不同机房不同服务器，很少出现3个哨兵全部挂掉的情况
• 可以同时监控多个master，一行一个

哨兵运行流程和选举原理

• 当一个主从配置中master失效后，sentinel可以选举出一个新的master
• 用于自动接替原master的工作，主从配置中的其他redis服务器自动指向新的master同步数据
• 一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换
• 运行流程，故障切换
  • 三个哨兵监控一主二从，正常运行中
  • SDown主观下线(Subjectively Down)
    • SDOWN（主观不可用）是单个sentinel自己主观上检测到的关于master的状态，从sentinel的角度来看，如果发送了PING心跳后，在一定时间内没有收到合法的回复，就达到了SDOWN的条件
    • sentinel配置文件中的 down-after-milliseconds 设置了判断主观下线的时间长度，默认30秒
    • 说明
  • ODown客观下线(Objectively Down)
    • ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕机
    • 说明
  • 选举出领导者哨兵（哨兵中选出兵王）
    • 完成投票后，如果认为master宕机了，会从3个哨兵里面选出一个leader，从众多slave里面选出一个做slave ==> master的转变，由leader来指定谁是新的master
    • 当主节点被判断客观下线后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点，并由该领导者也即被选举出的兵王进行failover（故障转移）。
    • 3哨兵日志文件2次解读分析
      
    • 哨兵领导者，兵王如何选出来？Raft算法：监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法。Raft算法的基本思路是先到先得:即在一轮选举中，哨兵A向B发送成为领导者的申请、如果B没有同意过其他哨兵，则会同意A成为领导者。
  • 由兵王开始推动故障切换流程并选出新的master

    1. 新主登基

       • 某个slave被选中成为新master
       • 选出新master的规则，剩余Slave节点健康前提下，会按图所示的规则进行选举权限、复制偏移量、runID

         • redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高)

         • 复制偏移位置offset最大的从节点(也就是在master还没有宕机时，复制到数据比其他Slave要多，尽可能保证数据完整性)

         • 最小Run ID的从节点，字典顺序，ASCII码

    2. 群臣俯首

       • 一朝天子一朝臣，换个码头重新拜
       • 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
       • sentinel leader会对选举出的新master执行slaveof on one操作，将其提升为master节点
       • sentinel leader向其他slave发送命令，让剩余的slave成为新的master节点的slave

    3. 旧主拜服

       • 老master回来也认怂，会被降级为slave
       • 老master重新上线后，会将它设置为新选出的master的从节点
       • sentinel leader会让原来的master降级为slave并恢复正常工作
  • 小总结：上述的failover操作均由sentinel自己独自完成，完全不需要人工干预

哨兵使用建议

• 哨兵节点的数量应为多个，哨兵本身应该集群，保证高可用
• 哨兵节点的数量应该是奇数，避免投票平局
• 各个哨兵节点的配置应一致
• 如果哨兵节点部署在Docker等容器里面，尤其要注意端口的正确映射
• 哨兵集群+主从复制，并不能保证数据零丢失，所以需要使用集群
  • 主从复制是异步的，主节点写入数据后，不会等待从节点确认就返回成功。若主节点在数据同步到从节点前宕机，这部分数据将丢失。
  • 哨兵系统检测主节点故障并切换到从节点需要时间，期间主节点无法服务，可能导致数据丢失。5-10s起步