Redis Sentinel

高可用架构-Redis Sentinel

Replication 缺点

接着之前的Redis Replication 主从复制架构,看似解决了主节点并发过大时,master节点处理繁忙的问题。将一部分读数据的请求交给从节点处理,从而将请求进行分散处理。但是该架构却存在很明显的缺陷:

  • 主节点写请求过大,从节点数据同步存在延迟。该架构适用于数据实时性要求不高的场景
  • 从节点宕机、数据延迟过大时,一些特殊的场景会存在问题,如使用Redis实现分布式锁,锁失效问题
  • 节点宕机 不能自动进行服务重启、故障转移 需要人工干预

关于Redis Replication 环境搭建请点击**这里**

主节点宕机

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=::1,port=6380,state=online,offset=21996,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=21996,lag=1
....

如上图,现在一主两从的复制架构,运行正常。现在人工模拟下主节点宕机,使用 kill 命令杀掉进程:

# 查找pid
AndydeMacBook-Pro:~ andy$ ps -ef | grep redis
  501 93666     1   0 五04上午 ??         0:51.18 redis-server 127.0.0.1:6380 
  501 93670     1   0 五04上午 ??         0:52.42 redis-server 127.0.0.1:6379 
  501 97406     1   0 11:14上午 ??         0:02.56 redis-server 127.0.0.1:6381 
# 杀死进程
AndydeMacBook-Pro:~ andy$ kill -9 93670

从节点状态

使用redis-cli客户端分别查看6380、6381的服务状态。

AndydeMacBook-Pro:~ andy$ redis-cli -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:localhost
master_port:6379
master_link_status:down
AndydeMacBook-Pro:~ andy$ redis-cli -p 6381
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down

人工干预

  • 直接重启主节点

  • 主节点服务器不可用 - 人工设置其他节点为主节点

    # 设置6381 为主节点
    AndydeMacBook-Pro:~ andy$ redis-cli -p 6381
    127.0.0.1:6381> slaveof no one
    OK
    
    # 查看服务状态 已经为master节点 但是没有从节点连接
    127.0.0.1:6381> info replication
    # Replication
    role:master
    connected_slaves:0
    master_failover_state:no-failover
    
    # 设置6380端口为从节点
    AndydeMacBook-Pro:redis-stable andy$ redis-cli -p 6380
    127.0.0.1:6380> slaveof localhost 6381
    OK
    
    # 重新查看主节点 连接状态 此时 6380 已经连接
    127.0.0.1:6381> info replication
    # Replication
    role:master
    connected_slaves:1
    slave0:ip=::1,port=6380,state=online,offset=42,lag=1
    

注意: slaveof 命令的有效期只针对当前Redis实例,当Redis重启时,设置失效,更为保险的方法是将相关的设置放到redis.conf 配置文件中。

至此处理完毕,过程不免有些繁杂。当Redis集群非常庞大时,人工干预的过程会演变成巨大的工作量。其次,主节点宕机会造成主从架构所有写请求失败,从而导致整个应用系统不可用,因此需要更为合理的架构解决该问题。Redis Sentinel应运而生。

Sentinel 架构

Redis Sentinel是用于故障自动发现、自动切换的一套高可用的服务架构,其目的是为了解决生产环境中Redis的单点故障。通常情况下Sentinel需要监多个redis实例,并作为决策者,底层原理是利用ping-pong 确定Redis实例的存活状态,当检测到Redis实例不可用时,自动进行切换。

这个流程对Redis-Client 是透明的,无感的。简而言之,Sentinel是Redis的故障切换管理器。今天来学习下,如何使用Sentinel在单机部署一个简单的高可用性Redis架构,如下图所示:

在这里插入图片描述

新增配置

# 在sentinel.conf 配置文件中加入一下配置
sentinel monitor mymaster 127.0.0.1 6379 1
sentinel down-after-milliseconds mymaster 10000

语法说明:

sentinel monitor <master-group-name> <ip> <port> <quorum>
# <master-group-name> - 集群名称
# <ip> - ip
# <port> - port
# <quorum> - Sentinels集群检测故障的数量 如配置为2 则表示至少需要2个sentinel节点认证节点不可达,才踢出集群
sentinel <option_name> <master_name> <option_value>
# <master-group-name> - 集群名称
# <option_name>
# 		down-after-milliseconds - 指定毫秒时间内 收不到ping心跳信息 则踢出集群,此时 <option_value> 为时间
#			parallel-syncs - 指定重新选取主节点时,从节点并行同步的数量 设置为1 则表示 每次只能复制一个

启动sentinel

# redis 安装完成后 相关脚本在 /usr/local/bin/ 目录下,包含 redis-sentinel
AndydeMacBook-Pro:redis-stable andy$ redis-sentinel sentinel.conf 

在这里插入图片描述

查看状态

redis-cli -p 26379 sentinel masters

在这里插入图片描述

验证测试

至此Redis Sentinel 架构已经在本地机器搭建完毕,现在手动关闭主节点,确认是否会自动进行转移

AndydeMacBook-Pro:replica andy$ ps -ef | grep redis
  501 98417     1   0 12:36下午 ??         0:01.44 redis-server 127.0.0.1:6379 
  501 98422     1   0 12:37下午 ??         0:01.34 redis-server 127.0.0.1:6380 
  501 98424     1   0 12:37下午 ??         0:01.36 redis-server 127.0.0.1:6381 
  501 98410 93729   0 12:36下午 ttys001    0:00.90 redis-sentinel *:26379 [sentinel] 
AndydeMacBook-Pro:replica andy$ kill -9 98417

在这里插入图片描述

如上图,从Sentinel的输出的信息中得知 主节点已经自动转移到6381端口。

重启6379节点,查看确认是否为6381的从节点

AndydeMacBook-Pro:replica andy$ redis-cli -p 6381 info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=54013,lag=1
slave1:ip=127.0.0.1,port=6379,state=online,offset=54013,lag=1
master_failover_state:no-failover
....

常用命令

# 获取指定集群的主节点 ip 地址
AndydeMacBook-Pro:~ andy$ redis-cli -p 26379
127.0.0.1:26379> SENTINEL get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6381"
# 设置集群 下线检测时间
127.0.0.1:26379> SENTINEL SET mymaster down-after-milliseconds 1000
OK
# 设置集群 下线判断数量 
127.0.0.1:26379> SENTINEL SET mymaster quorum 5
OK
# 设置集群 连接账号、密码
sentinel auth-user mymaster username
sentinel auth-pass mymaster password

总结

Redis Sentinel架构使用故障自动转移的机制,解决主从复制架构中,主节点出现单点故障的问题,通过选举机制实则其他从节点升级为主节点。从而让整个架构故障自动转移、平滑过渡、无需运维人员手工干预。在分布式环境下,Redis Sentinel 被设计为多个Sentinel 进程协同工作,Sentinel 集群的优势包含:

  • 降低误报 - 多个Sentinel一致认为给定的主机不再可用时,执行故障检测。这降低了误报的概率。
  • 解决单点故障 - 即时小部分Sentinel节点出现故障,整个Sentinel集群也能正常运行,提高系统高可用性
  • 4
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值