poolsize应按qps×平均延迟（秒）估算并上浮30%~50%，如qps=8000、p95延迟=1.2ms，建议设15起步，压测后调至20~30；需确保小于redis的maxclients限制且预留订阅连接余量。
PoolSize设多少才不卡顿
PoolSize不是越大越好，也不是照搬默认值（10 * runtime.GOMAXPROCS(0)）就能扛住高并发。它本质是“最大并发连接数”，设小了会频繁触发redis: connection pool timeout错误；设大了又可能耗尽文件描述符或触发Redis服务器的maxclients限制。
实际计算要结合QPS和单次操作耗时：
- 先用压测工具（如
ghz或自写benchmark）跑出稳定QPS和P95延迟 - 用公式粗估：
PoolSize ≈ QPS × 平均延迟（秒），再上浮30%~50%作为安全余量 - 例如：QPS=8000，P95延迟=1.2ms → 基础值≈9.6 → 建议设
PoolSize: 15起步，压测后调至20~30 - 注意Redis服务端限制：
CONFIG GET maxclients返回值要远大于你的PoolSize × 订阅goroutine数（订阅连接独占，不归还池）
MinIdleConns和MaxIdleConns怎么配才不冷启动
MinIdleConns决定连接池预热程度，MaxIdleConns控制空闲连接上限。两者不匹配会导致连接反复创建销毁，尤其在流量突增时明显卡顿。
生产环境推荐组合：
-
MinIdleConns设为PoolSize的50%~70%，比如PoolSize: 30→MinIdleConns: 15，确保服务刚启动就有足够热连接可用 -
MaxIdleConns设为PoolSize的60%~80%，避免空闲连接长期占着资源却不被复用，例如MaxIdleConns: 24 - 如果
MinIdleConns > MaxIdleConns，go-redis会静默忽略MinIdleConns，这点容易被忽略 - 检查
redis/internal/pool/pool.go里的checkMinIdleConns逻辑，它只在连接归还时触发，不是实时维护
ConnMaxIdleTime和ConnMaxLifetime为什么必须设
这两个参数不设，默认值（30分钟 / 0）在长稳运行的服务里极易引发隐蔽故障：旧连接因中间网络设备（如NAT网关、云负载均衡器）超时被静默断开，但客户端仍认为连接有效，后续读写直接卡死或报i/o timeout。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
真实线上建议值：
-
ConnMaxIdleTime设为5~15分钟，略小于Redis配置的tcp-keepalive（查CONFIG GET tcp-keepalive），比如Redis设120秒，这里就设90 * time.Second -
ConnMaxLifetime设为1~2小时，强制轮换连接，避免内存泄漏或TLS会话老化问题；设0（不限制）在K8s滚动更新或Redis节点迁移时大概率出问题 - 注意：
ConnMaxIdleTime和ConnMaxLifetime是独立触发的，只要任一条件满足，连接就会被关闭并重建
ReadTimeout/WriteTimeout配错会导致goroutine泄露
很多人把ReadTimeout和WriteTimeout当成“接口超时”来设，结果在Pipeline或订阅场景下，goroutine卡在read系统调用上不退出，最终OOM。
关键原则：
- 普通命令：设为业务能容忍的最短响应时间，比如
ReadTimeout: 300 * time.Millisecond - Pipeline：按总耗时估算，
ReadTimeout = 单命令超时 × 命令数 × 1.5（留出网络抖动余量） - Subscribe：必须设，且不能依赖
context.WithTimeout——因为rdb.Subscribe()返回的*redis.PubSub内部会起goroutine监听，超时需靠ReadTimeout兜底，否则永远阻塞 - 务必开启
ContextTimeoutEnabled: true，否则ctx.Done()对底层连接无影响
连接池参数不是调一次就万事大吉的事。每次发布新版本、升级Redis集群、或接入新业务模块前，都要重新验证PoolSize和超时组合是否仍匹配当前流量模型——尤其是订阅类长连接，最容易在半夜流量低谷时悄悄失效，等早高峰来了才爆发。
