zoukankan      html  css  js  c++  java
  • redis HA高可用方案Sentinel和shard

    1、搭建redis-master、redis-slave以及seninel哨兵监控

    在最小配置:master、slave各一个节点的情况下,不管是master还是slave down掉一个,“完整的”读/写功能都将受影响,这在生产环境中显然不能接受。幸好redis提供了sentinel(哨兵)机制,通过sentinel模式启动redis后,自动监控master/slave的运行状态,基本原理是:心跳机制+投票裁决

    每个sentinel会向其它sentinal、master、slave定时发送消息,以确认对方是否“活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的“主观认为宕机” Subjective Down,简称SDOWN)。

    若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称ODOWN),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置

    最小化的sentinel配置文件为:

    [html] view plain copy
     
     print?
    1. 1 port 26389  
    2. 2   
    3. 3 dir ./tmp  
    4. 4   
    5. 5 sentinel monitor mymaster 127.0.0.1 6379 1  
    6. 6 sentinel down-after-milliseconds mymaster 5000  
    7. 7 sentinel parallel-syncs mymaster 1  
    8. 8 sentinel failover-timeout mymaster 15000  

    第1行,指定sentinel使用的端口,不能与redis-server运行实例的端口冲突

    第3行,指定工作目录

    第5行,显示监控master节点10.6.144.155,master节点使用端口7030,最后一个数字表示投票需要的"最少法定人数",比如有10个sentinal哨兵都在监控某一个master节点,如果需要至少6个哨兵发现master挂掉后,才认为master真正down掉,那么这里就配置为6,最小配置1台master,1台slave,在二个机器上都启动sentinal的情况下,哨兵数只有2个,如果一台机器物理挂掉,只剩一个sentinal能发现该问题,所以这里配置成1,至于mymaster只是一个名字,可以随便起,但要保证5-8行都使用同一个名字

    第6行,表示如果5s内mymaster没响应,就认为SDOWN

    第8行,表示如果15秒后,mysater仍没活过来,则启动failover,从剩下的slave中选一个升级为master

    第7行,表示如果master重新选出来后,其它slave节点能同时并行从新master同步缓存的台数有多少个,显然该值越大,所有slave节点完成同步切换的整体速度越快,但如果此时正好有人在访问这些slave,可能造成读取失败,影响面会更广。最保定的设置为1,只同一时间,只能有一台干这件事,这样其它slave还能继续服务,但是所有slave全部完成缓存更新同步的进程将变慢。

    另:一个sentinal可同时监控多个master,只要把5-8行重复多段,加以修改即可。

    各自启动redis主备和sentinal哨兵,查看redis的master

    ./redis-cli -p 26389 sentinel masters 可通过该命令查看当前的master节点情况

    模拟当master挂掉,是否slave switch为master.

    切换成功,将挂掉master启起来,是否该redis变幻为slave.

    2、sentinel和shard redis保证redis 集群的高可用。

    Sentinel&Jedis看上去是个完美的解决方案,这句话只说对了一半,在无分片的情况是这样,但我们的应用使用了数据分片-sharing,数据被平均分布到4个不同的实例上,每个实例以主从结构部署,Jedis没有提供基于Sentinel的ShardedJedisPool,也就是说在4个分片中,如果其中一个分片发生主从切换,应用所使用的ShardedJedisPool无法获得通知,所有对那个分片的操作将会失败。 
    本文提供一个基于Sentinel的ShardedJedisPool,能及时感知所有分片主从切换行为,进行连接池重建..........

    3监控..

    目前针对redis的监控比较少见,主要有redis-live、dredis等。但这些工具对redis性能消耗比较严重,实时监控比较困难。

    redis的监控可以简单分为安全监控和性能监控。安全监控可以通过redissentinel的输出日志判断Master和Slave的状态;性能监控需要收集redis的性能参数进行评估。因此二者并不冲突,通过shell脚本可以实现轻量级的监控,缺点是没有可视化的实时图表。

    1、安全监控

    Redis sentinel的输出日志简洁而且内容很丰富,包含redis的实时状态、故障切换时间以及sentinel自身的状态,并且针对故障消除也有详细的记录。通过对sentinel日志挖掘,找出故障时刻进行及时报警,并通知管理员。

    由于sentinel默认不启用日志记录,可以通过以下方法记录日志:

    启动输入日志:

    src/redis-sentinel sentinel.conf >>sentinel.log &

  • 相关阅读:
    面经分享 | B站 | 数据分析 | 2021.1--转载
    TensorFlow 2.0 学习笔记--第六章 循环神经网络
    TensorFlow 2.0 学习笔记--第五章 神经网络卷积计算
    TensorFlow 2.0 学习笔记--第一章 神经网络计算过程及介绍
    免费服务器
    Nginx采坑日记(后台响应ResponseEntity时,Nginx将部分数据过滤)
    Vue 注意事项
    服务熔断&服务降级
    阿里微服务解决方案-Alibaba Cloud之负载均衡(Feign)(五)
    阿里微服务解决方案-Alibaba Cloud之服务消费方(Feign)(四)
  • 原文地址:https://www.cnblogs.com/grimm/p/5770908.html
Copyright © 2011-2022 走看看