哨兵配置中 sentinel monitor 的第三个参数填判定主库下线所需投票数，须过半且至少为2，如3个哨兵填2、5个填3；填1易致脑裂；所有哨兵该值必须一致，且不超总数。
哨兵配置文件里 sentinel monitor 的第三个参数到底填几？
填 2，不是 1，也不是哨兵节点总数。这个值是「判定主库客观下线所需的哨兵投票数」，必须满足「过半且至少为 2」。比如你部署了 3 个哨兵，这里填 2；5 个哨兵就填 3。填 1 会导致脑裂风险——任意一个哨兵网络抖动就可能误判主库下线，触发不必要的切换。
常见错误现象：+sdown master mymaster 127.0.0.1 6379 日志频繁出现，但主库明明在线；或者切换后旧主库恢复，却没被降为从库，形成双主。
- 必须确保所有哨兵节点的
sentinel monitor配置完全一致（名称、IP、端口、quorum 值） - quorum 值不能大于哨兵总数，否则永远无法达成共识
- 如果 Redis 主库启用了密码，必须在哨兵配置中补上
sentinel auth-pass <master-name> <password>
哨兵启动后一直报 +tilt 或 +reset-after-panic
这是哨兵进程进入「倾斜模式（Tilt Mode）」的标志，说明它检测到自身时钟异常或事件循环严重延迟，不再信任自己的判断逻辑。根本原因通常是：系统时间被 NTP 突然校准、CPU 过载导致事件处理超时、或磁盘 I/O 阻塞了哨兵的定时任务。
使用场景：你在容器或低配云主机上部署哨兵，又开了 cron 定时同步时间，就很容易触发。
- 检查系统时间是否稳定：
ntpq -p看 offset 是否持续大幅跳变 - 用
redis-cli -p 26379 info sentinel | grep tilt确认当前是否处于 tilt 状态 - 临时缓解：重启哨兵进程；长期解决需优化宿主机资源分配，禁用激进的 NTP step 调整（改用 slewing）
主从切换后客户端连不上新主库？
哨兵只负责发现和切换，不负责通知客户端。客户端仍拿着老的主库地址发请求，自然失败。这不是哨兵的问题，而是客户端集成方式不对。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
性能影响：硬编码 IP+端口的直连方式，在故障切换后会持续失败直到超时重试，RT 延长数秒甚至分钟级。
- Java 应用推荐用
JedisSentinelPool或Lettuce的RedisSentinelConfiguration，它们会定期向哨兵询问sentinel get-master-addr-by-name获取最新主库地址 - Python 用
redis.sentinel.Sentinel实例，调用sentinel.discover_master('mymaster')动态获取 - 切忌自己写轮询逻辑去查哨兵——哨兵响应慢或返回空时容易引发雪崩
为什么哨兵 + 主从还是扛不住写流量突增？
哨兵保障的是「高可用」，不是「高性能」。主从复制是异步的，从库不参与写操作；所有写请求必须打到单点主库。当写 QPS 突破主库瓶颈，哪怕哨兵再灵敏，也救不了吞吐下降和连接堆积。
容易被忽略的地方：很多人以为“上了哨兵就等于分布式”，其实哨兵管理的仍是单主架构。真正的水平扩展要靠分片（如 Redis Cluster 或 Codis），而哨兵只是 Cluster 中每个分片的 HA 组件之一。
如果你的应用写多读少、且无法接受分片带来的 key 分布复杂性，那就得接受主库是天然瓶颈——哨兵能做的，只是让这个瓶颈挂掉时，换另一个同规格的机器顶上而已。
