redis连接池需按流量、服务端能力、网络行为联动调优：理论连接数×2.5～3，minidle设为maxtotal的40%～60%，集群须分读写池并配置readfrom=replica_preferred，acquiretimeout宜设800～1200ms。
Java 应用要让 Redis 在高并发下跑出高网络吞吐，连接池不是“配个数就行”，而是得按真实流量特征、服务端能力、网络行为三者联动来调。核心目标是：让连接数既不卡住请求，也不拖垮 Redis 服务端调度。
连接池大小不能只算 QPS × 耗时
理论最小连接数 = QPS × 平均响应时间（秒），但这只是起点。实际必须乘以 2.5～3 的安全系数，因为：
- TCP 网络抖动会让单次操作耗时翻倍，尤其跨机房或云厂商内网不稳定时
- BLPOP、WATCH、EVAL 这类阻塞/事务命令会独占连接，无法复用
- Redis Cluster 中一次 GET 可能触发 MOVED 重定向，额外多占一次连接周期
例如：业务峰值 8000 QPS，平均耗时 3ms → 理论需 24 个连接 → 实际建议设 maxTotal = 64～72。
空闲连接要保底，不能归零
minIdle 设为 0 是常见误区。冷启动时所有连接都要重建，而 Redis Cluster 握手、ASK/MOVED 校验、AUTH 认证都会拖慢首连，导致批量请求卡在 getConnection() 上。
推荐：minIdle = maxTotal 的 40%～60%。比如 maxTotal=64，就设 minIdle=24 或 32。再配合 testWhileIdle=true（空闲时检测）+ testOnBorrow=false（借时不检测），减少 ping 开销。
集群场景必须拆分读写连接池
JedisCluster 不支持自动读写分离连接池管理。默认所有命令都打向 master，容易把 master 连接池打满，而 slave 白白闲置。
用 Lettuce 或 Redisson 才能精细控制：
- masterConnectionPoolSize ≥ 48（保障写和强一致性读）
- slaveConnectionPoolSize ≥ 从节点数 × 每节点预期并发读连接数（如 3 个从节点 × 12 = 36）
同时显式配置 readFrom = ReadFrom.REPLICA_PREFERRED，否则读请求不会真正落到 slave。
等待超时要设得“有脾气”
acquireTimeout（Lettuce）或 maxWait（Jedis）设成 5 秒，等于放任线程堆积。一旦连接池排队持续超 1 秒，说明容量已失衡，继续等只会引发下游级联超时。
建议值：800～1200ms。并实时监控 tasksQueueLength（Lettuce）或 jedisPool.getNumWaiters()（Jedis），连续 3 秒 > 5 就该告警并触发降级。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
