关于redis:缓存服务器Redis-06-Redis哨兵机制

哨兵机制次要是为了实现 redis 的高可用, 即高度可用性, 不会轻易宕机.

高可用实现

高可用实现前提

如果须要实现 Redis 服务器的高可用, 前提条件应该实现主从的配置.

复制哨兵目录

1. 敞开 redis 服务器 (敞开之前的分片)
2.cp -r shards sentinel 复制 shards 目录为 sentinel 目录
3.rm -f dump.rdb 删除长久化文件
4.redis-server 6379.conf & redis -server 6380.conf & redis-server 6381.conf & 运行 3 台服务器

实现主从挂载

1. 搭建规定:
1)6379 当作主机
2)6380/6381 当作从机
查看主从的状态: info replication

2. 实现主从的挂载 slaveof 主机 IP 主机端口

3. 对于主从挂载的特点
查看从机中的状态:

查看主机的状态:

4. 挂载谬误怎么做?
阐明: 因为误操作可能导致主从的构造挂载异样. 如何从新挂载呢?
操作阐明: 能够将 redis 服务器全副敞开, 之后重启 默认条件下的主从的挂载则会生效. 从新挂载即可.
补充阐明: 因为 slaveof 指令在内存中失效. 如果内存资源开释, 则主从的关系将生效. 为了实现永恒无效, 应该将主从的关系写在配置文件中即可.

问题

从下面晓得主从关系是写在配置文件中的, 可是如果主机意外宕机了, 那么由谁来批改配置文件呢?

哨兵

哨兵的工作原理

1. 当哨兵启动时, 会监控以后的主机信息. 同时获取链接以后主机的从机信息.
2. 当哨兵利用 心跳检测机制(PING-PONG), 测验主机是否失常. 如果间断 3 次发现主机没有响应信息. 则开始进行选举.
3. 当哨兵选举实现之后. 其余的节点都会当做新主机的从机.

哨兵机制实现

1. 复制哨兵配置文件:cp sentinel.conf sentinel/

2. 批改配置文件:
1). 批改保护模式:protected-mode no
2). 开启后盾运行:daemonize yes
3). 批改哨兵的监控, 其中的 1 示意投票失效的数量(如:3 人投票 2 票失效):
sentinel monitor mymaster 192.168.126.129 6379 1
4). 哨兵宕机之后的选举工夫:
sentinel down-after-milliseconds mymaster 10000
5). 批改哨兵选举的超时工夫:
sentinel failover-timeout mymaster 20000

3. 哨兵高可用测试:
1). 启动哨兵:redis-sentinel sentinel.conf
2). 先敞开主机, 之后期待 10 秒之后, 查看从机是否入选主机. 之后再次启动主机(宕机的), 查看是否为新主机的从

哨兵选举平票阐明

如果有多个哨兵进行选举, 如果 间断 3 次 投票失败, 可能引发 脑裂 景象的产生.
脑裂景象产生的概率是 1 /8 = 12.5%
解决策略: 只有 减少选举的节点的数量, 能够无效的升高脑裂景象的产生.

SpringBoot 链接哨兵入门案例

   /**
     * 哨兵的测试
     * 参数阐明:  masterName: 主机的变量名称
     *           sentinels:   链接哨兵的汇合.
     * 了解: 哨兵尽管链接 3 台 redis. 然而 3 台 redis 中存储的数据都是一样的. 对于用户而言
     * 就是一台.
     */
    @Test
    public void testSentinel(){Set<String> sets = new HashSet<>();
        sets.add("192.168.126.129:26379");//26379 为哨兵端口
        JedisSentinelPool sentinelPool =
                new JedisSentinelPool("mymaster",sets);
        Jedis jedis = sentinelPool.getResource();
        jedis.set("aaa", "wt");
        System.out.println(jedis.get("aaa"));
        jedis.close();}

哨兵与分片总结

分片:
1. 次要的作用实现内存 数据的扩容 .
2. 因为 运算产生在业务服务器 中, 所以执行的 效率更高 .
3.Redis 的 分片没有高可用 的成果. 如果其中一个节点呈现了问题则导致程序运行出错.

哨兵:
1. 实现 Redis高可用 , 当 redis 服务器产生宕机的景象时, 哨兵能够灵便的监控. 实现 主动的选举实现, 故障的迁徙 .
2. 哨兵中所监控的 redis 节点中的数据都是雷同的 . 无奈实现海量的数据存储.
3. 哨兵尽管能够实现 redis 的高可用, 然而因为 哨兵的自身没有实现高可用 . 所以存在危险.
如果想要最大水平上缩小损耗, 则倡议不要引入第三方的监控!