redis sentinel 管理大规模主从集群的核心是分层监控、分布式共识与可配置故障策略，专注高可用而非数据分片；需按业务域分组部署、统一配置管理、控制故障转移节奏，并配套可观测性与自动化响应。
合理规划 Sentinel 部署拓扑
避免单点 Sentinel，也避免每个主从组配一套独立 Sentinel 集群（成本高、难统一）：
- 按业务域或 Redis 实例重要性分组：例如核心交易用一组 3～5 个 Sentinel 节点管理 5～10 个主从对；日志缓存类可共用另一组
- Sentinel 进程尽量与 Redis 实例错开物理节点，防止单机故障同时带走 Redis 和 Sentinel
- 跨机房部署时，Sentinel 节点需满足“多数派”原则（如 5 节点，至少 3 个在可用区 A），避免脑裂
统一配置与动态发现
手动为每个主从组写 sentinel.conf 不现实。推荐方式：
Redis 8.2.3
下载
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 使用配置中心（如 Consul、Nacos）集中管理 master-name、ip:port、quorum、down-after-milliseconds 等参数，Sentinel 启动时拉取
- 通过
SENTINEL MONITOR命令动态添加主节点（配合脚本或 Operator），避免重启 Sentinel 进程 - 利用
SENTINEL SENTINELS <master-name></master-name>和SENTINEL MASTER <master-name></master-name>接口做状态巡检，集成到监控平台
控制故障转移节奏与影响面
大规模下自动 Failover 若无节制，可能引发雪崩：
- 设置合理的
quorum（触发投票所需 Sentinel 数）和failover-timeout（两次故障转移最小间隔），防止频繁切换 - 给从节点配置
replica-priority（数值越小越优先晋升），确保 SSD 机器、低负载、高同步延迟容忍度的节点优先当选 - 启用
sentinel parallel-syncs控制同时向多少个从节点发起同步，避免新主节点带宽打满 - 禁止对只读从节点设置
replica-priority 0，否则 Sentinel 会跳过它——这点常被忽略
配套可观测性与自动化响应
靠人工盯日志无法支撑大规模：
- 采集 Sentinel 的 INFO 输出（重点关注
+switch-master、+failover-end、-sdown等事件），接入 Prometheus + Grafana - 监听 Sentinel 发送的 Pub/Sub 消息（频道
__sentinel__:hello和__sentinel__:notify），触发告警或自动更新服务注册中心（如 Nacos、etcd） - 结合客户端 SDK（如 Lettuce、Jedis）的 Sentinel 支持，实现连接自动重定向，减少应用层改造
