Redis连接卡在TIME_WAIT是客户端短连接滥用所致：微服务频繁新建并关闭连接，触发Linux内核强制维持60秒TIME_WAIT状态，导致本地端口耗尽；须全局复用ConnectionPool、禁用close()、合理配置max_connections与health_check_interval，并规避K8s下IP漂移与DNS缓存问题。
为什么微服务里Redis连接总卡在TIME_WAIT
根本不是Redis服务端的问题，而是每个微服务实例都默认新建短连接、用完就关——Linux内核在客户端主动关闭时强制维持TIME_WAIT状态60秒（2×MSL），端口无法复用。当QPS高、实例多、部署密（比如K8s里几十个Pod），ss -tan state time-wait sport = :6379 | wc -l轻松破万，本地端口池迅速耗尽，新连接直接超时失败。
redis-py连接池必须全局单例且禁用close()
Python微服务里最常见错误是把redis.Redis()写在函数里或每次请求都初始化：
def handle_request():
r = redis.Redis(host='redis', port=6379) # ❌ 每次新建连接
return r.get('key')正确做法是：进程启动时初始化一次ConnectionPool，全局复用；绝不在业务逻辑里调用connection.close()或pool.disconnect()——连接应在使用后自动归还池中。
-
max_connections设为预估峰值QPS的1.5–2倍（例如QPS 800 → 设1600），别用默认值 -
timeout=5必须显式设置，否则卡住的socket不归还，间接逼出更多短连接 -
health_check_interval=30（非0），让空闲连接定期探测，避免僵死连接占坑 - 若用FastAPI/Starlette，把
redis.Redis(connection_pool=pool)挂到app.state.redis，而非依赖DI容器每次重建
K8s环境要防IP漂移+连接池跨Pod失效
Pod重启或滚动更新后IP变化，旧连接池里缓存的socket可能指向已销毁的网络栈，触发异常关闭，加剧TIME_WAIT堆积。不能只靠客户端配置解决：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 在Deployment里加
terminationGracePeriodSeconds: 30，给连接池留出优雅释放时间 - Service不要配
externalTrafficPolicy: Local（会绕过kube-proxy，放大源IP波动） - 若Redis走ClusterIP，客户端DNS缓存要设短（如
python -m pip install dnspython+ 自定义resolver），避免解析到已下线Pod的IP - 考虑用Unix socket通信（需Redis 6.0+ & 同机部署），彻底避开TCP状态机和端口争抢
验证是否真解决问题，别信日志信连接态
应用日志说“Connected”不代表连接被复用。上线后必须在宿主机（或Pod内）执行：
ss -tan state time-wait sport = :6379 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -5如果输出里全是同一个客户端IP（即你的微服务Pod IP），且数量稳定在几百以内（而非几千），说明连接池生效；如果仍是多个不同IP高频出现，大概率是某处代码偷偷new了新client，或者框架（如某些ORM插件）自动初始化了独立连接池。
最隐蔽的坑是异步场景：用aioredis时没await pool.disconnect()不算问题，但若在async def里写了r = aioredis.from_url(...)又没持久化引用，每次协程都新建底层连接——这种泄漏不会报错，但TIME_WAIT会稳步爬升。
