【redis学习三】简单高可用redis架构实践 靠谱崔小拽

本文详细介绍了如何构建一套高可用的Redis架构,包括版本选择、单机评估、主从复制配置及容灾策略等,旨在支撑线上千万级别的天级查询请求。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >



Evernote Export





body, td {
font-family: 微软雅黑;
font-size: 10pt;
}




背景:支撑线上千万级别的天级查询请求,要求高可用。

一、方案调研

1.1 redis版本选择

redis当前主流版本是redis 2.x 和 redis 3.x,3.0对集群支持比较不错,官方解释如下:

Redis是一个开源、基于C语言、基于内存亦可持久化的高性能NoSQL数据库,同时,它还提供了多种语言的API。近日,Redis 3.0在经过6个RC版本后,其正式版终于发布了。Redis 3.0的最重要特征是对Redis集群的支持,此外,该版本相对于2.8版本在性能、稳定性等方面都有了重大提高。

综合考虑之后扩展性和稳定性之后,选择版本 redis 3.2.3-1版本进行部署

1.2 是否选择搭建集群

是否搭建集群关键要看单机是否能够满足业务需求,做了个简单的数据评估。

数据量评估

  • 测试:单机写入2000w业务数据,占用内存1.5g,本机126g内存
  • 评估:单机的稳定数据承载量:2000w (126/1.56) 0.6 = 96923w
  • 结论:9T 的数据承载量,远超当前千万级别的数据量

性能评估

  • 测试:简单压测了下
    • 写操作 1000w,80% 在20ms一下 ,98%在30ms,最大218ms,qps 5w/s,总耗时197s
    • 读操作 1000w,97% 在10ms一下 ,99.99%在24ms,qps 6w/s,总耗时160s
  • 评估:当前的调用量在千万每天,qps的话在百/s。
  • 结论:当前单机的redis完全满足需求

因此:在单机远能够满足当下业务需求的情况下,决定不采用的集群的方式来部署redis,减少技术债务风险。

1.3 初定方案和架构图

选定了版本和基本部署方案之后,主要考虑服务的容灾和稳定性,经过思考之后采用采用极简的主从从结构,001实时同步数据002和003;001读写,002,003只读,机构图如下

二、实现过程

2.1 redis安装

此处略去,参考官方文档 https://redis.io/

2.2 配置读写master

  • 修改端口:port 【目的:简单的修改默认端口是最好的防攻击】
  • 添加密码:pwd
  • 关闭压缩:rdbcompression no 【硬盘最够,降低cpu的能耗更利于提升性能】
  • 开启守护进程:daemonize yes 【master开启守护,增加稳定性】
  • 关闭protect-mode :允许他机器访问
  • 添加白名单:bind xxx
  • 修改log地址,pid地址和数据存储地址:logfile pidfile 【便于维护和安全】
  • 添加慢查询:slowlog-log-slower-than 500 【根据业务需求,便于优化】
  • 最大内存限制:maxmemory 【考虑稳定性和性能,一般不超过最大内存的60%】

2.3 配置只读slave

  • 同master
  • 设置主库:slaveof ip:port
  • 主库密码:masterauth masterpwd
  • 只读:slave-read-only yes

2.4 启动测试

启动主库写入数据

进入从库查看

最初没有数据,主库写入之后,从库去到数据

查看log确认过程

三、架构能力评估

3.1 容灾能力

  • 主动容灾
    • 备份:master 全量备份,slave全量备份。
    • 备份安全:本机保存,hadoop同步保存一份。
    • 监控和探活:监控机分钟级探活和预警
  • 被动容灾:
    • slave 宕机:重启之后直接从master恢复
    • master 宕机且硬盘数据为损坏:重启后数据自动恢复且和从库一致。
    • master 宕机且数据损坏:删除损坏数据,使用slave1的数据恢复,保证数据一致。
    • master 和slave 1 同时宕机:slave2 保证读正常,业务不影响,利用slave2 数据备份恢复master,启动slave 即可
    • 三台全宕机:服务挂掉,从hadoop获取数据恢复服务。

3.2 性能评估

压测数据,参见方案选择,完全hold住。

四、问题思考

4.1 内存清理策略

暂时采用:

noeviction -> 谁也不删,直接在写操作时返回错误。

之后采用:

volatile-lru -> 根据LRU算法删除带有过期时间的key。 最少使用算法删除。

如果达到内存限制,手工清理,通过监控脚本监控内存情况

4.2 伸缩性和单节点问题

扩展slave可以直接扩展,扩展master需要master之间数据同步,暂时是个瓶颈。对于主读业务的需求,暂时问题不大;写需求的话,暂时的想法是代码转写的方式。

4.3 采用redis sentinal 监听

默认不错的监听,尝试了下效果不错,还在调研中,配置conf即可,完成后可以查看监听的情况

 
            
1
2
3
4
5
6
7
8
 
            
127.0 .0 .1:port> INFO Sentinel
# Sentinel
sentinel_masters: 1
sentinel_tilt: 0
sentinel_running_scripts: 0
sentinel_scripts_queue_length: 0
sentinel_simulate_failure_flags: 0
master0:name=redis115,status=ok,address=ip:port,slaves= 2,sentinels= 1

五:常用代码

 
            
1
2
3
4
5
6
7
8
9
10
 
            
# 强制杀死redis,模仿宕机
ps aux |grep redis |awk ‘{print 2}'</span>|xargs kill <span style="color:rgb(185, 202, 74);">-9</span></div><div style="height:20px;"><span style="color:rgb(195, 151, 216);"># 优化模拟宕机 【根据Dual-X-raY提示-_-】</span></div><div style="height:20px;">redis&gt; DEBUG SEGFAULT</div><div style="height:20px;"><span style="color:rgb(195, 151, 216);"># 重启,指定conf</span></div><div style="height:20px;">/home/work/xxx/bin/redis-server /home/work/xxx/etc/redis.conf</div><div style="height:20px;"><span style="color:rgb(195, 151, 216);"># 压测,具体参数可以参考benchmark</span></div><div style="height:20px;">[cuihuan@cuihuan bin] ./redis-benchmark -h 127.0.0.1 -p 端口 -a 密码 -c 1000 -n 10000000 -d 1024 -r 100000 -t set,get,incr,del

【转:【redis学习三】简单高可用redis架构实践 | 靠谱崔小拽


Redis从入门到高可用 分布式实战教程,共140多节课程、 掌握redis主从、哨兵、集群 ,参数调优 目录: 9-9 原生安装-1.准备节点.mp4 9-8 原生安装.mp4 9-7 基本架构.mp4 9-6 虚拟槽哈希分布.mp4 9-5 一致性哈希分区.mp4 9-4 节点取余分区.mp4 9-3 数据分布概论.mp4 9-2 呼唤集群.mp4 9-16 原生命令和redis-trib.rb对比.mp4 9-14 ruby环境准备-操作.mp4 9-13 ruby环境准备-说明.mp4 9-12 原生安装-4.分配主从.mp4 9-10 原生安装-2.节点握手.mp4 9-1 本章目录.mp4 8-9 实现原理-1-故障转移演练.mp4 8-8 python客户端.mp4 8-7 java客户端.mp4 8-6 redis sentinel安装演示-2.mp4 8-5 redis sentinel安装演示-1.mp4 8-4 redis sentinel安装与配置.mp4 8-3 redis sentinel架构.mp4 8-2 主从复制高可用?.mp4 8-19 本章总结.mp4 8-18 高可用读写分离.mp4 8-17 节点运维.mp4 8-16 常见开发运维问题-目录.mp4 8-15 故障转移.mp4 8-14 领导者选举.mp4 8-13 主观下线和客观下线.mp4 8-12 个定时任务.mp4 8-11 实现原理-3.故障演练(日志分析).mp4 8-10 实现原理-2.故障转移演练(客户端).mp4 8-1 sentinel-目录.mp4 7-9 主从复制常见问题.mp4 7-8 故障处理.mp4 7-7 全量复制开销 + 部分复制.mp4 7-6 全量复制.mp4 7-5 runid和复制偏移量.mp4 7-4 主从复制配置-操作.mp4 7-3 主从复制配置-介绍.mp4 7-2 什么是主从复制.mp4 7-1 目录.mp4 6-4 AOF阻塞.mp4 6-3 子进程开销和优化.mp4 6-2 fork.mp4 6-1 常见问题目录.mp4 5-9 RDB和AOF抉择.mp4 5-8 AOF实验.mp4 5-7 AOF(2).mp4 5-6 AOF(1).mp4 5-5 RDB(3).mp4 5-4 RDB(2).mp4 5-3 RDB(1).mp4 5-2 持久化的作用.mp4 5-1 目录.mp4 4-7 geo.mp4 4-6 hyperloglog.mp4 4-5 bitmap.mp4 4-4 发布订阅.mp4 4-3 pipeline.mp4 4-2 慢查询.mp4 4-1 课程目录.mp4 3-4 Go客户端:redigo简介.mp4 3-3 Python客户端:redis-py.mp4 3-2 Java客户端:Jedis.mp4 3-1 课程目录.mp4 2-9 list(2).mp4 2-8 list(1).mp4 2-7 hash (2).mp4 2-6 hash (1).mp4 2-5 字符串.mp4 2-4 单线程.mp4 2-3 数据结构和内部编码.mp4 2-2通用命令.mp4 2-11 zset.mp4 2-10 set.mp4 13-1 _课程总结.mp4 12-7 运维功能.mp4 12-6 用户功能.mp4 12-5 应用接入.mp4 12-4 机器部署.mp4 12-3 _快速构建.mp4 12-2 _Redis规模化困扰.mp4 12-1 _目录.mp4 11-8 本章总结.mp4 11-7 热点key的重建优化.mp4 11-6 无底洞问题.mp4 11-5 缓存穿透问题.mp4 11-4 缓存粒度问题.mp4 11-3 缓存的更新策略.mp4 11-2 缓存的受益和成本.mp4 11-1 目录.mp4 10-9 集群缩容-操作.mp4 10-8 集群缩容-说明.mp4 10-7 集群扩容演示-2.mp4 10-6 集群扩容演示-1.mp4 10-5 扩展集群-3.迁移槽和数据.mp4 10-4 扩展集群-2.加入集群.mp4 10-35 本章总结.mp4 10-34 集群vs单机.mp4 10-33 数据迁移.mp4 10-32 读写分离.mp4 10-31 请求倾斜.mp4 10-30 数据倾斜.mp4 10-3 扩展集群-1.加入节点.mp4 10-29 集群倾斜-目录.mp4 10-28 PubSub广播.mp4 10-27 带宽消耗.mp4 10-26 集群完整性.mp4 10-25 Redis Cluster常见开发运维问题-目录.mp4 10-24 故障模拟.mp4 10-23 故障恢复.mp4 10-22 故障发现.mp4 10-21 故障转移-目录.mp4 10-20 批量操作优化.mp4 10-2 集群伸缩原理.mp4 10-19 多节点操作命令.mp4 10-18 整合spring-2.mp4 10-17 整合spring-1.mp4 10-16 JedisCluster基本使用.mp4 10-15 smart客户端JedisCluster-目录.mp4 10-14 JedisCluster执行源码分析.mp4 10-13 smart客户端实现原理.mp4 10-12 ask重定向.mp4 10-11 moved异常说明和操作.mp4 10-10 客户端路由-目录.mp4 10-1 集群伸缩目录.mp4 1-9 特性5-功能丰富.mp4 1-8 特性4-多语言客户端.mp4 1-7 特性3-数据结构.mp4 1-6 特性2-持久化.mp4 1-5 特性1-速度快.mp4 1-4 redis特性目录.mp4 1-3 谁在使用Redis.mp4 1-2 Redis初识.mp4 1-15 redis常用配置.mp4 1-14 redis种启动方式介绍.mp4 1-13 redis典型使用场景.mp4 1-12 特性8-高可用分布式.mp4 1-11 特性7-复制.mp4 1-10 特性6-简单.mp4 1-1 导学.mp4
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值