根本原因是客户端将从节点视为独立服务端并为每个从节点创建独立连接池。开启读写分离后，Jedis/Lettuce会主动发现并连接所有从节点，导致连接数激增、从库负载过高；解决关键是禁用客户端拓扑发现，改用代理层统一入口或手动控制连接复用。
Redis主从架构下客户端为何会疯狂新建连接
根本原因不是主从复制本身，而是客户端默认把 slave 当成独立节点去连——哪怕你只配了一个 master 地址，只要开启了读写分离（比如 JedisPool + readFrom = SLAVE），客户端就会主动发现所有从节点 IP，并为每个从节点单独建一套连接池。
常见现象：redis-cli -h slave_ip info clients 显示 connected_clients 突增数倍，且大量连接 idle 时间极短；监控里从库 CPU 和网络流量明显高于主库。
- Spring Data Redis 默认使用
LettuceClientConfigurationBuilder时，若配置了ReadFrom.SLAVE_PREFERRED，它会拉取整个拓扑并为每个节点维护独立连接池 - Jedis 不支持自动拓扑发现，但如果你手动把多个从库地址塞进
JedisPoolConfig，它也会为每个地址新建一个池 - Lettuce 的
RedisURI若用redis://host:port单点写法，却启用了StaticMasterSlaveTopologyProvider，同样触发多池行为
如何让客户端复用同一组连接访问所有从库
核心思路：禁止客户端「感知」多个从节点，改由服务端或中间层做负载分发。不是不让读从库，而是不让客户端自己挑从库。
- 用代理层（如 Redis Proxy、Twemproxy 或自研 LB）统一暴露单个 VIP 或域名，后端转发到健康从库，客户端只连这一个入口
- Spring Boot 中禁用 Lettuce 自动拓扑发现：设置
spring.redis.lettuce.cluster.refresh.period=0，并显式指定spring.redis.url=redis://proxy-host:6379 - 如果必须直连，Lettuce 可用
MasterSlaveServersConfig配合ReadFrom.MASTER+ 应用层按需选从 —— 但此时你要自己实现getSlaveConnection()并复用已有连接，不能每次 new 一个StatefulRedisConnection - 检查是否误开了
spring.redis.lettuce.pool.max-active过大（比如 200），而实际只需要 20～50；每多一个从节点，这个值就会被乘上节点数
连接池参数调优的关键数值怎么设
不是越大越好，也不是越小越省，关键看你的命令 RT 和并发模型。Letture 默认的 max-active=8 在高并发读场景下极易打满，但盲目调到 200 会导致从库瞬间涌入上千连接。
-
max-active建议 = （QPS × P99 RT in seconds）× 1.2；例如 QPS=500、P99=20ms → 500 × 0.02 × 1.2 ≈ 12 -
min-idle设为max-active的 20%～30%，避免冷启动时反复创建连接 -
max-wait别设成 -1（无限等待），建议 100～300ms，超时直接报错比卡住线程更可控 - 务必关闭
test-on-borrow（Lettuce 对应validateConnectionOnCreate），它会让每次取连接都发PING，加重从库负担
验证是否真正在复用连接
最直接的办法不是看应用日志，而是抓包或查 Redis 实例本身的状态。
- 在从库执行
client list，过滤出你的客户端 IP，观察addr字段是否只有少量 distinct IP:port 组合（理想是 1～3 个），而不是几十上百个 - 用
tcpdump -i any port 6379 -w redis.pcap抓包后用 Wireshark 查看 TCP 握手次数 —— 优化后应明显少于部署前 - Lettuce 可开启
logging.level.io.lettuce.core=DEBUG，搜索日志中Creating connection to出现频次，正常应只在初始化或重连时出现，而非每次操作 - 注意：Spring Boot Actuator 的
/actuator/health或/actuator/metrics不反映真实连接数，它们只统计连接池内部状态，不包含底层 socket 数量
真正难处理的是那些隐式触发拓扑刷新的场景，比如 DNS 轮询、K8s Service Endpoint 变更、或者 Lettuce 的 PeriodicRedisClusterTopologyRefresh 被意外启用 —— 这些不会报错，但会悄悄重建连接池。
