核心目标建立系统化的观测手段INFO/SLOWLOG/CLIENT/MONITOR/latency与排障方法论能定位慢命令、大 key、热 key、连接与延迟问题用 redis-benchmark 建立性能基线把前 11 篇的知识收敛成一张可执行的排障决策树。前置知识本系列全部前篇——排障是机制理解的检验场没有 Part 2-11 的模型指标只是数字。验证环境Redis 8.10.0cygwin 移植版127.0.0.1:6379、redis-py 8.1.0、Python 3.11.6、Windows 11。最后复核日期2026-08-07。0. 本篇问题场景三个线上偶发的排查起点“Redis 偶尔慢一下过会儿自己好了”——是网络抖动、慢命令还是大 key 传输“内存涨上去降不下来”——是数据真的多还是过期堆积/碎片/峰值残留“连接数突然爆了”——是业务并发上来还是客户端连接泄漏前 11 篇建立了机制模型本篇回答最后一公里问题来了按什么顺序查、看哪些指标、怎么定位、怎么修。1. 观测体系五个入口1.1 INFO全局体检按段位查询INFO server # 版本、运行时间、配置 INFO clients # 连接数connected_clients、blocked_clients INFO memory # used_memory、fragmentation、peakPart 6 INFO stats # 命令数、ops、expired_keys、evicted_keys INFO replication # 主从角色、offset、延迟Part 10 INFO persistence # RDB/AOF 状态、最近保存时间Part 5实测INFO stats关键字段total_connections_received: 9 total_commands_processed: 1029 instantaneous_ops_per_sec: 0 ← 瞬时 QPS expired_keys: 0 evicted_keys: 0 ← 过期/淘汰量Part 61.2 SLOWLOG慢命令的账本Redis 记录执行耗时超过阈值的命令$ CONFIG SET slowlog-log-slower-than 0 # 阈值设 0记录一切排障用 $ SLOWLOG GET 5redis-py 8.x 的读取与字段SLOWLOG 最近 5 条耗时, 命令, 来源: 1 us SELECT 15 b127.0.0.1:65169 6 us HELLO 3 b127.0.0.1:65169 4 us SLOWLOG GET 3 b127.0.0.1:54057 SLOWLOG 长度: 128字段id、start_time、duration微秒、command、client_address。排障时把阈值降到 0 抓全量定位后调回正常值默认 10000 微秒 10ms。1.3 CLIENT LIST连接是谁addr127.0.0.1:65326 name age0s cmdclient|list字段addr来源、name业务标识强烈建议客户端设置 name、age连接存活、cmd当前命令。连接异常时按 name/addr 定位到具体服务CLIENT KILL定向清理。1.4 MONITOR实时命令流慎用1786145673.350415 [15 127.0.0.1:61971] SET mon:key hello 1786145673.386953 [15 127.0.0.1:61973] GET mon:key能看到每条命令的完整内容。代价MONITOR 会把所有命令广播给订阅者高流量下本身会放大负载——生产只在低峰期短时使用不能常开。1.5 latency monitor延迟事件CONFIG SET latency-monitor-threshold 100 # 记录超过 100ms 的事件 LATENCY LATEST # 最近事件 LATENCY HISTORY 事件名可以观测forkPart 5、command命令耗时、expire-cyclePart 6等事件——把偶发慢变成可回查的记录。2. 常见性能问题与指标对应症状看什么指标常见根因对应篇章命令偶发慢SLOWLOG、latency大 keyPart 4、KEYS/SMEMBERSPart 2、bgsave forkPart 5、rehashPart 3内存涨不降INFO memory过期堆积Part 6、碎片、峰值残留Part 6淘汰导致雪崩evicted_keys 突增maxmemory 过小 allkeys 策略Part 6/8连接数爆涨CLIENT LIST连接池泄漏、无超时、慢命令占连接Part 12.3主从延迟replication offset网络、大 key 传输、从库慢Part 10CPU 高instantaneous_ops_per_sec used_cpu单线程瓶颈、慢命令放大Part 1/2大 key–bigkeys / --memkeys / MEMORY USAGE字段过多的 Hash、大 valuePart 4/63. redis-py 客户端治理3.1 连接池redis.Redis(host127.0.0.1,port6379,max_connections50,# 池上限按服务并发估算别默认无限socket_connect_timeout2,# 建连超时socket_timeout2,# 读写超时——没有它Redis 挂起时请求无限等health_check_interval30,# 定期用 PING 剔除失效连接)连接泄漏是最常见事故连接池满 → 请求排队/超时 → 服务报错 → 重试 → 更多连接。治理CLIENT LIST看 age 与 name、INFO clients看connected_clients与blocked_clients、服务端设maxclients上限。3.2 超时、重试与退避超时必须有socket_timeout防Redis 挂了但请求永远不返回重试要保守写命令重试有重复执行风险命令可能已生效写路径优先幂等而不是重试退避重试间隔指数退避避免重试风暴放大故障。3.3 同步 vs 异步# redis.asyncio异步客户端连接池用法不同fromredis.asyncioimportRedisasAsyncRedis arAsyncRedis(host127.0.0.1,port6379,decode_responsesTrue)awaitar.set(k,v)异步客户端与同步客户端不要混用连接redis.asyncio的连接池由asyncio事件循环管理每个循环一个池。异步客户端在 Web 框架中的生命周期管理随请求创建、随应用关闭与同步写法不同接入示例见本系列 Part 8 的缓存实践思路。4. 生产排障决策树命令慢内存高连接异常主从延迟缓存命中率低线上问题什么症状查 SLOWLOG定位大 key / O-N 命令 / bgsave / rehash查 INFO memorybigkey / 过期堆积 / 碎片 / 峰值残留查 CLIENT LIST INFO clients连接泄漏 / 无超时 / maxclients查 INFO replication offset网络 / 大 key 同步 / 从库慢查 info stats 命中率 evicted/expired淘汰策略 / 过期抖动 / 穿透击穿4.1 案例复盘一次大 key 阻塞事故现象某服务晚高峰 P99 延迟从 5ms 涨到 200ms偶发超时INFO一切正常。排查SLOWLOG GET→ 发现一条GET cart:user:99999耗时 180ms——大 value 传输MEMORY USAGE cart:user:99999→ 23 MB——这个用户的购物车 Hash 积累了海量历史商品单线程模型这条 180ms 的命令阻塞了期间所有其他命令P99 全被拖高。修复拆 key购物车按最近 N 天分桶历史数据移到归档应用层限制单用户购物车条目数写入侧拦截监控--bigkeys定期扫描 SLOWLOG 告警 MEMORY USAGE阈值。预防Part 4/6 的大 key 治理 Part 12 的观测闭环——问题先被观测到才不会先被用户发现。5. 压测与性能基线redis-benchmark建立这台机器/这个版本的吞吐基线本机实测10 万请求、50 并发SET: 33806.62 requests per second, p501.375 msec GET: 34305.32 requests per second, p501.079 msec要点基线是环境的函数硬件、网络、是否同机跨机器比较没有意义同环境对比才有价值压测结果回答当前配置能扛多少 QPS上线前压测、上线后对拍异常偏离即告警压测工具模拟不了真实访问模式大 key、慢命令、热 key 分布benchmark 的 QPS 只是理论天花板。6. 版本与环境差异差异点官方 7.4本机 8.10.0cygwin 移植版SLOWLOG/CLIENT/MONITOR字段一致redis-py 8.x 返回结构变化client_list为 dict、slowlog 为command字段redis-benchmark可用可用吞吐数值低于 Linux 同配置cygwin 层开销latency monitor7.x一致连接治理参数一致health_check_interval在 5.x 均可用7. 测试与验收观测类测试SLOWLOG 能记录构造的慢命令、CLIENT LIST 字段完整、MONITOR 输出格式短时压测脚本保留环境记录版本、参数、机器供后续对比排障演练人为注入大 key/慢命令按决策树走一遍完整定位流程。本篇验收清单能说出 INFO 各段clients/memory/stats/replication/persistence各回答什么问题会用 SLOWLOG 定位慢命令并解释单线程阻塞的传导Part 1/2 模型会看 CLIENT LIST 定位连接异常知道name字段的价值知道 MONITOR/latency monitor 的适用边界短时、低峰能给 redis-py 配置合理的连接池、超时、重试策略能按决策树完成一次命令慢/内存高/连接异常/主从延迟的模拟排障有一套可复现的压测与基线记录方法。8. 常见误区“SLOWLOG 默认就能抓到所有慢命令”——默认阈值 10ms且日志有长度上限排障要临时降阈值§1.2。“MONITOR 开着没事”——高流量下 MONITOR 本身放大负载只能短时低峰用§1.4。“连接池越大越好”——池上限是保护不是性能过大反而放大 Redis 端压力与故障半径§3.1。“写操作超时重试就行”——写命令重试可能重复执行写路径靠幂等而不是重试§3.2。“benchmark 高 生产能扛”——benchmark 没有真实访问模式只能定基线和量级§5。“大 key 只有内存问题”——它的阻塞、带宽、主从延迟影响比内存更致命§4.1。9. 本篇小结全系列收尾12 篇的完整链路在此闭环Part 1-2 客户端 → 协议 → 事件循环 → 数据结构心智模型 Part 3-4 对象系统、SDS、dict、quicklist、skiplist、rax内存与性能之源 Part 5-6 持久化、过期、淘汰数据安全与内存治理 Part 7-9 事务、Lua、缓存一致性、分布式锁、限流并发架构 Part 10-11 复制、哨兵、集群高可用与容量扩展 Part 12 观测、压测、排障把以上全部变成可回答线上问题的能力排障的本质是机制 观测机制告诉你可能是什么单线程、COW、rehash、异步复制……观测告诉你现在是什么SLOWLOG、INFO、CLIENT LIST……。两者缺一排查就会变成瞎试。给读者的三条主线建议内存先看键数量再想优化Part 3 的 55.6B/键延迟任何偶发慢都先查 SLOWLOG 与 latencyPart 12一致性任何数据不对都先画时序图Part 8再谈方案。至此Redis 系列 12 篇全部完成。本系列所有实验均可在本机复现redis/shop-lab41 个测试 各篇隔离实例演练验证环境与版本差异已在每篇版本与环境差异中显式标注。10. 官方资料INFO / CONFIG / SLOWLOG / CLIENT / MONITORhttps://redis.io/docs/latest/commands/Latency monitoringhttps://redis.io/docs/latest/operate/oss_and_stack/management/optimization/latency-monitor/redis-benchmarkhttps://redis.io/docs/latest/operate/oss_and_stack/management/optimization/benchmarks/redis-py connection poolhttps://redis-py.readthedocs.io/en/stable/connections.html