Redis 故障排查与应急手册：从理论到实践

Redis 故障排查与应急手册从理论到实战场景线上 Redis 集群出现性能抖动、连接异常、数据丢失等问题时的快速响应指南一、故障分级与响应策略在深入技术细节之前先建立故障分级意识级别现象响应时间核心目标P0集群完全不可用业务中断5分钟内快速恢复服务P1主节点宕机自动切换中15分钟内确保高可用生效P2性能下降延迟升高30分钟内定位根因并优化P3监控告警指标异常2小时内预防性处理二、核心排查工具箱2.1 必知必会的监控指标# 实时查看关键指标redis-cli INFO stats redis-cli INFO memory redis-cli INFO replication redis-cli INFO clients黄金指标清单指标健康阈值异常含义used_memory/maxmemory 85%内存即将耗尽可能触发驱逐instantaneous_ops_per_sec视业务而定突增可能意味着热 Key 或攻击connected_clients 10000连接数过多可能连接泄漏rejected_connections0连接被拒绝检查maxclientskeyspace_hits/keyspace_misses命中率 90%缓存失效严重latest_fork_usec 100000Fork 耗时过长会阻塞主线程2.2 慢查询分析# 设置慢查询阈值单位微秒redis-cli CONFIG SET slowlog-log-slower-than10000# 查看最近 10 条慢查询redis-cli SLOWLOG GET10# 重置慢查询日志redis-cli SLOWLOG RESET慢查询分析要点关注KEYS *、FLUSHALL、HGETALL等全量操作检查是否有O(N)命令操作大 Key复杂 Lua 脚本的执行时间2.3 大 Key 扫描线上慎用# 安全扫描大 Key--bigkeys 是采样统计非精确值redis-cli--bigkeys# 更精确但需要遍历低峰期使用redis-cli --memkeys-samples1000三、六大经典故障场景与应急方案场景一Redis 内存飙升 / OOM现象used_memory持续增长最终触发 OOM 或大量 Key 被驱逐排查步骤# 1. 查看内存使用详情redis-cli INFO memory# 2. 查看 Key 的内存分布redis-cli--bigkeys# 3. 检查内存策略redis-cli CONFIG GET maxmemory-policy常见根因根因识别方法解决方案缓存未设置过期时间redis-cli INFO keyspace查看expires添加 TTL清理无用数据大 Key 问题--bigkeys发现单个 Key 1MB拆分 Hash使用HSCAN分批读取内存碎片率过高mem_fragmentation_ratio 1.5重启实例或启用activedefrag写入缓冲区堆积client-output-buffer-limit超限调整缓冲区限制优化消费速度应急操作# 紧急设置内存上限防止系统 OOMredis-cli CONFIG SET maxmemory 8gb# 调整驱逐策略为 volatile-lru优先淘汰有过期时间的 Keyredis-cli CONFIG SET maxmemory-policy volatile-lru# 手动删除大 Key使用 UNLINK 非阻塞删除redis-cli UNLINK big_hash_key# 开启主动碎片整理Redis 4.0redis-cli CONFIG SET activedefragyes场景二Redis 连接数爆满现象connected_clients接近maxclients新连接被拒绝排查步骤# 查看当前连接数redis-cli INFO clients# 查看连接来源redis-cli CLIENT LIST|grep-E(addr|name|age|idle)# 统计各 IP 连接数redis-cli CLIENT LIST|awk-F/addr/{print $2}|cut-d:-f1|sort|uniq-c|sort-rn|head-20常见根因根因识别特征解决方案连接池配置不当单服务节点连接数异常高调整连接池maxTotal和minIdle连接泄漏idle时间长但未被释放检查代码中close()是否被调用短连接风暴大量age很小的连接使用连接池避免频繁创建连接客户端 Bug特定版本客户端异常升级客户端版本应急操作# 临时提升最大连接数redis-cli CONFIG SET maxclients20000# 踢掉空闲连接危险操作谨慎使用redis-cli CLIENT KILL TYPE normal IDEL600# 查看阻塞客户端redis-cli CLIENT LIST|grep-iblockedJava 连接池优化示例// Jedis 连接池配置JedisPoolConfigconfignewJedisPoolConfig();config.setMaxTotal(100);// 最大连接数config.setMaxIdle(50);// 最大空闲连接config.setMinIdle(10);// 最小空闲连接config.setTestOnBorrow(true);// 借用时验证config.setTestWhileIdle(true);// 空闲时验证// 关键确保连接正确关闭try(Jedisjedispool.getResource()){jedis.get(key);}// 自动归还连接场景三Redis 主从复制中断现象从节点状态为master_link_status:down数据不同步排查步骤# 查看复制状态redis-cli INFO replication# 查看从节点日志tail-f/var/log/redis/redis-server.log# 检查主节点复制积压缓冲区redis-cli INFO stats|grep-E(master_repl_offset|repl_backlog)常见根因根因识别方法解决方案网络闪断日志中出现Connection timed out调整repl-timeout和repl-ping-replica-period复制缓冲区不足master_repl_offset差异大增大repl-backlog-size从节点重启master_link_status为down自动重连或手动SLAVEOF主节点 RDB 生成失败日志中Cant save in background检查磁盘空间和maxmemory应急操作# 从节点强制重新同步会清空从节点数据redis-cli SLAVEOF NO ONE redis-cli SLAVEOF master_host master_port# 调整复制超时时间redis-cli CONFIG SET repl-timeout120redis-cli CONFIG SET repl-ping-replica-period30# 增大复制积压缓冲区默认 1MB建议 100MBredis-cli CONFIG SET repl-backlog-size104857600场景四Redis 性能急剧下降现象RT 从 ms 级上升到秒级甚至超时排查步骤# 查看 CPU 使用率Redis 是单线程CPU 100% 意味着忙碌top-p$(pgrep redis-server)# 查看命令统计redis-cli INFO commandstats# 实时监控命令执行redis-cli MONITOR|head-100# 注意生产环境慎用性能开销大# 查看延迟监控redis-cli --latency-history-i1常见根因根因识别方法解决方案热 Key 访问instantaneous_ops_per_sec突增本地缓存 Key 拆分如key:{hash}大 Key 操作SLOWLOG中出现HGETALL、SMEMBERS拆分数据使用HSCAN、SSCANFork 阻塞latest_fork_usec过大控制实例内存大小使用磁盘less复制AOF 刷盘阻塞aof_delayed_fsync增加调整appendfsync策略持久化竞争备份或 AOF rewrite 期间避免高峰期执行BGSAVE应急操作# 临时关闭 AOF数据安全与性能的权衡redis-cli CONFIG SET appendonly no# 调整 AOF 刷盘策略redis-cli CONFIG SET appendfsync everysec# 或 no最高性能# 禁用 THP透明大页减少 Fork 耗时echonever/sys/kernel/mm/transparent_hugepage/enabled# 使用管道批量操作减少 RTTredis-cli--pipecommands.txt热 Key 解决方案架构┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ Client │────▶│ Local Cache │────▶│ Redis │ │ │ │ (Caffeine/ │ │ Cluster │ │ │◀────│ Guava) │◀────│ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ └────────── 异步更新缓存 ◀────────────┘场景五Redis 脑裂Split-Brain现象主从切换后旧主节点仍在接受写请求导致数据不一致排查步骤# 检查当前主从拓扑redis-cli-hold_master INFO replication redis-cli-hnew_master INFO replication# 检查 Sentinel 日志tail-f/var/log/redis/sentinel.log预防措施# 配置 min-slaves 机制Redis 2.8redis-cli CONFIG SET min-slaves-to-write1redis-cli CONFIG SET min-slaves-max-lag10# 配置 Sentinel自动故障转移sentinel monitor mymaster127.0.0.163792sentinel down-after-milliseconds mymaster5000sentinel failover-timeout mymaster60000应急操作# 强制旧主节点降级为从节点redis-cli-hold_master SLAVEOF new_master_ip new_master_port# 如果数据已不一致需要权衡保留旧数据还是新数据# 方案1保留新主节点数据丢弃旧主节点数据redis-cli-hold_master DEBUG SEGFAULT# 强制崩溃重启清空数据后同步# 方案2保留旧主节点数据手动合并复杂需业务配合场景六缓存雪崩 / 击穿 / 穿透现象大量请求直达数据库DB 压力骤增问题类型现象解决方案缓存雪崩大量 Key 同时过期随机 TTL、多级缓存、熔断降级缓存击穿热点 Key 过期瞬间高并发互斥锁、逻辑过期、永不过期缓存穿透查询不存在的 Key布隆过滤器、空值缓存、参数校验应急操作代码示例// 缓存击穿防护互斥锁publicStringgetWithLock(Stringkey){Stringvalueredis.get(key);if(valuenull){// 获取分布式锁if(redis.setnx(lock:key,1,10)){try{valuedb.get(key);redis.setex(key,3600,value);}finally{redis.del(lock:key);}}else{// 等待后重试Thread.sleep(100);returngetWithLock(key);}}returnvalue;}// 缓存穿透防护布隆过滤器publicStringgetWithBloomFilter(Stringkey){if(!bloomFilter.mightContain(key)){returnnull;// 直接返回不查 DB}// 正常查询缓存和 DB}四、标准化应急响应流程┌─────────────────┐ │ 收到告警通知 │ └────────┬────────┘ ▼ ┌─────────────────┐ 是 ┌─────────────────┐ │ 服务是否可用 │────────────▶│ 立即切换流量 │ │ │ │ 到备用集群 │ └────────┬────────┘ └─────────────────┘ │ 否 ▼ ┌─────────────────┐ │ 查看监控大盘 │ │ (内存/CPU/连接) │ └────────┬────────┘ ▼ ┌─────────────────┐ │ 定位故障场景 │ │ (匹配六大场景) │ └────────┬────────┘ ▼ ┌─────────────────┐ 是 ┌─────────────────┐ │ 是否需要应急 │────────────▶│ 执行应急操作 │ │ │ │ (保留现场日志) │ └────────┬────────┘ └─────────────────┘ │ 否 ▼ ┌─────────────────┐ │ 根因分析修复 │ │ 更新故障案例库 │ └─────────────────┘五、预防性建设清单5.1 监控告警体系# Prometheus AlertManager 配置示例groups:-name:redisrules:-alert:RedisMemoryHighexpr:redis_memory_used_bytes / redis_memory_max_bytes0.85for:5mannotations:summary:Redis 内存使用率超过 85%-alert:RedisConnectionsHighexpr:redis_connected_clients / redis_config_maxclients0.8for:2mannotations:summary:Redis 连接数超过 80%-alert:RedisReplicationLagexpr:redis_master_link_up 0for:1mannotations:summary:Redis 主从复制中断5.2 配置最佳实践# redis.conf 核心配置maxmemory 8gb maxmemory-policy allkeys-lru maxclients10000# 持久化配置根据业务选择appendonlyyesappendfsync everysec no-appendfsync-on-rewriteyesauto-aof-rewrite-percentage100auto-aof-rewrite-min-size 64mb# 慢查询配置slowlog-log-slower-than10000slowlog-max-len128# 客户端输出缓冲区client-output-buffer-limit normal000client-output-buffer-limit replica 256mb 64mb60client-output-buffer-limit pubsub 32mb 8mb605.3 定期演练事项月度执行主从切换演练验证 Sentinel/Cluster 自动故障转移季度模拟大 Key 删除验证UNLINK非阻塞效果半年全量数据恢复演练验证 RDB/AOF 文件可用性六、总结故障排查心法“监控先行日志为凭工具辅助经验兜底”保持冷静先确认服务可用性再深入排查现场保护故障时的INFO、MONITOR、SLOWLOG及时保存变更关联故障前是否有发布、配置变更、扩容操作渐进修复优先止损再根治避免二次故障复盘归档每个故障都是案例更新到团队知识库延伸阅读Redis 官方文档 - 延迟监控Redis 内存优化指南Redis 高可用架构实践本文基于 Redis 6.x/7.x 版本编写部分命令在低版本可能略有差异。生产环境操作前请务必在测试环境验证。