Redis连接数暴涨时，盲目调大maxclients会掩盖问题甚至引发OOM；真实瓶颈在系统级限制、连接池泄漏、僵尸连接及缺乏网络层防护。
Redis连接数暴涨时，maxclients不是万能解药
直接调大maxclients只会掩盖问题，甚至加速崩溃。Redis默认maxclients是10000，但真实瓶颈往往在系统级：Linux的ulimit -n、TCP连接队列（tcp_max_syn_backlog）、内存（每个连接约1KB+开销）。盲目设成50000，可能触发OOM Killer杀掉Redis进程。
- 先查真实上限：
redis-cli info clients | grep connected_clients+cat /proc/$(pidof redis-server)/limits | grep "Max open files" - 服务端合理值建议：生产环境设为
min(10000, 系统ulimit-20%)，留余量给其他进程 - 改完必须重启或用
CONFIG SET maxclients N，但注意该命令不持久化，需同步写入redis.conf
客户端连接池泄漏比连接数多更致命
连接池max_connections=100，但代码里忘了close()或没进finally块，10个线程反复借连不还，几分钟就占满——此时connected_clients持续上涨，rejected_connections开始计数，错误日志里出现ERR max number of clients reached。
- Java Jedis务必用try-with-resources：
try (Jedis jedis = pool.getResource()) { ... }，自动close() - Python redis-py别手动调
connection_pool.get_connection()，直接用redis.Redis(connection_pool=pool)实例，它内部会管理释放 - 检查
redis-cli info stats里的expired_keys和evicted_keys突增——这往往是连接泄漏导致内存不足、触发淘汰的间接信号
用timeout参数自动清理“睡死”的连接
客户端异常退出（如Pod被K8s强杀、网络闪断），连接不会自动关闭，Redis会一直维持这个socket，直到超时。默认timeout 0即永不超时，这些僵尸连接越积越多，最终挤占全部maxclients。
- 线上必须启用：
CONFIG SET timeout 60（单位秒），60~300之间按业务心跳周期定 - 注意副作用：长轮询、慢查询场景下，60秒可能太短，会误杀正常连接；此时应改用应用层心跳+
CLIENT IDLE TIME主动探测 - 该配置对已存在的空闲连接立即生效，无需重启，但要确认你的Redis版本≥4.0（低版本不支持动态设置）
防火墙+IP限流才是第一道防线
DDoS或恶意扫描器打进来，根本不需要等它连上Redis——在内核层面就该拦截。靠Redis自身认证（requirepass）或rename-command只能防君子，防不住海量SYN包。
- 云厂商安全组/iptables只放行可信IP段，例如：
iptables -A INPUT -p tcp --dport 6379 -s 10.0.0.0/8 -j ACCEPT - 配合
connlimit模块限制单IP并发：iptables -A INPUT -p tcp --dport 6379 -m connlimit --connlimit-above 10 -j REJECT - Redis本身不提供IP白名单，别信“
bind 127.0.0.1就能防住”——Docker桥接或K8s Service可能绕过bind
真正难处理的是合法业务流量突增（比如秒杀），这时候光靠限连接数不够，得结合分布式限流（令牌桶+Lua原子脚本）和降级开关。但那是另一个问题了。
