哨兵机制次要是为了实现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的高可用,然而因为哨兵的自身没有实现高可用.所以存在危险.
如果想要最大水平上缩小损耗,则倡议不要引入第三方的监控!