redis高可用架构

一、背景

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

二、环境

#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.54:26400 sentinel 本地节点 
100.10.32.57:26400 sentinel 仲裁节点

三、部署

1、安装

yum -y install redis

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

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)

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)

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
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)

redis-server /etc/redis_6400.conf

6、初始化主从(100.10.32.55)

redis-cli -p 6400 slaveof 10.10.32.54 6400

7、绑定VIP到主库(100.10.32.54)

/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)

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

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

[[email protected] 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
[[email protected] 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
[[email protected] 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、把主库停掉

redis-cli -h 100.10.32.54  -p 6400 shutdown

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

[[email protected] 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上

[[email protected] 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的监控状态

[[email protected] 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
时间: 2024-07-28 15:55:52

redis高可用架构的相关文章

Redis高可用架构之主从同步

CAP原理 最终一致性 Redis提供的同步机制 主从同步 丛丛同步 缓解master节点的压力 Redis的同步方式 增量同步 Redis同步的指令流,环形Buffer存储指令流 缺点:buffer大小固定,会存在未执行的指令被覆盖掉的情况 快照同步 耗费资源,主节点Bgsave到磁盘文件中,再将文件中的内容传送到从节点 从节点在进行快照文件接受完毕后进行全量加载,加载前先删除当前内存的数据,记载完毕后才继续进行增量同步 需要合理设置buffer大小,避免发生快照同步死循环 增加从节点 首先进

Redis Sentinel高可用架构

Redis目前高可用的架构非常多,比如keepalived+redis,redis cluster,twemproxy,codis,这些架构各有优劣,今天暂且不说这些架构,今天主要说说redis sentinel高可用架构. 它的主要功能有以下几点 不时地监控redis是否按照预期良好地运行; 如果发现某个redis节点运行出现状况,能够通知另外一个进程(例如它的客户端); 能够进行自动切换.当一个master节点不可用时,能够选举出master的多个slave(如果有超过一个slave的话)中

数据库高可用架构(MySQL、Oracle、MongoDB、Redis)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换 服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构 MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案 服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为从库的负载均衡器

[转]数据库高可用架构(MySQL、Oracle、MongoDB、Redis)

一.MySQL MySQL小型高可用架构 方案:MySQL双主.主从 + Keepalived主从自动切换 服务器资源:两台PC Server 优点:架构简单,节省资源 缺点:无法线性扩展,主从失败之后需要手动恢复主从架构 MySQL中型高可用架构 方案:MMM + MySQL双主 + 多从高可用方案 服务器资源: 1.至少五台PC Server,2台MySQL主库,2台MySQL从库,1台MMM Monitor: 2.1台MMM Monitor选择低配: 3.如果不采用F5作为从库的负载均衡器

Redis 实战搭建高可用架构

前言:最近在看关于redis缓存方面的知识,今天就来个 Redis sentinel 高可用架构,实战开始之前,先看看sentinel的概念 什么是redis-sentinel Redis-Sentinel是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发

Redis的高并发、持久化、高可用架构设计

就是如果你用redis缓存技术的话,肯定要考虑如何用redis来加多台机器,保证redis是高并发的,还有就是如何让Redis保证自己不是挂掉以后就直接死掉了,redis高可用 我这里会选用我之前讲解过这一块内容,redis高并发.高可用.缓存一致性 redis高并发:主从架构,一主多从,一般来说,很多项目其实就足够了,单主用来写入数据,单机几万QPS,多从用来查询数据,多个从实例可以提供每秒10万的QPS. redis高并发的同时,还需要容纳大量的数据:一主多从,每个实例都容纳了完整的数据,比

亿级商品详情页架构演进技术解密 | 高可用架构系列

亿级商品详情页架构演进技术解密 | 高可用架构系列 --http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=210272034&idx=1&sn=3be9d2b53c7fec88716ee8affd2515f8&scene=1&srcid=UfXZNNOVZZyZjQmp0VOh&from=groupmessage&isappinstalled=0#rd 此文是开涛在[三体高可用架构群]之分享内容

雪球在股市风暴下的高可用架构改造分享

本文根据唐福林老师在“高可用架构”微信群所做的<股市风暴下的雪球架构改造经验分享>整理而成,转发请注明来自微信公众号ArchNotes. 唐福林,雪球首席架构师,负责雪球业务快速增长应对及服务性能与稳定架构优化工作.毕业于北京师范大学,硕士学位.之前曾任微博平台资深架构师,微博技术委员会成员.长期关注并从事互联网服务后端性能及稳定性架构优化工作. 雪球公司介绍 雪球 聪明的投资者都在这里. web 1.0:新闻资讯,股价信息,K线图 web 2.0:SNS 订阅,分享,聊天 web 3.0:移

Twitter 高并发高可用架构

解决 Twitter的“问题”就像玩玩具一样,这是一个很有趣的扩展性比喻.每个人都觉得 Twitter很简单,一个菜鸟架构师随便摆弄一下个可伸缩的 Twitter就有了,就这么简单.然而事实不是这样, Twitter的工程副总裁 Raffi Krikorian细致深入的描述了在 Twitter在可伸缩性上的演化过程,如果你想知道 Twitter的如何工作—从这里开始吧. Twitter发展太快,一切转瞬即过,但 Twitter已经长大了.它从一开始一个在Ruby on Rails上苦苦挣扎的小网