Redis之高可用方案

简介: Redis之高可用方案   Redis以其高效的访问速度著称。但由于官方还未发布redis-cluster,而redis的replica又有诸多不便:比如一组master-slave的机器,如果之间有链接瞬段,或者对slave重新执行slaveof命令,会导致slave机器从头开始同步一次master的数据,造成较大的开销。

Redis之高可用方案

Redis以其高效的访问速度著称。但由于官方还未发布redis-cluster,而redis的replica又有诸多不便:比如一组master-slave的机器,如果之间有链接瞬段,或者对slave重新执行slaveof命令,会导致slave机器从头开始同步一次master的数据,造成较大的开销。
 
以下描述了使用keepalived+redis主从的一种高可用方法。安装方法在这里就不赘述了,google之则可。
1. redis服务配置
主机     端口   角色
redis0 6379   master
redis1 6379   slave
 
2. keepalived的配置
redis0和redis1使用一个虚拟ip
 
并使用如下脚本监控redis服务是否存活。监控脚本:

 

 

[html]  view plain copy
 
  1. #!/bin/bash  
  2. /usr/local/bin/redis-cli -h 192.168.1.53 -p 6379 info > /dev/null  
  3. if [ $? -eq 0 ]; then  
  4. echo "redis OK"  
  5. exit 0  
  6. else  
  7. echo "no redis service found!"  
  8. /usr/local/bin/redis-server /path/to/redis.conf  
  9.   
  10. # try to start it again  
  11. /usr/local/bin/redis-cli -h 192.168.11.53 -p 6380 info > /dev/null  
  12. if [ $? -eq 0 ]; then  
  13. exit 0  
  14. else  
  15.   
  16. # restart failed  
  17. killall keepalived  
  18. echo "error"  
  19. fi  
  20. fi  

 

要实现redis故障恢复,可以使用keepalived配置的notify_master, notify_backup这两个方法执行特有的脚本。实际上只要在slave(即redis1)上有2个脚本,第一个用于在redis1接管虚拟ip之后,执行slaveof no one把自己变成master。第二个用户在redis1交出虚拟ip之后,在redis0执行slaveof no one确保redis0恢复为主的状态,并对自己执行slaveof redis0 6379开始重新从master同步数据,如果自己已经是slave就没必要同步了。
 
redis1上keepalived的配置方法如下,redis0只要去掉notify_master, notify_backup两行即可。
[cpp]  view plain copy
 
  1. ! Configuration File for keepalived  
  2. global_defs {  
  3. router_id redis1  
  4. }  
  5. vrrp_script Monitor_Redis {  
  6.  script "/opt/redis_keepalive.sh"  
  7.  interval 10  
  8.  weight 2  
  9. }  
  10. vrrp_instance 360 {  
  11.  state BUCKUP #(主机为MASTER,备用机为BACKUP)  
  12.  interface eth0 #(HA监测网络接口)  
  13.  virtual_router_id 110 #(主、备机的virtual_router_id必须相同)  
  14.  mcast_src_ip 192.168.11.53 #(多播的源IP,设置为本机外网IP,与VIP同一网卡)此项可不设置  
  15.  priority 70 #(主、备机取不同的优先级,主机值较大,备份机值较小,值越大优先级越高)  
  16.  advert_int 1 #(VRRP Multicast广播周期秒数)  
  17.  authentication {  
  18.   ......  
  19. }  
  20.  notify_master /opt/redis_2master.sh  
  21.  notify_backup /opt/redis_2backup.sh  
  22.  track_script {  
  23.  Monitor_Redis #(调用nginx进程检测脚本)  
  24. }  
  25.  virtual_ipaddress {  
  26.  192.168.11.4 #(VRRP HA虚拟地址)  
  27.  }  
  28. }  
目录
相关文章
|
10月前
|
canal NoSQL 关系型数据库
Redis应用—7.大Value处理方案
本文介绍了一种用于监控Redis大key的方案设计及其实现步骤。主要内容包括:方案设计、安装与配置环境、binlog数据消费者。
397 29
Redis应用—7.大Value处理方案
|
4月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
5月前
|
监控 NoSQL 关系型数据库
保障Redis与MySQL数据一致性的强化方案
在设计时,需要充分考虑到业务场景和系统复杂度,避免为了追求一致性而过度牺牲系统性能。保持简洁但有效的策略往往比采取过于复杂的方案更加实际。同时,各种方案都需要在实际业务场景中经过慎重评估和充分测试才可以投入生产环境。
305 0
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
8月前
|
NoSQL 算法 安全
redis分布式锁在高并发场景下的方案设计与性能提升
本文探讨了Redis分布式锁在主从架构下失效的问题及其解决方案。首先通过CAP理论分析,Redis遵循AP原则,导致锁可能失效。针对此问题,提出两种解决方案:Zookeeper分布式锁(追求CP一致性)和Redlock算法(基于多个Redis实例提升可靠性)。文章还讨论了可能遇到的“坑”,如加从节点引发超卖问题、建议Redis节点数为奇数以及持久化策略对锁的影响。最后,从性能优化角度出发,介绍了减少锁粒度和分段锁的策略,并结合实际场景(如下单重复提交、支付与取消订单冲突)展示了分布式锁的应用方法。
614 3
|
NoSQL Redis
基于Redis的高可用分布式锁——RedLock
这篇文章介绍了基于Redis的高可用分布式锁RedLock的概念、工作流程、获取和释放锁的方法,以及RedLock相比单机锁在高可用性上的优势,同时指出了其在某些特殊场景下的不足,并提到了ZooKeeper作为另一种实现分布式锁的方案。
567 2
基于Redis的高可用分布式锁——RedLock
|
监控 NoSQL Redis
Redis 哨兵模式高可用
Redis 哨兵模式高可用
305 4
|
10月前
|
存储 监控 NoSQL
Redis集群有哪些方案
1. 主从复制集群 : 读写分离, 一主多从 , 解决高并发读的问题 2. 哨兵集群 : 主从集群的结构之上 , 加入了哨兵用于监控集群状态 , 主节点出现故障, 执行主从切换 , 解决高可用问题 3. Cluster分片集群 : 多主多从 , 解决高并发写的问题, 以及海量数据存储问题 , 每个主节点存储一部分集群数据
|
10月前
|
消息中间件 缓存 NoSQL
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
缓存与数据库的一致性方案,Redis与Mysql一致性方案,大厂P8的终极方案(图解+秒懂+史上最全)
|
存储 NoSQL Redis
Redis系列学习文章分享---第九篇(Redis快速入门之好友关注--关注和取关 -共同关注 -Feed流实现方案分析 -推送到粉丝收件箱 -滚动分页查询)
Redis系列学习文章分享---第九篇(Redis快速入门之好友关注--关注和取关 -共同关注 -Feed流实现方案分析 -推送到粉丝收件箱 -滚动分页查询)
196 0