高并发下redis连接池必须按qps×耗时×2.5～3设maxtotal，minidle设为maxtotal的40%～60%，并区分master/slave连接池大小，配合acquiretimeout≤1200ms与实时监控，否则瞬时流量必导致连接耗尽。
连接池参数配不对，再强的Redis集群也扛不住瞬时流量。高并发下连接耗尽、超时堆积、响应延迟飙升，根本不是Redis性能问题，而是客户端连接池没调好。
为什么maxTotal不能只看QPS × 耗时
公式 理论连接数 = QPS × 平均耗时（秒） 是起点，但实际必须叠加三个放大因子：
- 网络抖动：TCP重传、跨机房延迟会让单次操作耗时翻倍甚至更高
- 命令阻塞：
BLPOP、WATCH类操作会独占连接，不参与复用 - 集群路由开销：在Redis Cluster中，一次
GET可能触发MOVED重定向，额外消耗连接周期
生产建议按公式结果 × 2.5～3 设置 maxTotal，例如 8000 QPS × 3ms = 24 → 实际设为 64～72。JedisPoolConfig 中若只设 setMaxTotal(10)，基本等于给高并发埋雷。
minIdle设太低会导致冷启动雪崩
连接池空闲连接归零后，新请求进来要重新建连，而Redis Cluster节点握手、ASK/MOVED校验、AUTH认证都会拖慢首连。这不是“慢一点”，是批量请求卡在getConnection()上。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
-
minIdle建议设为maxTotal的 40%～60%，比如maxTotal=64，则setMinIdle(24)或32 - 避免设为 0 —— 这会让连接池每次扩容都从零开始，失去“预热”意义
- 配合
testOnBorrow(false)+testWhileIdle(true)，减少借连接时的ping开销
Redis Cluster下必须区分masterConnectionPoolSize和slaveConnectionPoolSize
用Redisson或Lettuce连集群时，读写分离不是自动的——默认所有命令都打向master，除非显式用readFrom策略。但即使开了READ_FROM_SLAVE，连接池也不自动拆分。
- 不配置时，所有读请求仍争抢 master 连接池，
masterConnectionPoolSize必须足够大 - 正确做法：设
masterConnectionPoolSize=48、slaveConnectionPoolSize=32，且确保slaveConnectionPoolSize≥ 从节点数 × 每节点预期并发读连接数 - 注意：JedisCluster 不支持该粒度控制，换Lettuce或Redisson才能精细拆分
acquireTimeout和maxWait不是越长越好
等待超时设成 5s 看似稳妥，实则掩盖了真实瓶颈。当队列积压持续超过 1s，说明连接池已失衡，继续等只会让线程堆积、线程池打满、下游超时级联。
-
acquireTimeout（node-redis）或maxWait（Jedis）建议设为 800～1200ms - 同时开启监控：
tasksQueueLength（node-redis）、jedisPool.getNumWaiters()（Jedis），一旦连续 3 秒 > 5，立刻告警并降级 - 不要依赖
blockWhenExhausted=true撑住流量 —— 它只是把问题从Redis侧转移到应用线程侧
真正难的不是算出那几个数字，而是把连接池当成一个有状态的中间件来观测：它什么时候开始排队，哪些命令在吃连接，空闲连接为什么迟迟不回收。参数只是杠杆，杠杆支点是你对业务流量模式的理解。
