Redis哨兵(sentinel)

是什么

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

哨兵的作用

1、监控redis运行状态，包括master和slave
2、当master down机，能自动将slave切换成新master

能干嘛

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

案例演示

Redis Sentinel架构

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

案例步骤

• 拷贝sentinel.conf文件，名字绝不能错
• 重点参数项说明

bind	服务监听地址，用于客户端连接，默认本机地址
daemonize	是否以后台daemon方式运行
protected-mode	安全保护模式
port	端口
logfile	日志文件路径
pidfile	pid文件路径
dir	工作目录
sentinel monitor <master-name> <ip> <redis-port> <quorum>	设置要监控的master服务器 quorum表示最少有几个哨兵认可客观下线， 同意故障迁移的法定票数。
sentinel auth-pass <master-name> <password>	master设置了密码，连接master服务的密码
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>：	客户端重新配置主节点参数脚本

• 本次案例哨兵sentinel文件通用配置
  • 由于机器硬件关系，我们的3个哨兵都同时配置进192.168.111.169同一台机器,修改sentinel.conf。

    bind 0.0.0.0
    protected-mode no
    port 26379
    daemonize yes
    pidfile /var/run/redis-sentinel26379.pid
    logfile "/opt/redis/26379.log"
    dir /opt/redis
    sentinel monitor mymaster 127.0.0.1 6379 2

    

• 先启动一主二从3个redis实例，测试正常的主从复制 

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

• 测试选举

  • 杀死master查看80、81状态（80尚未变为master节点，81变为80的salve）剩下的2台机器上选出新的master

  • 重启79不会变为master节点，而是变为salve节点(不会双master冲突)

• 投票新选

• 小问题：选举节点后80、89会出现"Error: Server closed the connectionnot"或"Error: Broken pipenot"
  • 了解 Broken Pipe

    认识broken pipe	pipe是管道的意思，管道里面是数据流，通常是从文件或网络套接字读取的数据。当该管道从另一端突然关闭时，会发生数据突然中断，即是broken，对于socket来说，可能是网络被拔出或另一端的进程崩溃
    解决问题	其实当该异常产生的时候，对于服务端来说，并没有多少影响。因为可能是某个客户端突然中止了进程导致了该错误
    总结 Broken Pipe	这个异常是客户端读取超时关闭了连接,这时候服务器端再向客户端已经断开的连接写数据时就发生了broken pipe异常！

    
  • 新老master配置文件
    • 老master配置文件中动态生成replicaof
    • 新master原replicaof被移除掉
  • sentinel配置文件，监控的节点由6379转移至6380
  • 总结
    • 文件的内容，在运行期间会被sentinel动态进行更改
    • Master-Slave切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行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设置了判断主观下线的时间长度
  • 所谓主观下线（Subjectively Down， 简称 SDOWN）指的是单个Sentinel实例对服务器做出的下线判断，即单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息， 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了。
  • sentinel down-after-milliseconds <masterName> <timeout>表示master被当前sentinel实例认定为失效的间隔时间，这个配置其实就是进行主观下线的一个依据master在多长时间内一直没有给Sentine返回有效信息，则认定该master主观下线。也就是说如果多久没联系上redis-servevr，认为这个redis-server进入到失效（SDOWN）状态。
• ODown客观下线(Objectively Down)
  • ODOWN需要一定数量的sentinel，多个哨兵达成一致意见才能认为一个master客观上已经宕掉
  • 四个参数含义：
    masterName是对某个master+slave组合的一个区分标识(一套sentinel可以监听多组master+slave这样的组合)
• 选举出领导者哨兵(哨兵中选出兵王)
  • 当主节点被判断客观下线以后，各个哨兵节点会进行协商，先选举出一个领导者哨兵节点（兵王）并由该领导者节点，也即被选举出的兵王进行failover（故障迁移）
    • 23679sentinel.log哨兵id：b8beb6261f28e1c1d6ddd7a65dd71d9a1c710432
    • 26380sentinel,log哨兵id：fe1efa5575493790ae72fbb65babd59d9a647714
    • 26381sentinel.log哨兵id：30296e7843ec737d9e103a0945c667b7c47bfab5
    • 推举leader，并由leader选择master节点
  • 兵王依靠Raft算法选举
    • 监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者
• 由兵王开始推动故障切换流程并选出一个新master
  • 新主登基
    • 某个Slave被选中成为新Master
    • 选出新master的规则，剩余slave节点健康前提下
      • redis.conf文件中，优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )
      • 复制偏移位置offset最大的从节点
      • 最小Run ID的从节点（字典顺序，ASCII码）
  • 群臣俯首
    • 执行slaveof no one命令让选出来的从节点成为新的主节点，并通过slaveof命令让其他节点成为其从节点
    • Sentinel leader会对选举出的新master执行slaveof no one操作，将其提升为master节点
    • Sentinel leader向其它slave发送命令，让剩余的slave成为新的master节点的slave
  • 旧主拜服
    • 将之前已下线的老master设置为新选出的新master的从节点，当老master重新上线后，它会成为新master的从节点
    • Sentinel leader会让原来的master降级为slave并恢复正常工作。
• 小总结：上述的failover操作均由sentinel自己独自完成，完全无需人工干预。

哨兵使用建议

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