3.2.5 Redis哨兵高可用机制

文章目录

    • 哨兵(Sentinel)机制核心作用
    • 核心运作流程
    • 七大核心概念
    • 哨兵启动和配置
    • 启动容器
    • 哨兵如何知道Redis主从信息
    • 什么是主观下线(sdown)
    • 哨兵之间如何通信
    • 什么是客观下线(odown)
    • 哨兵领导选举机制
    • slave选举方案
    • 最终主从切换的过程
    • 哨兵服务部署方案

哨兵(Sentinel)机制核心作用

3.2.5 Redis哨兵高可用机制_第1张图片
3.2.5 Redis哨兵高可用机制_第2张图片

核心运作流程

3.2.5 Redis哨兵高可用机制_第3张图片

七大核心概念

3.2.5 Redis哨兵高可用机制_第4张图片

哨兵启动和配置


sentinel-26380.conf中的内容

# 配置文件:sentinel.conf,在sentinel运行期间是会被动态修改的
# sentinel如果重启时,根据这个配置来恢复其之前所监控的redis集群的状态
# 绑定IP
bind 0.0.0.0
# 后台运行
daemonize yes
# 默认yes,没指定密码或者指定IP的情况下,外网无法访问
protected-mode no
# 哨兵的端口,客户端通过这个端口来发现redis
port 26381
# 哨兵自己的IP,手动设定也可自动发现,用于与其他哨兵通信
# sentinel announce-ip
# 临时文件夹
dir /tmp
# 日志
logfile "/var/log/redis/sentinel.log"
# sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡,才认为是真的死亡
sentinel monitor redis-1 192.168.0.102 6380 2
# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息,那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds redis-1 1000
# 如果在该时间(ms)内未能完成failover操作,则认为该failover失败
sentinel failover-timeout redis-1 3000
# 指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长
sentinel parallel-syncs redis-1 1

启动容器

与启动redis容器类似,启动一个别名为sentinel的容器

docker run -it --name sentinel-1 -p 26380:26380 -p 6379:6379 -v /root/sentinel-26380.conf:/usr/local/etc/redis/sentinel.conf -d redis /bin/bash

进入容器

docker exec -it sentinel-1 bash

创建日志目录和文件

mkdir /var/log/redis

touch /var/log/redis/sentinel.log

启动哨兵
redis-sentinel /usr/local/etc/redis/sentinel.conf

查看日志,哨兵成功监听到一主和两从的机器

哨兵如何知道Redis主从信息

3.2.5 Redis哨兵高可用机制_第5张图片

什么是主观下线(sdown)

3.2.5 Redis哨兵高可用机制_第6张图片

哨兵之间如何通信

3.2.5 Redis哨兵高可用机制_第7张图片

什么是客观下线(odown)

3.2.5 Redis哨兵高可用机制_第8张图片

哨兵领导选举机制

3.2.5 Redis哨兵高可用机制_第9张图片

slave选举方案

3.2.5 Redis哨兵高可用机制_第10张图片

最终主从切换的过程

3.2.5 Redis哨兵高可用机制_第11张图片

哨兵服务部署方案

3.2.5 Redis哨兵高可用机制_第12张图片

你可能感兴趣的:(缓存中间件)