Redis连接超时问题需优先排查服务端真实瓶颈，通过redis-cli info clients查看connected_clients是否接近maxclients上限、client list中idle超60000毫秒的连接是否大量存在、info stats中rejected_connections>0与expired_keys突增是否并存、info commandstats中cmdstat_get等命令avg_latency是否异常偏高、info memory中mem_fragmentation_ratio>1.5且RSS内存显著高于实际使用量，多指标交叉验证才能准确定位根因。
Redis连接超时问题，不能只盯着客户端报错，得先看服务端是否真“卡”了——INFO 里几个关键指标一查，90% 的真实瓶颈就浮出来了。
redis-cli info clients 显示 connected_clients 飙高但 maxclients 接近上限
这是最常见也最容易被忽略的连接耗尽场景。客户端没及时释放连接，或连接池配置过大，导致 Redis 实例被撑满。
-
connected_clients持续高于maxclients的 80%，说明连接压力已临界 - 执行
redis-cli config get maxclients查当前限制，默认是 10000，但很多云厂商会设为更低值（如 2048） -
client list输出里如果大量连接的idle字段超过 60000（单位毫秒），说明连接空闲太久却未关闭，大概率是客户端没调用close()或连接池没配置maxIdleTime - 注意：某些 SDK（如 Lettuce）在高 CPU 场景下会延迟处理响应，造成连接假性堆积，需同步检查业务进程 CPU 使用率
info stats 中 rejected_connections > 0 或 expired_keys 突增
这两个指标同时出现，往往指向资源争抢或过期策略失控。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
rejected_connections非零，说明新连接已被拒绝，不是网络不通，而是服务端主动拒接——此时connected_clients已达maxclients上限 -
expired_keys在短时间内陡增（比如每秒几百上千），可能触发 Redis 主动阻塞清理逻辑，尤其当active_defrag_running为 1 时，evict和expire操作会显著拖慢响应 - 结合
instantaneous_ops_per_sec观察：若该值骤降而expired_keys飙升，基本可判定是过期 key 清理拖垮了吞吐
info commandstats 显示某些命令 avg_latency 异常偏高
不是所有超时都来自网络或连接数，有些是特定命令本身慢到拖垮整个队列。
- 重点关注
cmdstat_get、cmdstat_hgetall、cmdstat_zrange这类易出大 key 的命令，它们的avg_latency若超过 50ms（尤其对比其他命令普遍 - 执行
slowlog get 20，看是否有KEYS、FLUSHDB、HGETALL等全量扫描命令频繁出现；duration字段单位是微秒，> 100000（即 100ms）就值得警惕 - 注意：
commandstats中的calls和usec_per_call是累计均值，要结合时间窗口比对——比如凌晨批量 job 执行后该值突升，白天又回落，说明是定时任务引发的周期性抖动
info memory 中 mem_fragmentation_ratio > 1.5 且 used_memory_rss_human 明显大于 used_memory_human
内存碎片高 + RSS 内存远超实际使用量，说明 Redis 内存分配器吃紧，GC 压力大，容易引发命令执行卡顿甚至超时。
-
mem_fragmentation_ratio=used_memory_rss/used_memory，> 1.5 表示碎片严重；> 2.0 基本可确认为内存分配瓶颈 - 此时
allocator_active和allocator_resident差值拉大，说明 jemalloc 分配器无法及时回收页，Redis 可能频繁触发malloc失败重试 - 临时缓解可用
redis-cli config set activedefrag yes（仅 4.0+ 支持），但治标不治本；长期需控制大 key、避免频繁写入/删除小对象
监控指标本身不会撒谎，但容易被误读——比如 connected_clients 高未必是客户端 bug，可能是 timeout 设置太短导致频繁重连；avg_latency 高也不一定代表命令慢，有可能是某次 GC 或 fork 阻塞了整个事件循环。真正关键的是把多个指标交叉看，而不是单点归因。
