系统时钟不同步会导致哨兵误判主节点下线，因哨兵依赖本地时间戳计算响应超时；若各节点时间漂移超过down-after-milliseconds阈值，将引发主观下线判断不一致、quorum投票失效及错误故障转移。
为什么系统时钟不同步会让哨兵误判主节点下线
Redis Sentinel 的故障检测依赖时间戳比对：每个 Sentinel 会记录自己最后一次收到主节点 PING 响应的时间，再结合配置的 down-after-milliseconds 判断是否超时。如果两台 Sentinel 所在机器的系统时间相差超过这个阈值（比如设为 5000ms，但实际漂移达 8000ms），就可能出现——A 认为还没超时，B 却已判定主节点“主观下线”。当多个 Sentinel 时间不一致，quorum 投票结果就不可靠，极易触发错误的故障转移。
必须用 ntpd/chronyd 平滑同步，禁用 ntpdate
ntpdate 是一次性跳变校时，会导致系统时间突然回拨或前跳。Sentinel 内部用 gettimeofday() 或 clock_gettime(CLOCK_MONOTONIC) 做心跳计时，时间跳变会让它误认为主节点“长时间无响应”，直接触发 sdown 和后续 odown 流程。而 ntpd 或 chronyd 是渐进式微调，保持单调性，不会干扰 Sentinel 的状态机。
- 确认运行的是
ntpd或chronyd（不是systemd-timesyncd，它不满足 Redis 对精度和稳定性的要求） - 检查进程：运行
ps aux | grep -E "(ntpd|chronyd)"，确保只有一个在跑 - 禁止任何定时任务调用
ntpdate或hwclock --systohc
内网部署专用 NTP Server，别直连公网
所有 Sentinel 节点（以及它们监控的 Redis 主从节点）必须同步到同一个内网 NTP 源。如果各自去同步 ntp.aliyun.com 或 pool.ntp.org，公网网络抖动、DNS 解析延迟、服务限流都会导致各节点间 offset 不一致——哪怕只有 ±15ms 差异，在 down-after-milliseconds 5000 场景下也足够埋雷。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 选一台稳定的管理节点或哨兵节点作为 NTP Server，
/etc/ntp.conf加入：server 127.127.1.0 fudge 127.127.1.0 stratum 10 - 配
restrict规则，只允许集群网段访问，例如：restrict 192.168.10.0 mask 255.255.255.0 nomodify notrap - 客户端节点只保留一行：
server 192.168.10.100 iburst（填你 Server 的真实 IP）
验证同步状态不能只看 date，要看 ntpq 输出和 Redis 日志
date 显示相同不代表时间在协议层真正对齐。Sentinel 的判断依据是内核时钟偏移，必须查 ntpq 的实时反馈：
- 运行
ntpq -p：输出中带*的那行是当前同步源，offset值应持续稳定在 ±5ms 内（生产环境建议压到 ±2ms） - 运行
ntpq -c rv：重点看offset=、sys_jitter=（低于 5ms 为健康）、leap=00（表示无闰秒告警） - 翻 Redis/Sentinel 日志：搜索
failover前后是否有Timeout、no reply、master is down等关键词；若某节点频繁出现Connection refused或 Gossip ping 延迟突增至几百毫秒，先盯它的ntpq -poffset
真正难防的不是配不配得上，而是配完没人定期看 ntpq -p。集群跑两周后，某台哨兵节点 offset 悄悄飘到 ±40ms，下次网络抖动时，它就会成为那个“投出关键一票却基于错误时间”的节点。
