sentinel monitor 用于让哨兵监控指定主节点，而非添加哨兵节点；新哨兵需独立启动并配置相同 monitor 参数，通过 __sentinel__:hello 频道自动发现集群，quorum 决定故障判定阈值而非哨兵数量。
sentinel monitor 是用来加主节点，不是加哨兵节点
很多人误以为 SENTINEL MONITOR 是往哨兵集群里“添加新哨兵”，其实它只做一件事：让当前这个哨兵开始监控某个 Redis 主节点。新哨兵进程本身必须独立启动、独立配置，不能靠其他哨兵“拉进来”。
真正添加一个哨兵节点，就是启动一个新的 redis-sentinel 进程，并确保它的 sentinel.conf 里有和已有哨兵一致的 sentinel monitor 配置（即监控同一个主节点），且网络互通。
- 新哨兵的
port必须唯一（不能和其他哨兵冲突，比如都用 26379） -
bind要监听能被其他哨兵和 Redis 节点访问到的 IP（不能只写127.0.0.1） -
protected-mode no必须设为no，否则跨机器无法通信 - 所有哨兵的
sentinel monitor mymaster 192.168.1.10 6379 2中的mymaster名称、IP 和端口必须完全一致
新哨兵启动后为什么没出现在 SENTINEL SENTINELS 结果里？
执行 SENTINEL SENTINELS mymaster 查不到新哨兵，常见原因就三个：
- 新哨兵还没连上其他哨兵：它会主动向已知哨兵发
HELLO消息，但需要时间发现并建立连接；等 30 秒左右再查 - 防火墙或安全组拦截了新哨兵的出向连接（目标端口是其他哨兵的
port，默认 26379） - 新哨兵配置里漏了
sentinel monitor—— 它必须先知道要监控谁，才会去加入哨兵集群；没有这行，它就是个孤岛
验证方式：在新哨兵进程日志里搜 +sentinel 或 new sentinel，看到类似 +sentinel slave 192.168.1.20:26379 才算成功接入。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
哨兵之间如何自动发现并形成集群？
哨兵不依赖中心注册，靠的是“被动广播 + 主动发现”机制：
- 每个哨兵定期（默认每 2 秒）向主节点的
__sentinel__:hello频道发布自己的信息（IP、port、runid） - 所有监听该频道的哨兵都会收到并解析，如果发现新成员，就尝试与其建立 TCP 连接
- 连接成功后，双方交换已知哨兵列表，逐步收敛成一致视图
所以只要新哨兵能连上主节点（sentinel monitor 配对成功）、能连上至少一个已有哨兵、且所有哨兵监控的是同一个 master-name，集群就会自动补全。不需要手动执行任何命令同步列表。
quorum 参数影响的是故障判定，不是哨兵数量
sentinel monitor mymaster 192.168.1.10 6379 2 里的 2 不是指“必须部署 2 个哨兵”，而是指：当有 ≥2 个哨兵同时认为主节点主观下线（SDOWN），才会触发客观下线（ODOWN）和后续故障转移。
- 如果只部署 1 个哨兵，
quorum设为 1 也能工作，但失去容错能力——它挂了，整个高可用就失效 - 生产环境推荐至少 3 个哨兵，
quorum设为 2：允许任意 1 个哨兵失联，仍能达成多数共识 -
quorum不能大于哨兵总数，否则永远无法触发故障转移
真正容易被忽略的是：哨兵节点之间的网络延迟和时钟漂移会影响 SDOWN 判定一致性，建议所有节点 NTP 同步。
