max-active、min-idle、acquiretimeout配置不当会导致连接池失效或拖垮redis：max-active需按min(cpu核数×3, ceil(峰值qps÷单连接qps))估算，避免超maxclients；min-idle应设5–10防冷启动抖动，不可为0；acquiretimeout必须显式设置（如150ms），禁用-1或0以防线程卡死。
max-active、min-idle、acquireTimeout 这几个参数设错，连接池不是压根没用上，就是把 Redis 实例拖垮。
max-active 不是越大越好，得看 CPU 和 maxclients
max-active（或 size、maximum）本质是并发连接上限，但它的合理值取决于两个硬限制：
- Redis 服务端的
maxclients配置（默认 10000），必须大于等于客户端连接池总和 - 客户端所在机器的 CPU 核心数：线程争抢连接比争抢 CPU 更容易引发锁竞争
常见错误是直接设成 200 或 500，结果所有服务加起来超了 maxclients，Redis 开始拒绝新连接，日志里反复出现 ERR max number of clients reached
建议按这个公式初步估算：max-active = min( (CPU 核心数 × 3), ceil(峰值 QPS ÷ 单连接 QPS) )
其中单连接 QPS 可实测：用一个空闲连接连续 SET / GET，取稳定值（通常 2k–8k，取决于网络延迟和命令复杂度）
min-idle 要防冷启动抖动，但别设成 0
min-idle 是连接池里常驻的“热连接”数量。设为 0 意味着每次流量突增都要新建连接——TCP 握手 + 认证 + 初始化耗时叠加，首请求延迟飙升。
典型场景：凌晨低峰期后突然来一波秒杀流量，min-idle=0 的池子前 100 个请求会卡在连接建立上。
合理值参考：
- Web 应用（每实例 4–8 核）：设
min-idle=5到10 - 后台任务服务（长周期、低频）：可设
min-idle=1或2 - 注意：Lettuce 默认
min-idle=0，Spring Boot 必须显式配置，否则等于没开池
acquireTimeout 必须设，且不能依赖默认值
很多客户端（如 node-redis、redis-py）默认 acquireTimeout 是无限等待或几秒，线上一旦连接池满、又没超时，线程就卡死，最终触发线程池耗尽、HTTP 请求超时雪崩。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键点：
- 超时值应略大于 P99 的 Redis 命令耗时（比如 P99 是 80ms，设
acquireTimeout=150） - 绝对不要设成 -1 或 0（等同于无限等待）
- 超时后必须有 fallback 逻辑，比如降级读本地缓存，而不是直接抛异常
示例（node-redis）：
const pool = await createClientPool({}, {
minimum: 5,
maximum: 30,
acquireTimeout: 150 // ms
});
connection_idle_time 和 connection_lifetime 容易被忽略，但影响稳定性
连接池不是建完就万事大吉。长时间存活的连接可能因网络中断、防火墙回收、Redis 主从切换而失效，但池子不知道，还会继续分发给业务线程，导致随机 Connection reset 或 broken pipe。
所以必须配：
-
connection_idle_time：空闲连接多久后关闭（推荐30m） -
connection_lifetime：不管忙闲，连接最多活多久（推荐1h） - 同时开启
keep_alive（TCP 层保活），避免中间设备静默断连
这些参数在 Redis++、Lettuce、phpredis 中都有对应字段，但名字不统一：connection_idle_time 在 Redis++ 叫 connection_idle_time，在 Lettuce 是 timeBetweenEvictionRuns + minEvictableIdleTimeMillis 组合生效。
真实问题往往不出现在峰值时刻，而出现在连接老化、服务重启、网络抖动后的那几分钟——那时没配生命周期管理的池子，就开始批量报错。
