标签：主机 redis 哨兵 6379 6381 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中的数据不能实现内存的扩容.哨兵服务本身没有实现高可用.如果哨兵发生了异常则直接影响用户使用.

标签：主机,redis,哨兵,6379,6381,sentinel
来源： https://www.cnblogs.com/zpKang/p/13512119.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。