redis哨兵不支持动态扩容，因其仅负责故障检测与主从切换，无数据分片和槽位迁移能力；扩容需依赖客户端（如lettuce配置replica_preferred）或proxy层实时感知哨兵事件并更新路由。
Redis 哨兵（Sentinel）本身不支持动态扩容——它只管故障检测、主从切换和配置通知，不参与数据分片、槽位迁移或节点增减。所谓“哨兵实现动态扩容”，是常见误解，真正承担扩容职责的是客户端或代理层。
为什么 Sentinel 不能直接扩容？
哨兵模式下所有节点都保存全量数据，新增一个 slave 节点只是增加读副本，不改变数据分布或负载结构。它没有槽位（slot）概念，也不提供自动重分片能力。
-
Sentinel不监听客户端请求，不代理流量，只暴露管理命令（如SENTINEL slaves） - 扩容从节点 ≠ 扩容系统吞吐：若客户端仍只连主节点，新从节点完全闲置
- 哨兵不会主动通知客户端“现在多了个可用从节点”，需靠客户端轮询或 Proxy 订阅事件
Lettuce 客户端如何配合 Sentinel 实现轻量级读扩容
不引入 Proxy 时，Lettuce 是最可行的方案，但它依赖正确配置与生命周期管理：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 初始化时必须用
RedisURI指向哨兵地址（如redis-sentinel://127.0.0.1:26379/monitor-name），而非直连某节点 - 启用读策略：
ClientResources.builder().ioThreadPoolSize(4).computationThreadPoolSize(4).build()+ReadFrom.REPLICA_PREFERRED - 连接池需设置
maxInactiveTime和validateWhileIdle，否则失效从节点可能长期滞留连接池 - 关键限制：Lettuce 不会自动剔除 lag 过大的从节点（如
INFO replication中master_repl_offset - slave_repl_offset > 1000000），需自行扩展健康检查逻辑
Proxy 层才是动态读扩容的实际执行者
真正能“感知哨兵状态→发现新从节点→过滤不可用实例→实时更新路由表”的，只有 Proxy。它不是可选组件，而是必要环节：
- 必须解析
SENTINEL slaves <master-name></master-name>返回的flags字段，例如slave,online才加入读池，slave,sdown或slave,disconnected必须剔除 - 扩容从节点后，不能立刻转发流量：要等
SENTINEL slaves中该节点的lag≤ 100（单位：毫秒级复制延迟）才视为就绪 - 推荐用事件驱动替代轮询：
SENTINEL subscribe +slave +sdown -slave，避免频繁拉取造成哨兵压力 - 常见踩坑：Proxy 把
ROLE命令发到从节点查角色，但某些旧版 Redis 从节点禁用ROLE，导致识别失败——应改用INFO replication解析
哨兵动态扩容的复杂点不在加机器，而在状态同步的时效性与一致性：哨兵的 +slave 事件发出、Proxy 收到并生效、客户端连接池刷新、旧连接自然淘汰——这整个链路存在数秒级延迟，且任意一环卡住都会导致读请求打到异常节点。业务对读一致性要求越高，越需要在 Proxy 层做细粒度控制，比如按 slave_priority 排序、按 lag 分档路由、甚至结合监控指标动态降级。
