redis哨兵机制 (sentinel)

redis哨兵机制 (sentinel)

哨兵机制原理

1. 首先启动Redis哨兵.由哨兵监控整个Redis主从状态. 主要监控M主机. 同时获取其从机的信息.
2. 哨兵利用心跳检测机制(PING-PONG)的方式监控主机是否宕机. 如果连续3次主机没有响应.则哨兵判断主机宕机. 之后开始进行选举.
3. 根据从主机中获取的从机信息.之后利用 选举机制算法.挑选新的主机.
4. 之后将剩余的redis修改为当前主机的的从.并且修改配置文件.

Redis主从搭建

前提条件: 如果要实现redis高可用机制,则必须首先实现主从搭建.
主从关系设定: 6379当做主机-Master 6380/6381 从机-Slave

1. 准备前提

关闭所有redis服务

ps =ef | grep redis 查看redis进程

kill -9 pid 根据pid杀死redis进程

创建sentinel目录, 并复制3份配置文件到sentinel目录, 文件名为 6379.conf, 6380.conf, 6381.conf

更改每个配置文件中对应的端口号即生成的rdb文件名

启动3个配置文件的redis服务

2. 检查主从关系

命令格式: (进入redis中使用以下命令)

info replication

三个redis的服务查看的结果 role 均为master, 即都没有主从关系

配置主从, 进入6380端口和6381端口的redis客户端 redis-cli -p 6380, 和 redis-cli -p 6381

均执行如下命令进行主从配置: 格式 slave of 主机IP 主机端口

3. 配置主从关系

命令格式: 在redis中使用

 slave of   主机IP 主机端口

6380和6381均执行如下配置即可绑定与主机的主从关系

slave of 192.168.126.129 6379

即6380和6381均为6379的从服务器

4. 再次检查主从关系

3个redis服务均执行执行

info replication

发现6380和6381的结果部分如下

role: slave
master_host: 192.168.126.129
master_port: 6379

6379部分结果如下

role: master

然后我们可以进行测试, 在6379端口的redis中 set a 123

在6380和6381中执行keys * 是否有a的数据, 在进行get a 结果是否为123, 如果有, 并结果正确则说明配置主从关系成功

说明

当redis服务器已经配置了主从结构之后.如果将服务器宕机.之后再次重启.则发现从服务器又会变为主机!!!
问题说明: 执行了主从挂载命令 该命令一直保存在内存中.当redis服务器重启之后,该命令失效.如果想要一直保持主从的关系.则必须将主从的结构写入Redis.conf的配置文件中.

上面内容大致意思为: redis重启后, 主从关系会失效, 如果需要永久保持, 需要更改sentinel.conf哨兵配置文件

Redis实现哨兵机制

实现哨兵机制建立在主从关系之上

1. 复制Redis哨兵配置文件

将redis目录下的sentinel.conf配置文件复制到sentinel目录中去

2. 修改配置文件

sentinel.conf配置文件修改内容如下:

# 关闭保护模式, 大约在17行
protected-mode no

# 默认端口号, 大约在21行
port 26379

# 开启后台启动, 大约在26行
daemonize yes

修改哨兵监控配置

# 监控主机的ip和端口, 最后的1代表选举生效的票数, 大约在84行
# mymaster为变量名称, springboot整合的时候需要用到此名称
sentinel monitor mymaster 192.169.126.129 6379 1

修改哨兵选举的时间,

# 当redis主机宕机之后, 哨兵多久开始选举, 单位毫秒, 大学在113行
sentinel down-after-milliseconds mymaster 10000

选举超时时间设定

# 如果当主机的服务器在规定的时间之内, 没有完成切换, 则哨兵重新选举, 
# 单位毫秒, 大约在146行
sentinel failover-timeout mymaster 180000

3. 启动哨兵

启动命令: 也是基于配置文件启动

redis-sentinel sentinel.conf

4. 测试

目前6379数据发生变化, 6380和6381也跟着变化

现在假设主服务宕机, 即关闭6379端口的redis redis-cli -p 6379 shutdown

之后等待10秒, 再次查看6380和6381, 使用info replication 命令

发现现在6381被选举为主服务器, 6380 依然是从服务器

再次启动6379服务器, 发现6379服务器重启后为从服务器, 被选举的6381依然为主服务器

我们可以查看6379的日志 tail -10 6379.conf 查看后10行, 发现已经标识了6381为主服务器

进入6379的redis客户端, 执行info replication命令, 发现 部分内容如下

role: slave
master_host: 192.168.126.129
master_port: 6381

springboot 哨兵入门案例

确定redis的maven的依赖已经导入

入门案例

public class TestSentinel { //主要完成哨兵测试

    /**
     * JedisSentinelPool参数说明:
     *   masterName: 主机名称, 即在sentinel.conf中配置的名称
     *   sentinels:  哨兵节点信息.
     */
    @Test
    public void test01(){
        Set<String> sentinels = new HashSet<>();
        String node = "192.168.126.129:26379"; // 哨兵的ip和端口
        sentinels.add(node); // 如果有多个哨兵, 可以都添加进来
        JedisSentinelPool sentinelPool =
                new JedisSentinelPool("mymaster", sentinels);
        Jedis jedis = sentinelPool.getResource(); //获取资源 (获取Jedis对象)
        jedis.set("sentinel", "redis哨兵机制配置成功!!!!"); // 数据存入缓存
        System.out.println(jedis.get("sentinel")); // 从缓存中取出数据
    }

}

如果结果能正常输出, 就大功告成了.

Redis分片/Redis哨兵总结

1. 分片可以实现Redis内存数据的扩容.可以存储海量的内存数据. Redis分片机制没有实现高可用.如果分片中一个节点宕机,则直接影响整个服务的运行.
2. 哨兵可以实现Redis节点的高可用.但是Redis中的数据不能实现内存的扩容.哨兵服务本身没有实现高可用.如果哨兵发生了异常则直接影响用户使用.