Redis 学习笔记(十三)Redis Sentinel 介绍与部署

Redis Sentinel 介绍与部署

1. Sentinel介绍

1.1 主从复制的问题

Redis主从复制可将主节点数据同步给从节点,从节点此时有两个作用:

  • 一旦主节点宕机,从节点作为主节点的备份可以随时顶上来。
  • 扩展主节点的读能力,分担主节点读压力。

但是问题来了:

  • 一旦主节点宕机,从节点晋升成主节点,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。
  • 主节点的写能力受到单机的限制。
  • 主节点的存储能力受到单机的限制。

第一个问题,我们接下来讲的Sentinel就可以解决。而后两个问题,Redis也给出了方案Redis Cluster

1.2 Redis Sentinel的高可用

Redis Sentinel是一个分布式架构,包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当发现节点不可达时,会对节点做下线标识。

如果被标识的是主节点,他还会选择和其他Sentinel节点进行“协商”,当大多数的Sentinel节点都认为主节点不可达时,他们会选举出一个Sentinel节点来完成自动故障转移工作,同时将这个变化通知给Redis应用方。

整个过程完全自动,不需要人工介入,所以可以很好解决Redis的高可用问题。

接下来我们就通过部署一个Redis Sentinel实例来了解整体框架。

2. Redis Sentinel部署

我们部署的拓扑结构如图所示:

这里写图片描述

分别有3个Sentinel节点,1个主节点,2个从节点组成一个Redis Sentinel

roleIPport
master127.0.0.16379
slave1127.0.0.16380
slave2127.0.0.16381
Sentinel1127.0.0.126379
Sentinel2127.0.0.126380
Sentinel3127.0.0.126381

2.1 启动主节点

  • 配置:
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/"
  • 启动主节点
➜   sudo redis-server redis-6379.conf
  • 使用PING命令检测是否启动
➜   redis-cli -h 127.0.0.1 -p 6379 ping
PONG

2.2 启动两个从节点

  • 配置(两个从节点配置相同,除了文件名有区分)
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/" 
slaveof 127.0.0.1 6379      // 从属主节点
  • 启动两个从节点
➜   sudo redis-server redis-6380.conf 
➜   sudo redis-server redis-6381.conf 
  • 使用PING命令检测是否启动
➜   redis-cli -h 127.0.0.1 -p 6380 ping
PONG
➜   redis-cli -h 127.0.0.1 -p 6381 ping
PONG

2.3 确认主从关系

  • 主节点视角
➜   redis-cli -h 127.0.0.1 -p 6379 INFO replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=85,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=85,lag=0
......
  • 从节点视角(6380端口)
➜   redis-cli -h 127.0.0.1 -p 6380 INFO replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
......

确立中从关系,如下图所示:

这里写图片描述

2.4 部署Sentinel节点

3个Sentinel节点的部署方法是相同的(端口不同)。以26379为例。

  • 配置
// Sentinel节点的端口
port 26379  
dir /var/redis/data/
logfile "26379.log"

// 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
// 2代表判断主节点失败至少需要2个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6379 2

//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过30000毫秒且没有回复,则判定不可达
sentinel down-after-milliseconds mymaster 30000

//当Sentinel节点集合对主节点故障判定达成一致时,Sentinel领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作,限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1

//故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000
  • 启动(两种方法)
    • redis-sentinel sentinel-26379.conf
    • redis-server sentinel-26379.conf --sentinel
sudo redis-sentinel sentinel-26379.conf --sentinel
  • 确认
➜   redis-cli -h 127.0.0.1 -p 26379 INFO Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=1 //sentinels=1表示启动了1个Sentinel

部署三个Sentinel节点之后,真个拓扑结构如图所示:

这里写图片描述

  • 当部署号Redis Sentinel之后,会有如下变化
    • Sentinel节点自动发现了从节点、其余Sentinel节点。
    • 去掉了默认配置,例如:parallel-syncsfailover-timeout
    • 新添加了纪元(epoch)参数。

我们拿端口26379的举例,启动所有的Sentinel和数据节点后,配置文件如下:

port 26379
dir "/var/redis/data"
sentinel myid 70a3e215c1a34b4d9925d170d9606e615a8874f2
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel config-epoch mymaster 0
sentinel leader-epoch mymaster 0
daemonize yes
logfile "26379.log"
// 发现了两个从节点
sentinel known-slave mymaster 127.0.0.1 6381
sentinel known-slave mymaster 127.0.0.1 6380
// 发送了连个Sentinel节点
sentinel known-sentinel mymaster 127.0.0.1 26381 e1148ad6caf60302dd6d0dbd693cb3448e209ac2
sentinel known-sentinel mymaster 127.0.0.1 26380 39db5b040b21a52da5334dd2d798244c034b4fc3
sentinel current-epoch 0

2.5 故障转移实验

先查看一下节点的进程pid

➜   ps -aux | grep redis
root     18225  0.1  0.0  40208 11212 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6379
root     18234  0.0  0.0  38160  8364 ?        Ssl  22:10   0:04 redis-server 127.0.0.1:6380
root     18244  0.0  0.0  38160  8308 ?        Ssl  22:10   0:04 redis-server 127.0.0.1:6381
root     20568  0.1  0.0  38160  8460 ?        Ssl  23:05   0:02 redis-sentinel *:26379 [sentinel]
root     20655  0.1  0.0  38160  8296 ?        Ssl  23:07   0:02 redis-sentinel *:26380 [sentinel]
root     20664  0.1  0.0  38160  8312 ?        Ssl  23:07   0:02 redis-sentinel *:26381 [sentinel]

我们干掉端口6379的主节点。

➜   sudo kill -9 18225
➜   ps -aux | grep redis
root     18234  0.0  0.0  38160  8364 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6380
root     18244  0.0  0.0  38160  8308 ?        Ssl  22:10   0:05 redis-server 127.0.0.1:6381
root     20568  0.1  0.0  38160  8460 ?        Ssl  23:05   0:03 redis-sentinel *:26379 [sentinel]
root     20655  0.1  0.0  38160  8296 ?        Ssl  23:07   0:03 redis-sentinel *:26380 [sentinel]
root     20664  0.1  0.0  38160  8312 ?        Ssl  23:07   0:03 redis-sentinel *:26381 [sentinel]

此时,Redis Sentinel对主节点进行客观下线(Objectively Down, 简称 ODOWN)的判断,确认主节点不可达,则通知从节点中止复制主节点的操作。

这里写图片描述

当主节点下线时长超过配置的下线时长30000秒,Redis Sentinel执行故障转移操作。

此时,我们查看一下Sentinel节点监控的主节点信息:

127.0.0.1:26379> sentinel masters 
1)  1) "name"
    2) "mymaster"
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6380"           //可以看到主节点已经成为6380端口的节点
    7) "runid"
    8) "084850ab4ff6c2f2502b185c8eab5bdd25a26ce2"
    9) "flags"
   10) "master"
    ..............

看一下Sentinel节点监控的从节点信息:

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"             //ip:port
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) ""
    9) "flags"
   10) "s_down,slave,disconnected"  //端口6379的原主节点已经断开了连接
   ..............
2)  1) "name"
    2) "127.0.0.1:6381"             
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6381"
    7) "runid"
    8) "24495fe180e4fd64ac47467e0b2652894406e9e4"
    9) "flags"
   10) "slave"                      //本来的从节点,还是从节点的role
    ..............

由以上信息可得,端口为6380的Redis数据节点成为新的主节点,端口为6379的旧主节点断开连接。如图所示:

这里写图片描述

我们在试着重启端口6379的数据节点。

➜   sudo redis-server redis-6379.conf 
➜   ps -aux | grep redis              
root     18234  0.1  0.0  40208 11392 ?        Ssl  522   0:06 redis-server 127.0.0.1:6380
root     18244  0.1  0.0  40208 10356 ?        Ssl  522   0:07 redis-server 127.0.0.1:6381
root     20568  0.1  0.0  38160  8460 ?        Ssl  522   0:05 redis-sentinel *:26379 [sentinel]
root     20655  0.1  0.0  38160  8296 ?        Ssl  522   0:05 redis-sentinel *:26380 [sentinel]
root     20664  0.1  0.0  38160  8312 ?        Ssl  522   0:05 redis-sentinel *:26381 [sentinel]
menwen   22475  0.0  0.0  14216  5920 pts/2    S+   522   0:00 redis-cli -p 26379
// 6379的数据节点已重启
root     22617  0.0  0.0  38160  8304 ?        Ssl  00:00   0:00 redis-server 127.0.0.1:6379   

看看发生什么:

127.0.0.1:26379> sentinel slaves mymaster
1)  1) "name"
    2) "127.0.0.1:6379"     //6379端口的节点重启后,变成了"活"的从节点
    3) "ip"
    4) "127.0.0.1"
    5) "port"
    6) "6379"
    7) "runid"
    8) "de1b5c28483cf150d9550f8e338886706e952346"
    9) "flags"
   10) "slave"
    ..............
2)  1) "name"               //6381端口的节点没有变化,仍是从节点
    2) "127.0.0.1:6381"
    ..............

他被降级成为端口6380的从节点。

这里写图片描述

从上面的逻辑架构和故障转移试验中,可以看出Redis Sentinel的以下几个功能。

  • 监控Sentinel节点会定期检测Redis数据节点和其余Sentinel节点是否可达。
  • 通知Sentinel节点会将故障转移通知给应用方。
  • 主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。
  • 配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节点集合,从中获取主节点信息。

3. Sentinel配置说明

  • sentinel monitor mymaster 127.0.0.1 6379 2

    • 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
    • 2代表判断主节点失败至少需要2个Sentinel节点节点同意
    • mymaster是主节点的别名
  • sentinel down-after-milliseconds mymaster 30000

    • 每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达,如果超过30000毫秒且没有回复,则判定不可达
  • sentinel parallel-syncs mymaster 1

    • 当Sentinel节点集合对主节点故障判定达成一致时,Sentinel领导者节点会做故障转移操作,选出新的主节点,原来的从节点会向新的主节点发起复制操作,限制每次向新的主节点发起复制操作的从节点个数为1。
  • sentinel failover-timeout mymaster 180000

    • 故障转移超时时间为180000
  • sentinel auth-pass \ \
    • 如果Sentinel监控的主节点配置了密码,可以通过sentinel auth-pass配置通过添加主节点的密码,防止Sentinel节点无法对主节点进行监控。
    • 例如:sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
  • sentinel notification-script \ \
    • 在故障转移期间,当一些警告级别的Sentinel事件发生(指重要事件,如主观下线,客观下线等)时,会触发对应路径的脚本,想脚本发送相应的事件参数。
    • 例如:sentinel notification-script mymaster /var/redis/notify.sh
  • sentinel client-reconfig-script \ \
    • 在故障转移结束后,触发应对路径的脚本,并向脚本发送故障转移结果的参数。
    • 例如:sentinel client-reconfig-script mymaster /var/redis/reconfig.sh
  • 16
    点赞
  • 65
    收藏
    觉得还不错? 一键收藏
  • 17
    评论
尚硅谷是一个教育机构,他们提供了一份关于Redis学习笔记。根据提供的引用内容,我们可以了解到他们提到了一些关于Redis配置和使用的内容。 首先,在引用中提到了通过执行命令"vi /redis-6.2.6/redis.conf"来编辑Redis配置文件。这个命令可以让你进入只读模式来查询"daemonize"配置项的位置。 在引用中提到了Redis会根据键值计算出应该送往的插槽,并且如果不是该客户端对应服务器的插槽,Redis会报错并告知应该前往的Redis实例的地址和端口。 在引用中提到了通过修改Redis的配置文件来指定Redis的日志文件位置。可以使用命令"sudo vim /etc/redis.conf"来编辑Redis的配置文件,并且在文件中指定日志文件的位置。 通过这些引用内容,我们可以得出结论,尚硅谷的Redis学习笔记涵盖了关于Redis的配置和使用的内容,并提供了一些相关的命令和操作示例。<span class="em">1</span><span class="em">2</span><span class="em">3</span> #### 引用[.reference_title] - *1* [Redis学习笔记--尚硅谷](https://blog.csdn.net/HHCS231/article/details/123637379)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] - *2* *3* [Redis学习笔记——尚硅谷](https://blog.csdn.net/qq_48092631/article/details/129662119)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v93^chatsearchT3_2"}}] [.reference_item style="max-width: 50%"] [ .reference_list ]

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 17
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值