1. 课程导论：微服务架构下Redis哨兵模式的地位与连接池调优的必要性

1.1 微服务架构中的缓存层困境

在微服务架构中，每个服务实例独立部署、独立扩展，但共享的数据层（尤其是缓存层）往往成为整个系统的并发瓶颈。Redis 作为高性能内存数据库，承担着会话缓存、分布式锁、热点数据加速等关键职责。然而，当数十甚至上百个微服务实例同时向 Redis 发起连接请求时，传统的单点 Redis 架构会暴露出以下问题：

• 单点故障风险：主节点宕机导致整个缓存层不可用，引发缓存雪崩。
• 连接数爆炸：每个微服务实例默认创建独立连接池，总连接数 = 服务实例数 × 连接池大小，极易耗尽 Redis 最大连接数。
• 资源竞争加剧：高并发下连接池内线程争抢连接，导致请求排队、超时甚至拒绝服务。

1.2 哨兵模式在微服务中的定位

Redis Sentinel（哨兵）模式为 Redis 提供了自动故障转移、主节点监控和通知机制。在微服务架构中，哨兵模式的核心价值体现在：

下图展示了微服务集群通过哨兵模式访问 Redis 的典型架构：

1.3 连接池调优的必要性

即使有了哨兵模式的高可用保障，微服务场景下的连接池配置不当仍会引发严重的性能问题。以下是三个必须进行连接池调优的核心原因：

1. 连接数上限冲突：Redis 默认最大连接数通常为 10,000（可通过 maxclients 配置）。假设有 50 个微服务实例，每个实例连接池大小为 200，则总连接数 = 50 × 200 = 10,000，恰好触达上限。一旦某个实例突发流量，连接池扩容将直接导致 Redis 拒绝新连接。
2. 连接池资源争抢：微服务实例内部，多个线程共享连接池。若 maxTotal 设置过大，线程等待连接的时间会急剧增加；若 maxWaitMillis 设置不合理，大量请求会因获取连接超时而失败。
3. 故障转移时的连接中断：哨兵切换主节点后，旧连接池中的连接全部失效。若客户端未实现连接池自动刷新，服务会持续向已宕机的主节点发送请求，导致大量报错。

1.4 常见连接池配置误区

以下表格总结了微服务团队在 Redis 连接池配置中容易踩入的误区及其后果：

1.5 本课程的核心内容预览

本课程将围绕以下主线展开，帮助学员掌握从理论到实战的完整调优路径：

• 哨兵模式原理与客户端适配：深入哨兵故障转移流程，讲解 Jedis、Lettuce 等客户端如何与哨兵交互。
• 连接池核心参数详解：逐项分析 maxTotal、maxIdle、minIdle、maxWaitMillis、testOnBorrow、testWhileIdle、timeBetweenEvictionRunsMillis 等参数的作用与调优策略。
• 并发压力测试与监控：使用 JMeter、Redis-benchmark 等工具模拟微服务并发场景，结合 Redis INFO 命令和 Grafana 监控连接池状态。
• 实战调优案例：针对秒杀系统、社交 Feed 流、实时排行榜等典型微服务场景，给出具体的连接池配置方案。
• 连接池自动刷新与哨兵感知：实现客户端连接池在哨兵切换后的自动重建，避免服务中断。