短连接在 Redis 中严重伤性能，因其每次需完整 TCP 握手、认证、DB 切换与释放，局域网下单次开销达 1–3ms，超 GET 命令 5–10 倍，并引发 TIME_WAIT 端口耗尽。
为什么短连接在 Redis 里特别伤性能
Redis 本身是单线程 I/O，每次 connect() + auth + select + close() 都要走完整 TCP 握手、认证、DB 切换、连接释放流程。实测在局域网下，单次短连接开销常超 1–3ms，比一个简单 GET 命令还慢 5–10 倍。更麻烦的是，频繁 TIME_WAIT 会快速占满本地端口（尤其客户端密集部署时），直接触发 Cannot assign requested address 错误。
用连接池替代 new client() 是最直接解法
几乎所有主流 Redis 客户端都内置连接池（如 Python 的 redis-py 默认启用，Go 的 github.com/go-redis/redis/v9 要显式配置）。关键不是“有没有池”，而是池参数是否匹配真实负载：
-
max_connections别盲目设大：超过 200 后提升极小，反而增加内存和调度压力；建议从 32 起步，按QPS × 平均响应时间（秒） × 1.5估算 -
min_idle设为 0 更安全：空闲连接不保活，避免网络中断后残留失效连接 - 务必开启
health_check_interval（如 30s）：定期发PING探活，防止服务端主动断连后客户端还往死连接写数据 - Java 用户注意：
Jedis的GenericObjectPoolConfig中maxWaitMillis必须设合理值（比如 100ms），否则拿不到连接时会无限阻塞
禁用 tcp_nodelay 可能适得其反
有人听说 “关闭 Nagle 算法能降低延迟”，就给 Redis 连接加 TCP_NODELAY=1。但短连接场景下这毫无意义——连接刚建好就发命令然后关掉，Nagle 根本没机会起作用。反而在高并发下，大量小包会加剧内核协议栈负担。真正该关 tcp_nodelay 的，是长连接+高频小命令（如 Pub/Sub 或实时计数器更新）。
别让业务代码无意中制造短连接
常见陷阱藏在看似合理的封装里：
- HTTP 请求处理函数里每次 new 一个
redis.Client，哪怕只调一次GET—— 这等于把连接生命周期绑定到 HTTP 生命周期上 - 用了依赖注入框架（如 Spring Boot），但把
RedisTemplate声明为@Scope("prototype")，导致每次获取都是新实例 - 测试代码里用
with redis.Redis(...) as r:，生产环境忘了删，变成隐式短连接
检查方法很简单：抓包看 SYN → FIN 是否密集出现，或监控 Redis 的 connected_clients 指标是否随 QPS 剧烈抖动。
连接复用这事，本质是把“连接管理”从业务逻辑里剥离出来。越晚做，越容易在压测时被 TIME_WAIT 和连接超时拖垮。
