Redis哨兵功能与集群搭建

Posted 2020-11-29 怀心抱素

6.redis哨兵功能

Redis-Sentinel

Redis-Sentinel是redis官方推荐的高可用性解决方案，当用redis作master-slave的高可用时，如果master本身宕机，redis本身或者客户端都没有实现主从切换的功能。

而redis-sentinel就是一个独立运行的进程，用于监控多个master-slave集群，自动发现master宕机，进行自动切换slave > master。

sentinel主要功能如下：

• 不时的监控redis是否良好运行，如果节点不可达就会对节点进行下线标识
• 如果被标识的是主节点，sentinel就会和其他的sentinel节点“协商”，如果其他节点也认为主节点不可达，就会选举一个sentinel节点来完成自动故障转义
• 在master-slave进行切换后，master_redis.conf、slave_redis.conf和sentinel.conf的内容都会发生改变，即master_redis.conf中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令
 
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。

如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。

当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线

在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令

当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次

若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除。

若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

主观下线和客观下线

主观下线：Subjectively Down，简称 SDOWN，指的是当前 Sentinel 实例对某个redis服务器做出的下线判断。
客观下线：Objectively Down， 简称 ODOWN，指的是多个 Sentinel 实例在对Master Server做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，然后开启failover.

SDOWN适合于Master和Slave，只要一个 Sentinel 发现Master进入了ODOWN， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对下线的主服务器执行自动故障迁移操作。

ODOWN只适用于Master，对于Slave的 Redis 实例，Sentinel 在将它们判断为下线前不需要进行协商， 所以Slave的 Sentinel 永远不会达到ODOWN。

redis命令:

redis-cli info             #查看redis数据库信息

redis-cli info replication #查看redis的复制授权信息

redis-cli info sentinel    #查看redis的哨兵信息

环境准备

一主两从（3个redis数据库实例）,准备3个哨兵，用于投票选举新的主库

6379redis.conf 
port 6379
daemonize yes
logfile "6379.log"
dbfilename "dump-6379.rdb"
dir "/var/redis/data/"

6380redis.conf 
port 6380
daemonize yes
logfile "6380.log"
dbfilename "dump-6380.rdb"
dir "/var/redis/data/"
slaveof  127.0.0.1  6379
    
6381redis.conf 
port 6381
daemonize yes
logfile "6381.log"
dbfilename "dump-6381.rdb"
dir "/var/redis/data/"
slaveof  127.0.0.1  6379

配置Redis Sentinel

redis-sentinel-26379.conf配置文件写入如下信息

// 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毫秒30s且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 30000

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

//故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000

26380redis-sentinel.conf

port 26380  
dir /var/redis/data/
logfile "26380.log"
sentinel monitor mymaster  127.0.0.1  6379  2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
daemonize yes 

26381redis-sentinel.conf

port 26381  
dir /var/redis/data/
logfile "26381.log"
sentinel monitor mymaster  127.0.0.1  6379  2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000
daemonize yes 

启动三个哨兵

redis-sentinel redis-sentinel-26379.conf
redis-sentinel redis-sentinel-26380.conf
redis-sentinel redis-sentinel-26381.conf

查看哨兵是否成功通信

[root@linux redis-conf]# redis-cli -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=3

#看到最后一条信息正确即成功了哨兵，哨兵主节点名字叫做mymaster，状态ok，监控地址是127.0.0.:6379，有两个从节点，3个哨兵

redis高可用故障实验

1.杀掉6379redis进程

2.查看6380与6381状态

发现6381变成了master节点,6380变成了6380的slave节点

7. redis集群搭建

环境准备

6个redis数据库节点，准备6个配置文件，6个配置文件，仅仅是端口的区别

redis-7000.conf

port 7000
daemonize yes
dir "/opt/redis/data"
logfile "7000.log"
dbfilename "dump-7000.rdb"
cluster-enabled yes   # 开启集群模式
cluster-config-file nodes-7000.conf　　# 集群内部的配置文件
cluster-require-full-coverage no　　# redis cluster需要16384个slot都正常的时候才能对外提供服务，换句话说，只要任何一个slot异常那么整个cluster不对外提供服务。 因此生产环境一般为no

redis-7001.conf
redis-7002.conf
redis-7003.conf
redis-7004.conf
redis-7005.conf

分别运行6个redis的节点

redis-server 7000redis.conf 
redis-server 7001redis.conf 
redis-server 7002redis.conf 
redis-server 7003redis.conf 
redis-server 7004redis.conf 
redis-server 7005redis.conf

通过ruby脚本

一键开启redis-cluster ，自动分配槽位

yum install  ruby -y

# 安装ruby操作redis的模块
wget http://rubygems.org/downloads/redis-3.3.0.gem
# 通过ruby的包管理工具安装即可
gem install -l redis-3.3.0.gem

# 一键创建槽位
# create代表创建集群  
# --replicas 代表配置复制关系
# 后面的1代表，一主一从 

/opt/redis-4.0.10/src/redis-trib.rb   create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

查看集群状态

redis-cli -p 7000 cluster info  

redis-cli -p 7000 cluster nodes  
# 等同于查看nodes-7000.conf文件节点信息

# 集群主节点状态
redis-cli -p 7000 cluster nodes | grep master
# 集群从节点状态
redis-cli -p 7000 cluster nodes | grep slave

测试写入集群数据

登录集群必须使用redis-cli -c -p 7000必须加上-c参数

127.0.0.1:7000> set name chao     
-> Redirected to slot [5798] located at 127.0.0.1:7001   
OK
127.0.0.1:7001> exit
[root@yugo /opt/redis/src 18:46:07]#redis-cli -c -p 7000
127.0.0.1:7000> ping
PONG
127.0.0.1:7000> keys *
(empty list or set)
127.0.0.1:7000> get name
-> Redirected to slot [5798] located at 127.0.0.1:7001

redis客户端任意访问一个redis实例，如果数据不在该实例中，通过重定向引导客户端访问所需要的redis实例