连接复用省的是什么
短连接每次都要走一遍 TCP 三次握手、可选的 TLS 握手、认证与客户端初始化，这些往返不产生业务价值却实实在在占掉延迟与 CPU。高并发下连接建立速率本身会成为瓶颈，服务端还要为每条新连接分配缓冲与内存。连接池长期持有并复用连接，是客户端侧收益最直接的优化，前提是池大小与回收策略和服务端容量匹配。
基本信息
| 主要成本 | TCP 握手、TLS 握手、认证、客户端初始化 |
|---|---|
| 推荐方案 | 连接池复用长连接 |
| 服务端约束 | 每条连接占用文件描述符与缓冲，总量受 maxclients 限制 |
| 配套参数 | 池最大连接数、空闲回收时间、获取连接超时 |
| 验证方式 | INFO clients 看连接数，INFO stats 看 rejected_connections |
典型使用场景
- 高并发业务：每秒上万请求时，握手环节就会吃掉大量时间预算
- TLS 场景：握手开销远高于明文，复用带来的收益更明显
- 容器扩缩容：副本数变化让连接总数波动，池上限需要随之评估
- 故障恢复：池的健康检查决定重连是平滑还是风暴
- 服务端资源受限：用池把并发连接数压进可控区间
两端一起看
两端一起看
redis-cli INFO clients | grep -E 'connected_clients|maxclients' # 当前连接与上限
redis-cli INFO stats | grep rejected_connections # 是否出现过拒绝
redis-cli CONFIG GET maxclients # 核对服务端连接上限
redis-cli INFO clients | grep client_recent_max_input_buffer # 单连接缓冲峰值
# 客户端侧按库文档配置池（示例）：max=50, idle=10, acquire_timeout=200ms连接成本对照
| 动作 | 相对成本 | 说明 |
|---|---|---|
| 复用已有连接 | 一次请求一次往返 | 目标状态 |
| 新建明文连接 | 握手加往返 | 认证与初始化另算 |
| 新建 TLS 连接 | 显著高于明文 | 证书校验与会话协商都耗时 |
| 连接被拒绝 | 请求直接失败 | rejected_connections 上升说明已达上限 |
池不是越大越好：服务端为每条连接分配读写缓冲，连接数暴涨会推高内存并加重事件循环负担。按实测压出合适的池上限，比套用网上流传的经验值可靠。
池中空闲连接缺少健康检查时，取到一条已被对端关闭的连接，请求会在首次读写时报错。配合保活间隔与取用前校验，才能把这类偶发失败压下去。