Redis集群故障监测及哨兵机制原理解析
Posted 踩踩踩从踩
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis集群故障监测及哨兵机制原理解析相关的知识，希望对你有一定的参考价值。
前言
上篇文章我解析了如何搭建主从集群，以及主从复制原理分析；本篇文章继续对集群继续沉入，以及常见运行时的检测工具，及哨兵机制原理的解析，以及遇到常见问题的处理
Redis客户端及监控集群
Redis在集群中数据同步流程
集成在spring中，实现就很简单，只要连接主节点即可，而对于从节点，是会自动发现的。并且在设置 ReadFrom.SLAVE_PREFERRED 时，会自动选择读写的情况
@Configuration
@Profile("replication-rw") // 主从 - 读写分离模式
public class ReplicationRWRedisAppConfig {
@Value("${redis_host}")
private String redisHost;
@Value("${redis_port}")
private int redisPort;
@Bean
public LettuceConnectionFactory redisConnectionFactory() {
System.out.println("使用读写分离版本");
LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
.readFrom(ReadFrom.SLAVE_PREFERRED)
.build();
// master:192.168.1.128 slave:192.168.1.145
// 默认slave只能进行读取，不能写入
// 如果你的应用程序需要往redis写数据，建议连接master
RedisStandaloneConfiguration serverConfig = new RedisStandaloneConfiguration(redisHost, redisPort);
return new LettuceConnectionFactory(serverConfig, clientConfig);
}
}Monitor命令
Info 命令
图形化监控工具 - RedisLive
这个工具git 地址 为：GitHub - nkrode/重新使用：可视化您的重新出现实例，分析查询模式和峰值。
可视化您的重新出现实例，分析查询模式和峰值。
作为一款开源的 Redis 图形化监控工具，RedisLive 提供对 Redis 实例的内存使用情况，接收的客户端命令，接收的请求数量以及键进行监控。RedisLive 的工作原理基于 Redis 的 INFO 和 MONITOR 命令，通过向 Redis 实例发送 INFO 和 MONITOR 命令来获取 Redis 实例当前的运行数据。
安装 则直接使用git 命令
git clone https://github.com/kumarnitin/RedisLive.git哨兵机制(Sentinel)
Redis Sentinel是一个分布式系统，为Redis提供高可用性解决方案。可以在一个架构中运行多个 Sentinel 进程(progress)， 这些进程使用流言协议(gossip protocols)来 接收关于主服务器是否下线的信息， 并使用投票协议(agreement protocols)来决定是否执行自动故 障迁移， 以及选择哪个从服务器作为新的主服务器。
如何配置一个哨兵高可用搭建，可以按照下面的文档进行搭建
# 云服务器要注意ip要写对，端口要开放
# 虚拟机要注意防火墙要关闭 systemctl stop firewalld.service# 配置文件：sentinel.conf，在sentinel运行期间是会被动态修改的
# sentinel如果重启时，根据这个配置来恢复其之前所监控的redis集群的状态
# 绑定IP
bind 0.0.0.0
# 后台运行
daemonize yes
# 默认yes，没指定密码或者指定IP的情况下，外网无法访问
protected-mode no
# 哨兵的端口，客户端通过这个端口来发现redis
port 26380
# 哨兵自己的IP，手动设定也可自动发现，用于与其他哨兵通信
# sentinel announce-ip
# 临时文件夹
dir /tmp
# 日志
logfile "/usr/local/redis/logs/sentinel-26380.log"
# sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡
sentinel monitor mymaster 192.168.100.241 6380 2
# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 1000
# 如果在该时间（ms）内未能完成failover操作，则认为该failover失败
sentinel failover-timeout mymaster 3000
# 指定了在执行故障转移时，最多可以有多少个从Redis实例在同步新的主实例，在从Redis实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel parallel-syncs mymaster 1启动 直接使用 /usr/local/redis/bin/redis-server /usr/local/redis/conf/sentinel-26380.conf --sentinel 启动既可
在spring中配置
@Configuration
@Profile("sentinel")
public class SentinelRedisConfig {
@Bean
public LettuceConnectionFactory redisConnectionFactory() {
System.out.println("使用哨兵版本");
RedisSentinelConfiguration sentinelConfig = new RedisSentinelConfiguration()
.master("mymaster")
// 哨兵地址
.sentinel("192.168.100.16", 26379)
.sentinel("192.168.100.8", 26380)
.sentinel("192.168.100.8", 26381);
return new LettuceConnectionFactory(sentinelConfig);
}
}这个名字和配置文件中的名字对应就好
哨兵(Sentinel)核心机制
- 简化客户端的配置选择，客户端只用配置好哨兵的地址即可，无需连接主节点
-
引入哨兵机制，哨兵通过ping去感知监控、通知、自动故障转移、配置提供。
-
主节点故障 ，选则到新的主节点， slave of no one 将新的主节点选择，并将从节点的主节点重新设置。
-
哨兵中有主观下线， 和客观下线，当一台哨兵认为下线时是主观下线，只有大多数哨兵认为下线则认为是客观下线，真的下线，可以配置参数去设置
服务发现和健康检查流程
故障切换流程
哨兵常见的命令
直接通过sentilnel sentinels 进行查看哨兵的端口号等等
利用哨兵的命令 使用sentinel slaves mymaster就可以查看从节点信息
在哨兵或者redis服务中，由于网络中断有可能出现分布式的情况下出现脑裂的情况，因为有大多数的机制，因此并不存在这个问题，如果出现网络隔断，没有达到大多数的情况，则会不能使用，当重新连接上时，在根据offset进行数据更新
哨兵7大核心概念
1. 哨兵如何知道Redis主从信息（自动发现机制）
# sentinel监控的master的名字叫做mymaster,初始地址为 192.168.100.241 6380,2代表两个及以上哨兵认定为死亡，才认为是真的死亡
sentinel monitor mymaster 192.168.100.241 6380 22. 什么是master主观下线
# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 10003. 什么是客观下线
客观下线：一定数量的哨兵任务master已经下线。
# 发送心跳PING来确认master是否存活
# 如果master在“一定时间范围”内不回应PONG 或者是回复了一个错误消息，那么这个sentinel会主观地(单方面地)认为这个master已经不可用了
sentinel down-after-milliseconds mymaster 1000
4. 哨兵之间如何通信（哨兵之间的自动发现）
如果是多哨兵模式，哨兵节点之间也是可以相互感知的
如下是在Redis主从复制的基础上，依次启用三个哨兵节点的后，sentinel.cnf的变化情况
可以发现，当启用了三个哨兵节点之后，sentinel.cnf配置文件会被自动重写，主要有一下几点，如
1，增加了一个sentinel myid （标识哨兵节点的唯一性）
2，自动追加哨兵节点本身的信息（这样哨兵节点之间就会相互自动发现），以及redis数据服务的slave的信息
3，自动移除主节点的密码
4，dir 的相对路径被修改为绝对路径
总的来说 通过发布订阅 pub/sub 通道去监听 通过2000的偏移量端口，进行通信。
5. 哪个哨兵负责故障转移？(哨兵领导选举机制)
1.每个在线的哨兵节点都可以成为领导者，当它确认（比如哨兵3）主节点下线时，会向其他哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移；
2.当其他哨兵收到此命令时，可以同意或者拒绝它成为领导者；
3.如果哨兵3发现自己在选举的票数大于等于哨兵的个数/2+1时，将会成为领导者，如果没有超过，继续选举。。。。
6. slave选举机制
slave的选举机制有个大多数机制，包括哨兵自己的选择，也遵从raft算法，这个比zookeeper中的paxos算法更简单一点
7. 最终主从切换的过程
以上是关于Redis集群故障监测及哨兵机制原理解析的主要内容，如果未能解决你的问题，请参考以下文章