用redis-cli -p 26379 SENTINEL master mymaster可查主节点当前IP和端口；flags含master且num-slaves≥1为基本健康信号，需结合INFO replication比对偏移量确认数据一致性。
用 redis-cli 连接哨兵并检查主节点状态
哨兵本身不提供 HTTP 接口，必须通过 Redis 协议连接其监听端口（默认 26379），用 SENTINEL 命令获取拓扑信息。直接连错端口（比如连了主库的 6379）是常见失败原因。
- 确认哨兵进程在运行：
ps aux | grep redis-sentinel，并核对配置中port和bind设置 - 用
redis-cli -p 26379 -h 127.0.0.1 SENTINEL master mymaster查主节点当前 IP 和端口；若报错(error) ERR Unknown sentinel command，说明连的是普通 Redis 实例而非哨兵 - 返回结果中
flags字段含master且num-slaves≥ 1 是基本健康信号；若num-down-sentinels或num-other-sentinels异常偏低，说明哨兵集群通信有问题
判断是否发生主从切换的可靠依据
仅看 SENTINEL masters 输出不够——它总是返回当前主节点，但无法区分是“稳定运行”还是“刚切完还没同步完”。真正要盯的是切换事件本身和后续状态收敛。
- 监听哨兵日志比轮询更及时：
tail -f /var/log/redis/sentinel.log | grep "switch-master"，该行出现即表示切换已触发 - 切换后需验证：新主节点的
role必须为master（用redis-cli -p <new_port> ROLE</new_port>确认），且所有从节点master_link_status为up - 避免误报：如果
SENTINEL slaves mymaster返回的从节点里有flags含s_down或o_down，即使主节点正常，也意味着故障未完全恢复
用 Shell 脚本触发企业微信/钉钉报警
报警逻辑必须带去重和冷却，否则一次网络抖动可能触发几十条消息。脚本不应每次检测都发告警，而应记录上次告警时间戳并比对。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 用
date -d "@$(cat /tmp/redis_sentinel_last_alert 2>/dev/null)" +%s 2>/dev/null || echo 0读取上一次告警时间 - 冷却期设为 300 秒（5 分钟）：当前时间减去上次时间 > 300 才允许发送，并在成功后更新
/tmp/redis_sentinel_last_alert - 调用钉钉机器人示例：
curl -X POST https://oapi.dingtalk.com/robot/send?access_token=xxx -H 'Content-Type: application/json' -d '{"msgtype": "text", "text": {"content": "Redis 哨兵检测到主节点切换：old=10.0.1.100:6379, new=10.0.1.101:6379"}}' - 注意：
curl超时必须设短（如--connect-timeout 5 --max-time 10），否则脚本卡住影响下一轮检测
定时任务里漏掉的关键细节
cron 默认环境变量极简，PATH 不包含 /usr/local/bin，导致找不到 redis-cli 或 curl；同时脚本内路径写相对路径会失败。
- 在 crontab 中显式声明环境：
PATH=/usr/local/bin:/usr/bin:/bin SHELL=/bin/bash */2 * * * * /opt/scripts/check_sentinel.sh >> /var/log/redis_sentinel_check.log 2>&1 - 脚本开头加
cd $(dirname "$0")或直接用绝对路径引用配置文件，比如/etc/redis/sentinel.conf - 不要依赖
whoami判断用户——cron 以指定用户身份运行，但脚本内执行命令时权限可能受限；测试时用sudo -u redis /opt/scripts/check_sentinel.sh模拟真实场景
哨兵状态检查最易被忽略的不是命令怎么写，而是“什么算真正恢复”——比如主节点 IP 变了，但从节点复制偏移量没追平，此时应用仍可能读到旧数据。得结合 INFO replication 里的 master_repl_offset 和各从节点的 slave_repl_offset 对比才稳妥。
