Redis 连接管理与熔断治理

Redis 连接数打满往往不是单一原因，而是连接池配置不当 + timeout=0 + 缺少熔断机制 三个因素叠加的结果。核心教训：timeout=0 在生产环境是高风险配置。

连接机制

Redis 单线程事件循环，每个客户端占用一个 fd。

maxclients 必须联动调整： Redis 配置 → ulimit → fs.file-max → limits.conf，缺一不可。

排查命令速查

# 连接概况
redis-cli INFO clients                           # connected_clients / maxclients

# 连接分布
redis-cli CLIENT LIST | awk '{print $2}' | cut -d= -f2 | cut -d: -f1 \
  | sort | uniq -c | sort -rn | head -10        # 各 IP 连接数

# 僵尸连接（idle 过大）
redis-cli CLIENT LIST | grep -E "idle=[0-9]{4,}"

# 系统限制检查
cat /proc/$(pidof redis-server)/limits | grep "Max open files"
cat /proc/sys/fs/file-nr

快速止血

连接池配置

<!-- Jedis Pool 生产推荐 -->
<property name="maxTotal" value="50"/>         <!-- 单节点 20~100 -->
<property name="maxIdle" value="20"/>
<property name="minIdle" value="5"/>           <!-- 新版本发布时 minIdle 翻倍 -->
<property name="maxWaitMillis" value="2000"/>  <!-- 必须设，防无限等待 -->
<property name="testWhileIdle" value="true"/>
<property name="timeBetweenEvictionRunsMillis" value="60000"/>

关键原则：

• maxTotal 不是越大越好。Redis 处理 10000 个空闲连接 vs 500 个活跃连接的开销完全不同
• 设 maxWaitMillis（建议 1000~3000ms），避免线程无限等待
• 用 try-with-resources（Jedis 3.x+）或 finally 确保连接归还
• 发布过程中监控连接数变化，发现异常立即回滚

熔断与降级

// 指数退避重试
int baseDelay = 100;
for (int i = 0; i < maxRetries; i++) {
    try { return jedisPool.getResource(); }
    catch (Exception e) { Thread.sleep(baseDelay * (long)Math.pow(2, i)); }
}

应用侧必须有熔断机制。否则单一组件故障级联扩散形成雪崩。

雪崩链路

连接满 → 获取连接失败 → 无熔断 → 重试阻塞线程
→ 线程池打满 → 健康检查超时 → 注册中心摘除节点
→ 流量转移 → 剩余节点也打满 → 全面不可用

注册中心选型对比参见 [[registry-center-comparison]]（Nacos/ZK/Consul 深度对比）。

连接代理收敛

大规模直连：应用 × 50 个 → Redis         (M × N 连接)
代理收敛：  应用 × 50 个 → 代理 → Redis  (M + N 连接)

推荐：Twemproxy / Predixy。增加 0.1~0.5ms 延迟，但显著降低连接数。

监控告警

# Prometheus
redis_connected_clients / redis_config_maxclients
# > 80% Warning | > 90% Critical | rejected_connections > 0 → P0 Emergency

关联页面