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 阻塞了整个事件循环。真正关键的是把多个指标交叉看，而不是单点归因。