redis 2.8 以后提供了 Redis Sentinel 哨兵机制,如果主实例宕机,哨兵将一台从机升级为主机,实现高可用。上一篇记录了redis哨兵集群搭建,这里验证高可用
-
模式类型
主从模式(redis2.8版本之前的模式)、哨兵sentinel模式(redis2.8及之后的模式)、redis cluster模式(redis3.0版本之后),我们这里说的是第二种 哨兵sentinel模式 -
主从复制特点
1、一个master可以有多个slave
2、一个slave只能有一个master
3、数据流向是单向的,master到slave -
redis sentinel(哨兵)
哨兵负责监控redis节点,当主实例宕机,则通过选举机制,把一个从节点升级为主节点,原来的主节点降级为从节点 -
图解
-
故障转移
我们先用info replication查看一下三个节点的状态
很明显看出6379是master主节点,6380、6381是slave从节点
这时候我们关掉端口6379的主节点,再info replication看看,很明显6380的从节点升级为了主节点
我们再次启动6379的redis,原来6379的主节点降级为了slave的从节点
-
代码验证一下
pom.xml
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>2.9.0</version>
</dependency>
public class JedisClusterClient {
public static void main(String[] args) {
Set<String> sentinels = new HashSet<>(Arrays.asList("192.168.33.76:26379","192.168.33.76:26380","192.168.33.76:26381"));
GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig();
JedisSentinelPool pool = new JedisSentinelPool("mymaster",sentinels,poolConfig);
Jedis jedis = pool.getResource();
jedis.set("test_msg","test_value");
String test_value = jedis.get("test_msg");
System.out.println("redis获取的值:"+test_value);
jedis.close();
}
}
run完main方法,看到已经写进redis的一个值了
然后我们在主节点和从节点都看到有这个key的值了
当6379的节点挂了之后我们再run一下,结果也是正常的,因为6380的从节点升级为主节点,redis哨兵模式实现了高可用