应停用短连接模式，强制启用并调优连接池，禁用短连接下的tcp_nodelay，服务端配合收敛time_wait与合理设置timeout。
核心问题不在Redis业务逻辑，而在连接生命周期管理——短连接让Redis服务器反复执行连接建立与释放的系统级操作，大量消耗CPU在listSearchKey、freeClient等内核态路径上，而非处理实际命令。实测显示：相同QPS下，短连接场景中listSearchKey CPU占比远超readQueryFromClient，服务器“不务正业”地忙于清理连接，性能直接腰斩。
立即停用短连接模式
所有业务入口必须杜绝每次请求新建Redis客户端实例的行为。典型错误包括：
- HTTP handler里写
redis.NewClient()或with redis.Redis() as r: - Spring Boot中将
RedisTemplate设为@Scope("prototype") - AI服务/图片处理函数中隐式初始化新连接
验证方式简单：抓包观察SYN/FIN是否密集交替；或监控connected_clients指标是否随QPS剧烈抖动（正常长连接应平稳）。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
强制启用并调优连接池
连接池不是“有就行”，参数失配等于没开：
-
max_connections建议从32起步，按公式
QPS × 平均响应时间（秒）× 1.5估算，超过200后收益极低，反而增加内存与调度压力 - min_idle设为0更安全——空闲连接不保活，避免网络中断后残留失效连接
- health_check_interval必须开启（如30s），定期发PING探活，防止往已断连接写数据触发重传与超时
- Java用户特别注意：
Jedis的maxWaitMillis务必设合理值（如100ms），否则连接获取失败时会无限阻塞
关闭无意义的TCP_NODELAY优化
短连接场景下禁用TCP_NODELAY=1。因为连接刚建好就发命令随即关闭，Nagle算法根本来不及生效；强行关闭反而导致大量小包冲击内核协议栈，加重Sys态负担。该选项只对长连接+高频小命令（如Pub/Sub、实时计数器）有意义。
服务端层面辅助收敛
虽主要责任在客户端，但可配合服务端降低影响：
- 检查
tcp_fin_timeout和net.ipv4.ip_local_port_range，避免TIME_WAIT端口耗尽引发Cannot assign requested address - 确认
timeout配置合理（如设为300s），避免健康长连接被误杀后频繁重连 - 升级Redis至6.0+，其
freeClient路径已有部分优化，减少listSearchKey调用频次
