Redis哨兵模式的实现


    目录
  • 1、哨兵简介
  • 2、启用哨兵模式
    • 2.1 哨兵配置
    • 2.2 哨兵模拟搭建实验
  • 3、哨兵工作原理
    • 3.1 监控阶段
    • 3.2 通知阶段
    • 3.3 故障转移阶段

    1、哨兵简介
    master宕机场景的处理：
    
    问题：
    怎么确认master确实宕机了？（中间断网1s就认为人挂了不合适）
    怎么找一个slave来暂替master？
    旧的master恢复以后怎么处理？
    
    哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master
    
    哨兵的三点作用：
    
  • 监控
        不断的检查master和slave是否正常运行。
  • 通知
        当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知
  • 自动故障转移
        断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

    注：
    
  • 哨兵也是一台redis服务器，只是不提供数据服务
  • 通常哨兵配置数量为单数，3、5、7……

    2、启用哨兵模式
    2.1 哨兵配置
    查看哨兵的配置文件，过滤注释与空行：
    
    具体配置参数整理：
    
配置项实例含义
sentinel auth-pass 服务器名 密码sentinel auth-pass mymaster 9527连接服务器时的验证密码
sentinel down-after-milliseconds 自定的服务器名 masterIP Port 票选数量sentinel monitor mymaster 1.2.3.4 6379 2后面的2，即两个哨兵认为master挂了就是真的挂了，常为哨兵数的1/2+1
sentinel down-after-milliseconds 服务器名 毫秒数sentinel down-after-milliseconds mymaster 3000哨兵判定master挂掉的时间周期
sentinel parallel-syncs 服务器名 服务器数sentinel parallel-syncs mymaster 1指定同时进行主从的slave数量，数值越大，要求网络资源越高，数值约小，同步时间约长
sentinel failover-timeout 服务器名 毫秒数sentinel failover-timeout mymaster 9000出现故障后，故障切换的最大超时时间3分钟，超过则认定切换失败
sentinel notification-script 服务名 脚本路径服务器无法正常联通时，设定的执行脚本，通常调试使用

    使用sed编辑文件，并重定向。生成三个哨兵的配置文件（用三个不同端口模拟三个哨兵）
    
    哨兵启动指令：
    redis-sentinel sentinel-端口号.conf先启动master、再slave、最后启动哨兵
    2.2 哨兵模拟搭建实验
    以本机的6379位master、6380、6381为slave，26379、26380、26381为三个sentinel，模拟实验：
    ①启动master和slave后，启动26379sentinel：
    
    ②连接哨兵的客户端，验证其确实不能进行set等指令：
    
    
    ③启动哨兵26380
    
    注意此时哨兵26379的配置文件会相应的发生变化：
    
    ④模拟master宕机，CTRL+C掉6379的server端
    
    ⑤6379重新连接服务端以后，查看哨兵控制台日志：取消了6379的s_down标记，但并未恢复其master的身份
    
    3、哨兵工作原理
    哨兵在进行主从切换过程中经历三个阶段：
    
  • 监控
  • 通知
  • 故障转移

    3.1 监控阶段
    
    sentinel会向master和slave要信息，各个sentinel之间有专门通路进行信息交换，如此便形成了一个网络：
    
    3.2 通知阶段
    就像一个小的朋友圈，sentinel之间互相进行信息的传播，保持信息的对等：
    
    3.3 故障转移阶段
    ①哨兵1持续发消息给master均无反应，标记master为S_DOWN，也叫主观下线
    
    ②哨兵1标记后，并将这个消息带回sentinel的圈子里，告诉其余哨兵，可能master挂了，于是其余哨兵开始发送消息给master验证消息是否属实
    
    ③验证结果确实如此，只要半数以上哨兵认为挂了，则标记变为O_DOWN（这也是哨兵数量要求奇数的原因），这时，O_DOWN就是客观下线了
    
    ④既然确认master挂了，那就要去处理，哪个哨兵去处理呢，每个哨兵发送挂的IP、挂的端口、自己曾经竞选的次数、自己的runID，以便选个领头的哨兵
    
    最后由竞选出来的1号哨兵去处理：
    
    ⑤ 从slave中挑选备选master，首先淘汰掉：
    
  • 不在线的
  • 响应慢的
  • 与原master断开时间久的

    
    对于剩下的备选，则考虑优先级、offset、runid等等
    
    ⑥向新选出的master发送slaveof no one，断开原主从连接，并向其他slave发送slaveof 新masterIP端口
    
    至此，故障转移完成！！
    到此这篇关于Redis哨兵模式的实现的文章就介绍到这了,更多相关Redis哨兵模式内容请搜索电脑手机教程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持电脑手机教程网！
相关文章！