高可用架构-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 集群的优势包含：