Redis高可用架构:主从复制、哨兵、集群
一、引子:单机Redis的三大困境 假设你正在运行一个电商网站,使用单机Redis作为缓存。随着业务增长,你会遇到三个核心问题: 1.1 问题1:单点故障(可用性) 场景:双11大促,凌晨0点 00:00:00 - Redis单机宕机(内存不足OOM) 00:00:01 - 所有请求打到数据库 00:00:02 - 数据库连接池耗尽(1000个请求/秒) 00:00:03 - 数据库CPU 100% 00:00:05 - 网站503错误,用户无法下单 00:00:10 - 运维手动重启Redis 00:00:15 - Redis启动成功,但缓存为空 00:00:20 - 缓存预热中(需要10分钟) 00:10:00 - 系统恢复正常 损失: - 10分钟宕机时间 - 订单损失:10分钟 × 1000单/分钟 = 1万单 - GMV损失:1万单 × 200元/单 = 200万元 核心问题:单点故障导致系统不可用,无容灾能力。 可用性计算: 假设:Redis每月宕机1次,每次10分钟 可用性 = (30天 × 24小时 × 60分钟 - 10分钟) / (30天 × 24小时 × 60分钟) = (43200 - 10) / 43200 = 99.977% 看起来还不错?但实际上: - 1年12次宕机,累计120分钟 = 2小时 - 如果恰好在大促期间宕机,损失巨大 - 高可用系统要求:99.99%(年宕机时间 < 52分钟) 1.2 问题2:容量瓶颈(可扩展性) 场景:业务增长,数据量暴增 第1个月: - 商品数量:10万 - 缓存数据量:2GB - 单机Redis:4GB内存(够用) 第6个月: - 商品数量:100万 - 缓存数据量:20GB - 单机Redis:4GB内存(不够用!) 解决方案1:垂直扩展(加内存) - 4GB → 16GB(成本翻倍,但有上限) - 最大:512GB(成本极高,且有物理上限) 解决方案2:水平扩展(加机器) - 需要Redis集群(数据分片) 核心问题:单机内存有限,垂直扩展有上限,需要水平扩展。 ...