Redis主从实现(哨兵)

1 Redis高可用实现前提

问题分析: 如果需要实现Redis服务器的高可用,前提条件应该实现主从的配置.

2 复制哨兵目录

前提:先关闭Redis服务器.
1).复制shards文件

2).删除持久化文件

3).运行3台Redis服务器

[root@localhost sentinel]# redis-server 6379.conf & redis             -server 6380.conf & redis-server 6381.conf &

3 实现主从挂载

搭建规则:

1. 6379 当作主机
2. 6380/6381 当作从机

检查主从的状态: info replication

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

4).关于主从挂载的特点
检查从机中的状态

检查主机的状态:

4 关于挂载错误的说明

说明:由于误操作可能导致主从的结构挂载异常.如何重新挂载呢?
操作说明:可以将redis服务器全部关闭,之后重启 默认条件下的主从的挂载则会失效. 重新挂载即可.

补充说明:由于slaveof指令在内存中生效.如果内存资源释放,则主从的关系将失效.为了实现永久有效,应该将主从的关系写在配置文件中即可.
新问题的产生: 如果主机意外宕机,则由谁来完成配置文件的修改呢?

哨兵的工作原理

哨兵工作原理说明
1.当哨兵启动时,会监控当前的主机信息.同时获取链接当前主机的从机信息.
2.当哨兵利用心跳检测机制(PING-PONG),检验主机是否正常.如果连续3次发现主机没有响应信息.则开始进行选举.
3.当哨兵选举完成之后.其他的节点都会当做新主机的从.

5 哨兵机制实现

5.1 复制哨兵配置文件

5.2 修改配置文件

1).修改保护模式

2).开启后台运行

3).修改哨兵的监控 其中的1表示投票生效的数量.

4).哨兵宕机之后的选举时间
如果主机宕机10秒之后开始进行推选.

5.修改哨兵选举的超时时间

5.3 哨兵高可用测试

1).启动哨兵

[root@localhost sentinel]# redis-sentinel sentinel.conf

2).先关闭主机,之后等待10秒之后,检查从机是否当选主机.之后再次启动主机(宕机的),检查是否为新主机的从

1.6 关于哨兵选举平票的说明

如果有多个哨兵进行选举,如果连续3次投票失败,可能引发脑裂现象的发生.
问题: 脑裂现象发生的概率是多大?? 1/8 = 12.5%
解决策略: 只要增加选举的节点的数量,可以有效的降低脑裂现象的发生. 概率论

1.7 链接哨兵的入门案例

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

8 关于分片哨兵的总结说明

分片:
1.主要的作用实现内存数据的扩容.
2.由于运算发生在业务服务器中,所以执行的效率更高.
3.Redis的分片没有高可用的效果. 如果其中一个节点出现了问题则导致程序运行出错.
哨兵机制:
1.实现Redis高可用,当redis服务器发生宕机的现象时,哨兵可以灵活的监控.实现自动的选举实现 故障的迁移.
2.哨兵中所监控的redis节点中的数据都是相同的. 无法实现海量的数据存储.
3.哨兵虽然可以实现redis的高可用,但是由于哨兵的本身没有实现高可用.所以存在风险.
如果想要最大程度上减少损耗,则建议不要引入第三方的监控