Redis客户端连接耗尽本质是文件描述符被空闲或长连接占满，需协同配置timeout（推荐300秒）与maxclients（受ulimit和内存限制），并配合连接池、CLIENT LIST监控及lsof排查僵尸连接。
Redis客户端句柄连接耗尽，本质是系统文件描述符（file descriptor）被大量空闲或长连接占满，导致新连接无法建立。核心要从两个参数入手：timeout控制单个连接的生命周期，maxclients控制并发连接上限。二者配合不当，就会出现“连得上但撑不久”或“连不上还查不出原因”的问题。
合理设置 timeout 释放闲置连接
timeout 默认为 0，即永不超时——这在生产环境极易引发连接堆积。尤其当客户端未主动关闭、网络抖动或应用异常退出时，Redis 会一直保留该连接，直到进程重启或系统资源耗尽。
- 推荐值设为 300 秒（5 分钟）：覆盖绝大多数业务请求周期，兼顾响应及时性与连接稳定性
- 若使用分布式锁等强时效场景，可设为 60～120 秒；但需确保业务逻辑能在超时前完成锁操作
- 动态验证命令：
CONFIG GET timeout查当前值，CONFIG SET timeout 300立即生效，再执行CONFIG REWRITE持久化到配置文件 - 注意：集群模式下，每个分片节点都需单独配置，不可只改一个
科学调整 maxclients 避免硬性拒绝
maxclients 不是越大越好，它受限于系统级限制（如 ulimit -n）和 Redis 单连接内存开销（约 10KB）。盲目调高可能触发 OOM 或系统级报错 “Too many open files”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 先检查系统上限：
ulimit -n，确保其 ≥ 你计划设置的 maxclients 值（建议留 20% 余量） - Redis 默认 10000，对中等规模服务通常够用；若监控发现
rejected_connections持续增长，说明已达上限 - 计算参考公式：maxclients ≈ (可用内存 × 0.7) ÷ 10KB，例如 64GB 内存服务器，理论建议值约 45000
- 配置后务必重启 Redis 或用
CONFIG REWRITE生效，并观察INFO clients中connected_clients和maxclients是否匹配
配合连接池与监控闭环验证
光调参数不够，必须有配套手段防止问题复发。
- 客户端强制使用连接池（如 JedisPool、redis-py 的 ConnectionPool），设置
max_connections小于 Redis 的 maxclients，避免单应用打爆全实例 - 定期执行
CLIENT LIST，重点关注idle字段：若大量连接 idle > timeout，说明客户端未正确复用或释放连接 - 监控关键指标：
connected_clients（当前连接数）、rejected_connections（拒绝数）、total_connections_received（历史总连接数），三者趋势结合看是否真有泄漏 - Linux 层面辅助排查：
lsof -i :6379 | wc -l对比 Redis reported 连接数，差值过大说明存在“僵尸连接”或 fd 泄漏
不复杂但容易忽略：timeout 和 maxclients 是一对联动开关，调高 maxclients 却不设 timeout，等于给连接池开了个漏水的口子；设了 timeout 却不配连接池，又会造成频繁建连开销。真正稳住句柄资源，靠的是参数+工具+监控三者咬合。
