哨兵

一、引子：单机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集群（数据分片） 核心问题：单机内存有限，垂直扩展有上限，需要水平扩展。 ...

一、引子：单机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集群（数据分片） 核心问题：单机内存有限，垂直扩展有上限，需要水平扩展。 ...

引言 主从复制虽然实现了数据备份，但主节点宕机后需要手动切换。哨兵（Sentinel）提供了自动故障检测和故障转移能力，实现真正的高可用。 一、哨兵概述 1.1 什么是哨兵？ 监控 ↓ [哨兵1] ←→ [哨兵2] ←→ [哨兵3] (多个哨兵相互通信) ↓ ↓ ↓ 监控 监控 监控 ↓ ↓ ↓ [主节点] ← [从节点1] ← [从节点2] 功能： 1. 监控：检查主从节点是否正常 2. 通知：故障通知管理员 3. 故障转移：自动提升从节点为主节点 4. 配置中心：客户端通过哨兵发现主节点 1.2 核心功能 监控（Monitoring） 检查主从节点健康状态 周期性发送PING命令 故障检测（Failure Detection） 主观下线（SDOWN）：单个哨兵判断 客观下线（ODOWN）：多数哨兵同意 自动故障转移（Failover） 选举领导者哨兵 选择新主节点 通知从节点切换 通知客户端 配置中心（Configuration Provider） 客户端从哨兵获取主节点地址 主节点变更自动通知客户端 二、哨兵部署 2.1 最小配置 # sentinel.conf port 26379 sentinel monitor mymaster 127.0.0.1 6379 2 # 2个哨兵同意才判定下线 sentinel down-after-milliseconds mymaster 5000 # 5秒无响应判断下线 sentinel failover-timeout mymaster 180000 # 故障转移超时时间 sentinel parallel-syncs mymaster 1 # 同时同步的从节点数量 2.2 启动哨兵 # 方式1： redis-sentinel sentinel.conf # 方式2： redis-server sentinel.conf --sentinel # 查看哨兵状态 127.0.0.1:26379> SENTINEL masters 127.0.0.1:26379> SENTINEL slaves mymaster 127.0.0.1:26379> SENTINEL sentinels mymaster 2.3 推荐部署架构 机器1：Redis Master + Sentinel1 机器2：Redis Slave1 + Sentinel2 机器3：Redis Slave2 + Sentinel3 好处： - 3个哨兵互相监控，防止误判 - 分布式部署，避免单点故障 三、故障检测机制 3.1 主观下线（SDOWN） 哨兵1每秒向主节点发送PING： PING → 主节点 PING → 主节点 PING → (超时5秒无响应) 判断：主节点主观下线（SDOWN） 配置： ...