最有效的是addr、age、idle三个字段：addr集中指向某ip+age持续增长表明连接池泄漏；idle>300秒说明连接“借出未还”；flags=n但qbuf非零、qbuf-free过小则提示命令堆积或客户端卡死。
redis-cli client list 看什么字段最有效
别只扫一眼 connected_clients 数值，那只是当前连接总数，掩盖了真实问题。真正要盯的是 client list 输出里的三个字段：addr、age、idle。
addr 固定不变（比如全是 10.0.1.12:54321）+ age 持续增长（几小时甚至几天），基本锁定是某台应用机器的连接池没关干净；idle > 300 的连接，大概率是借出去没还，或异常中断后未清理；大量连接 flags=N 但 qbuf 非零、qbuf-free 很小，说明命令堆积，可能是客户端卡死或网络问题。
快速定位“贡献”最多连接的客户端 IP：
redis-cli client list | awk '{print $2}' | sort | uniq -c | sort -nr
CONFIG GET maxclients 返回值不准？查 /proc 才算数
CONFIG GET maxclients 显示的值经常不是真实生效值——Redis 启动时会自动把 maxclients 降到 ulimit -n - 32（预留 32 个给自身），且不报错、不写日志。你改了配置文件，重启后看到的仍是旧值，实际生效的是系统限制。
必须验证真实上限：
cat /proc/$(pidof redis-server)/limits | grep "Max open files"
这个值才是 Redis 当前能打开的最大文件描述符数，也就是它实际允许的连接上限。如果它比你设的 maxclients 小，那改配置就等于白改。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
rejected_connections 持续上涨就是连接耗尽的明确信号
INFO clients 输出里有个关键指标：rejected_connections。只要它在缓慢但持续上涨，就说明新连接正在被硬性拒绝，不是偶发抖动，而是连接池/应用层存在泄漏或空闲连接未释放。
常见诱因包括：
- Jedis 获取连接后漏掉
close()，哪怕每秒只漏 1 个，QPS 上万的服务一天就能涨几千连接 - try-finally 里调
jedis.close()，但该方法抛IOException被上层吞掉，连接仍没归还 - 客户端未启用连接池，每次请求都新建连接，又没配
timeout，连接长期 hang 在 ESTABLISHED 状态 - 应用进程异常退出，连接没走正常释放流程，Redis 端无法感知断连
为什么调高 timeout 和 maxclients 必须同步做
timeout 默认为 0（永不超时），这在生产环境极易引发连接堆积。尤其当客户端未主动关闭、网络抖动或应用异常退出时，Redis 会一直保留该连接。
推荐设为 300 秒（5 分钟），覆盖绝大多数业务周期。但光设 timeout 不够——如果 maxclients 还卡在默认 10000，而你的应用单机开 200 个连接池，10 台机器就直接打满。
二者必须协同调整：
- 先确认系统级
ulimit -n≥ 计划设置的maxclients（建议留 20% 余量） - 计算理论值：
maxclients ≈ (可用内存 × 0.7) ÷ 10KB，例如 64GB 内存服务器约 45000 -
CONFIG SET timeout 300+CONFIG REWRITE，再CONFIG SET maxclients 45000+CONFIG REWRITE - 集群模式下，每个分片节点都得单独执行，不能只改一个
改完不重启 Redis 进程，新限制不会加载；改完不验证 /proc/$(pidof redis-server)/limits，你永远不知道到底生效没。
