Linux有系统时间（CPU tick维持）和硬件时间（RTC晶振维持），需用chronyd渐进同步并写回RTC；禁用ntpdate跳变，云服务器应优先用systemd-timesyncd。
Linux 有两个时间，别搞混了
系统启动时，内核从硬件时钟（RTC）读一次时间设为系统时间；之后两者就各自走各自的——系统时间靠 CPU tick 累加维持，硬件时钟靠主板电池供电的晶振维持。你用 date 看到的是系统时间，用 hwclock -r 看到的是硬件时间。它们长期不同步是常态，尤其重启后没做同步的话，差几分钟很常见。
- 系统时间不准 → 影响日志时间戳、定时任务触发、Kafka 消息时间戳、ZooKeeper 会话超时（30 秒偏差就会断连）
- 硬件时间不准 → 下次开机直接继承错误时间，雪上加霜
- 所以同步完成后，记得用
hwclock -w把校准后的系统时间写回硬件时钟
ntpdate 和 ntpd/chronyd 的本质区别
ntpdate 是“一刀切”：发现当前时间比 NTP 服务器慢 5 分钟，立刻把系统时间拨快 300 秒。这会导致 cron 任务重复执行、Java 应用里 System.currentTimeMillis() 突然倒退、数据库事务时间戳乱序等真实故障。而 ntpd 或 chronyd 是“渐进式”：它通过微调内核时钟频率（tick rate），让时间在几十秒甚至几分钟内慢慢追上，不跳变、不倒流。
- RHEL/CentOS 7+ 默认用
chronyd，不是ntpd；RHEL 8+ 已移除ntp包，chrony是唯一官方支持方案 - 生产环境严禁只跑
ntpdate就完事；正确做法是先用ntpdate -u快速粗调（比如偏差 > 1 秒），再启chronyd做细调 -
chronyd对虚拟机、断网重连、网络抖动更友好，ntpd在持续在线的物理机上更稳，但新系统别纠结，直接用chronyd
/etc/chrony.conf 里最关键的三行配置
默认配置往往连不上国内可用源，得手动改。重点不是加多少 server，而是控制行为逻辑：
-
server ntp.aliyun.com iburst：用阿里云公共 NTP 源（免备案、低延迟），iburst表示首次连接时发多个包加速同步 -
makestep 1.0 3：如果系统时间偏差超过 1 秒，允许前 3 次启动时“跳变”校正（避免 chronyd 启动失败卡住） -
rtcsync：启用内核 RTC 同步，让硬件时钟每 11 分钟自动对齐一次系统时间，防止关机后 RTC 漂移
别碰 driftfile 或 hwtimestamp——前者是 chrony 自己管的偏移记录，后者需要 NIC 硬件支持，普通服务器开了反而报错。
CRMEB打通版是一款全开源支持免费商用的PHP 多语言商城系统；CRMEB技术团队历经6年时间匠心之作！系统采用前后端分离技术，基于TP6+Uni-app框架开发；客户移动端采用uni-app开发，管理后台前端使用iviewUI开发。系统支持微信公众号端、微信小程序端、H5端、PC端多端账号同步，可快速打包生成APP；赋能开发者，减少重复造轮子；系统支持自动检查安装环境一键安装部署，使用简单方便
验证同步是否真生效，别信 timedatectl status 的表面状态
timedatectl status 显示 “NTP enabled: yes” 和 “NTP synchronized: yes” 只代表服务在跑、上次同步没失败，不代表当前时间准。真正要看的是：
-
chronyc tracking：看Offset字段，单位是秒，理想值应 1s，说明没同步成功或源不可达 -
chronyc sources -v：看列出的 server 是否有*（当前主源）或+（候选源），全都是?或x就是网络不通或防火墙拦了 UDP 123 端口 -
chronyc makestep：强制立即跳变同步（仅调试用），执行后立刻再跑chronyc tracking看 offset 是否归零
最常被忽略的一点：云服务器（如阿里云、腾讯云）默认禁用 NTP 客户端，靠宿主机注入时间；如果你手动启了 chronyd，反而可能和宿主机时间打架，导致 offset 持续震荡——这种场景下，应该关掉 chronyd，改用 systemd-timesyncd（轻量级，只 client 不 server）。
