redis高可用架构

简介:
原创作品,允许转载,转载时请务必以超链接形式标明文章  原始出处 、作者信息和本声明。否则将追究法律责任。 http://navyaijm.blog.51cto.com/4647068/1745569

一、背景

   公司的业务在大量的使用redis,访问量大的业务我们有在使用codis集群,redis 3.0集群,说到redis 3.0集群,我们线上已经跑了半年多了,集群本身没有出现过任务问题,但是由于我们这个业务是海外的,集群建在aws的ec2上,由于ec2的网络抖动或者ec2本身的原因,导致主从切换,目前aws的技术正在跟进,这个集群目前的QPS 50w+,集群本身已经做到了高可用和横向扩展,但是,实际情况一些小的业务没必要上集群,单个实例就可以满足业务需求,那么我们就要想办法如何保证单个实例的高可用,最近也在看相关的文档,做一些测试,大家有在使用redis主从+lvs 漂VIP的方案,也有使用redis主从+哨兵 漂VIP的方案,甚至有在代码逻辑做故障切换等等,各种各样的方案都有,下面我介绍一下redis主从+哨兵 漂VIP的方案,后面我们打算线上大规模的使用这个方案。

二、环境

1
2
3
4
5
6
7
8
#redis
100.10.32.54:6400 主库
100.10.32.55:6400 从库
100.10.32.250 VIP
#sentinel
100.10.32.54:26400 sentinel 本地节点
100.10.32.55:26400 sentinel 本地节点 
100.10.32.57:26400 sentinel 仲裁节点

三、部署

1、安装

1
yum -y  install  redis

2、撰写redis配置文件(100.10.32.54 和100.10.32.55)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
vim  /etc/redis_6400 .conf
 
daemonize  yes
pidfile  "/var/run/redis_6400.pid"
port 6400
tcp-backlog 65535
bind 0.0.0.0
timeout 0
tcp-keepalive 0
loglevel notice
logfile  "/var/log/redis/redis_6400.log"
maxmemory 8gb
maxmemory-policy allkeys-lru
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error  yes
rdbcompression  yes
rdbchecksum  yes
dbfilename  "dump.rdb"
dir  "/data/redis/6400"
slave-serve-stale-data  yes
slave- read -only  yes
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename  "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua- time -limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
notify-keyspace-events  ""
hash -max-ziplist-entries 512
hash -max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set -max-intset-entries 512
zset-max-ziplist-entries 128

3、撰写sentinel配置文件(100.10.32.54 、100.10.32.55 和100.10.32.57)

1
2
3
4
5
6
7
8
9
10
11
vim  /etc/redis-sentinel6400 .conf
 
daemonize  yes
port 26400
dir  "/data/redis/redis_sentinels"
pidfile  "/var/run/redis/sentinel6400.pid"
logfile  "/data/redis/redis_sentinels/sentinel6400.log"
sentinel monitor master6400 100.10.32.54 6400 2
sentinel down-after-milliseconds master6400 6000
sentinel failover-timeout master6400 18000
sentinel client-reconfig-script master6400  /opt/notify_master6400 .sh    ##仲裁节点无需添加这行配置,client-reconfig-script参数是在sentinel做failover的过程中调用脚本漂vip到新的master上

PS:

关于sentinel 的一些工作原理和参数说明,请参阅:http://redisdoc.com/topic/sentinel.html

4、撰写漂VIP的脚本(100.10.32.54 、100.10.32.55)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
vim  /opt/notify_master6400 .sh
 
#!/bin/bash
MASTER_IP=$6
LOCAL_IP= '100.10.32.54'  #从库修改为100.10.32.55
VIP= '100.10.32.250'
NETMASK= '24'         
INTERFACE= 'eth0' 
if  [ ${MASTER_IP} = ${LOCAL_IP} ];  then
          /sbin/ip  addr add ${VIP}/${NETMASK} dev ${INTERFACE}
          /sbin/arping  -q -c 3 -A ${VIP} -I ${INTERFACE}
         exit  0
else
          /sbin/ip  addr del ${VIP}/${NETMASK} dev ${INTERFACE}
         exit  0
fi
exit  1
1
chmod  +x  /opt/notify_master6400 .sh    #赋予可执行权限

PS:

这里大概说一下这个脚本的工作原理,sentinel在做failover的 过程中会传出6个参数,分别是<master-name>、 <role>、 <state>、 <from-ip>、 <from-port>、 <to-ip> 、<to-port>,其中第6个参数from-ip也就是新的master的ip,对应脚本中的MASTER_IP,下面的if判断大家应该都很了然了,如果MASTER_IP=LOCAL_IP,那就绑定VIP,反之删除VIP。


5、启动redis服务(100.10.32.54、100.10.32.55)

1
redis-server  /etc/redis_6400 .conf

6、初始化主从(100.10.32.55)

1
redis-cli -p 6400 slaveof 10.10.32.54 6400

7、绑定VIP到主库(100.10.32.54)

1
/sbin/ip  addr add 100.10.32.250 /24  dev eth0

8、启动sentinel服务(100.10.32.54、100.10.32.55、100.10.32.57)

1
redis-server  /etc/redis-sentinel6400 .conf --sentinel

至此,整个高可用方案已经搭建完成。

1
2
3
4
5
6
7
8
9
10
[root@localhost tmp] # redis-cli -h 100.10.32.54  -p 6400 info  Replication
# Replication
role:master
connected_slaves:1
slave0:ip=100.10.32.55,port=6400,state=online,offset=72669,lag=1
master_repl_offset:72669
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:72668
1
2
3
4
5
6
7
[root@localhost tmp] # redis-cli -h 100.10.32.54  -p 26400 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master6400,status=ok,address=100.10.32.54:6400,slaves=1,sentinels=3
1
2
3
4
[root@localhost tmp] # ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
     inet 100.10.32.54 /24  brd 100.10.32.255 scope global eth0
     inet 100.10.32.250 /24  scope global secondary eth0

四、测试

1、把主库停掉

1
redis-cli -h 100.10.32.54  -p 6400  shutdown

2、看从库是否提升为主库

1
2
3
4
5
6
7
8
9
[root@localhost tmp] # redis-cli -h 100.10.32.55 -p 6400 info Replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

3、看VIP是否漂移到100.10.32.55上

1
2
3
4
[root@localhost tmp] # ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
     inet 100.10.32.55 /24  brd 100.10.32.255 scope global eth0
     inet 100.10.32.250 /24  scope global secondary eth0

4、看Sentinel的监控状态

1
2
3
4
5
6
7
[root@localhost tmp] # redis-cli -p 26400 info  Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master6400,status=ok,address=100.10.32.55:6400,slaves=1,sentinels=3

本文出自 “屌丝运维男” 博客,请务必保留此出处http://navyaijm.blog.51cto.com/4647068/1745569

目录
相关文章
|
9月前
|
SQL 监控 关系型数据库
MySQL主从复制:构建高可用架构
本文深入解析MySQL主从复制原理与实战配置,涵盖复制架构、监控管理、高可用设计及性能优化,助你构建企业级数据库高可用方案。
|
10月前
|
运维 监控 搜索推荐
MSE ZooKeeper:Flink 高可用架构的企业级选择
本文深入解析了 Apache Flink 架构中 ZooKeeper 的核心作用,包括 Leader 选举、Checkpoint 管理、作业协调及配置管理等关键功能,并结合金融风控与电商推荐等典型场景,分析了 ZooKeeper 在实际应用中的技术实现。
|
8月前
|
运维 监控 安全
公链开发中的高可用架构设计要点
本指南提供公链高可用架构的可复用流程与模板,涵盖目标拆解、先决条件、分步执行、故障排查及验收标准,结合跨链DApp与量化机器人案例,提升落地效率与系统稳定性。
|
8月前
|
缓存 运维 监控
Redis 7.0 高性能缓存架构设计与优化
🌟蒋星熠Jaxonic,技术宇宙中的星际旅人。深耕Redis 7.0高性能缓存架构,探索函数化编程、多层缓存、集群优化与分片消息系统,用代码在二进制星河中谱写极客诗篇。
1551 3
|
9月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
监控 Linux 应用服务中间件
Linux多节点多硬盘部署MinIO:分布式MinIO集群部署指南搭建高可用架构实践
通过以上步骤,已成功基于已有的 MinIO 服务,扩展为一个 MinIO 集群。该集群具有高可用性和容错性,适合生产环境使用。如果有任何问题,请检查日志或参考MinIO 官方文档。作者联系方式vx:2743642415。
3931 57
|
11月前
|
文字识别 运维 监控
架构解密|一步步打造高可用的 JOCR OCR 识别服务
本文深入解析了JOCR OCR识别服务的高可用架构设计,涵盖从用户上传、智能调度、核心识别到容错监控的完整链路,助力打造高性能、低成本的工业级OCR服务。
435 0
架构解密|一步步打造高可用的 JOCR OCR 识别服务
|
10月前
|
存储 NoSQL 算法
Redis的集群架构与使用经验
本文介绍了Redis的集群架构与使用经验,包括主从复制、哨兵集群及Cluster分片集群的应用场景与实现原理。内容涵盖Redis主从同步机制、数据分片存储方式、事务支持及与Memcached的区别,并讨论了Redis内存用尽时的处理策略。适用于了解Redis高可用与性能优化方案。
|
消息中间件 存储 设计模式
RocketMQ原理—5.高可用+高并发+高性能架构
本文主要从高可用架构、高并发架构、高性能架构三个方面来介绍RocketMQ的原理。
3565 21
RocketMQ原理—5.高可用+高并发+高性能架构
|
存储 NoSQL Redis
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构