架构-Redis哨兵(Sentinel)模式

it2023-09-19  78

一、主从复制高可用

当我们使用主从复制出现的问题

手动故障转移写能力和存储能力受限主从复制 -master 宕机故障处理

主从切换技术的方法是:当主服务器宕机后,需要手动把一台从服务器切换为主服务器,这就需要人工干预,费事费力,还会造成一段时间内服务不可用。这不是一种推荐的方式,更多时候,我们优先考虑哨兵模式。

福利 福利  福利 免费领取Java架构技能地图  注意了是免费送 

 

免费领取  要的+V 领取


~哨兵模式概述

哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例。

哨兵主要有两个作用

通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。

当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。

故障切换(failover)的过程。假设主服务器宕机,哨兵1先检测到这个结果,系统并不会马上进行failover过程,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线。这样对于客户端而言,一切都是透明的。

二、架构说明

多个sentinel 发现并确认master有问题。选举出一个sentinel作为领导选出一个slave作为master通知其余的slave成为新的master的slave通知客户端主从变化等待老的master复活成新的master的slave

三、安装配置

配置主从节点 主节点 启动命令:redis-server redis-7000.conf 复制代码

配置

port 7000 daemonize yes pidfile /var/run/redis-7000.pid logfile "7000.log" dir "/opt/soft/redis/data/" 复制代码 Redis从节点 redis-server redis-7001.conf redis-server redis-7002.conf 复制代码

slave-1:

port 7002 daemonize yes pidfile /var/run/redis-7002.pid logfile "7002.log" dir "/opt/soft/redis/data/" slaveof 127.0.0.1 7000 复制代码

slave-2:

port 7001 daemonize yes pidfile /var/run/redis-7001.pid logfile "7001.log" dir "/opt/soft/redis/data/" slaveof 127.0.0.1 7000 复制代码 配置开启sentinel监控主节点 sentine 主要配置 编辑 sentinel.conf port ${port} dir "/opt/soft/redis/data/" logfile "${port}.log" // 配置监听的主服务器,这里sentinel monitor代表监控,mymaster代表服务器的名称,可以自定义,192.168.11.128代表监控的主服务器,6379代表端口,2代表只有两个或两个以上的哨兵认为主服务器不可用的时候,才会进行failover操作。 sentinel monitor mymaster 127.0.0.1 7000 2 sentinel down-after-millseseconds mymaster 30000 //判断主节点时间 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 复制代码

启动

redis-sentinel sentinel.conf 复制代码

可以使用 ps -ef|grep redis-sentinel 命令查看进程、


四、实现原理

故障转移 --- java实现 /** * 测试Redis哨兵模式 * @author liu */ public class TestSentinels { @SuppressWarnings("resource") @Test public void testSentinel() { JedisPoolConfig jedisPoolConfig = new JedisPoolConfig(); jedisPoolConfig.setMaxTotal(10); jedisPoolConfig.setMaxIdle(5); jedisPoolConfig.setMinIdle(5); // 哨兵信息 Set<String> sentinels = new HashSet<>(Arrays.asList("127.0.0.1:26379","1127.0.0.1:26379","127.0.0.1:26379")); // 创建连接池 JedisSentinelPool pool = new JedisSentinelPool("mymaster", sentinels,jedisPoolConfig,"123456"); // 获取客户端 Jedis jedis = pool.getResource(); // 执行两个命令 jedis.set("mykey", "myvalue"); String value = jedis.get("mykey"); System.out.println(value); } } 复制代码

如果我们把主服务器停掉,在经过一段时间的报错后,redis集群会恢复

主观下线和客观下线

主观下线:当前sentintel节点认为某个redis节点不可用。

客观下线:所有sentinel节点认为某个redis节点不可用。

三个定时任务 每10秒每个sentinel对master 和 slave执行info 发现slave节点确认主从关系每2秒每个sentinel通过master节点对channel交换信息(发布订阅) 通过sentinel:hello频道交互交互对节点的“看法”和自身信息每1秒每个sentinel 对其他sentinel和redis执行ping

领导者选举

只需要一个sentinel节点完成故障转移

通过sentinel is - master -down -by-addr 命令都希望成为领导者

-1. 每个主观下线都Sentitle 节点向其他Sentinel节点发送命令,要求将它设置为领导者 -2. 收到命令对Sentinel节点如果没有同一通过其他Sentinel节点发送的命令,那么就将同一该请求,否则拒绝 -3. 如果该Sentinel节点发现直接的票数已经超过Sentinel集合半数且超过quorum,那么它将成为领导者 -4. 如果此过程由多个Sentinel节点成为领导者,那么将来等待一段时间重新进行选举 复制代码

故障转移(Sentinel领导者节点完成)

1.从slave节点中选出一个 “合适点”节点作为master节点2.对上面对slave节点执行slaveof no one 命令让其成为master节点。3.向剩余的slave节点发送命令,让它们成为新的maater节点的slave节点,复制规避和parallel-syncs参数有关4.更新对原来master节点配置为slave,并保持着对其 “关注”,当其恢复后命令他去复制新对master节点

选择 “合适的” slave节点

1.选择slave-priority(slave节点优先级)最高对slave节点,如果存在返回,不存在继续2.选择复制偏移量最大的slave节点,复制最完整,存在返回,不存在继续3.选择runId最小的slave节点

五、需要说明的问题

尽可能在不同物理机上和同一个网络部署Redis sentinel的所有节点Redis sentinel中的sentinel节点个数应该大于等于3且最好是奇数。(节点数多可以保证高可用)Redis sentinel中的数据节点和普通数据节点没有区别。每个sentinel节点在本质上还是一个Redis实例,只不过和Redis数据节点不同的是,其主要作用是监控Redis数据节点客户端初始化时连接的是sentinel节点集合,不再是具体的Redis节点,但sentinel只是配置中心不是代理。

 

最新回复(0)