目前项目的服务器是多台，有次有台服务器反馈token经常超时，核对了下时间，慢了一分钟，其他服务器都是正常的。
感觉很神奇，分析了下发现了问题。

查看时间：
date

然后命令：
timedatectl
发现时间慢的服务器 NTP synchronized 状态是no。
      Local time: Wed 2024-02-07 13:45:57 CST
  Universal time: Wed 2024-02-07 05:45:57 UTC
        RTC time: Wed 2024-02-07 05:45:58
       Time zone: n/a (CST, +0800)
     NTP enabled: yes
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

于是运行命令：
systemctl start chronyd
运行完之后，date查看时间终于正常了，NTP synchronized 状态也变成yes了。

操作完之后，把别的项目也检查了下。
别的项目运行timedatectl，直接没这个命令，于是运行 yum install chrony。
报错，提示ntpd已经存在。
好吧，那就启动ntp吧：service ntpd start。
至此，都已设置linux时间都已设置同步。

NTP是网络时间协议(Network Time Protocol)，它是用来同步网络中各个计算机的时间的协议。
它的用途是把计算机的时钟同步到世界协调时UTC，其精度在局域网内可达0.1ms，在互联网上绝大多数的地方其精度可以达到1-50ms。

以RedHat的Linux发行版为例,早期用来解决时间服务器(CentOS 6.x版本之前)的程序包是ntpd，该程序包既可以用作服务端又可以用作客户端。ntpd是基于NTP(Network Time Protocal)实现时间同步的。

ntdp的实现同步时间的逻辑：
它的思想是把时间的周期缩短，举个例一个比较极限的例子，假设一台服务器两台服务器时间相差1小时，它的思想就是将自己现有的时间周期缩短，从而间接追上时间服务器的时间。比如时间服务器跑一分钟需要60秒，而ntpd的思想是跑一分钟使用30秒甚至1秒实现跑一分钟的的时间周期，这样随着时间的推移一定会追上服务器时间的。这种方式的确是可以追到服务器时间，但是为了追到服务器时间会付出一定时间的代价，这也是ntpd之所以被淘汰的根本原因。

生产环境中,你是否也发现了这样的现象呢？明明在部署集群时时间配置是正确的，可能过了2三个月后，你会发现集群中总有那么几台及其出现时间不同步的情况。这里的根本问题在于ntpd在和时间服务器进行时间同步的核心逻辑问题，因此CentOS7.x版本将CentOS6.x版本的ntpd替换为chronyd服务啦。

chrony是网络时间协议（NTP）的通用实现。它可以将系统时钟与NTP服务器、参考时钟（例如GPS接收器）和使用手表和键盘的手动输入同步。它还可以作为NTPv4（RFC 5905）服务器和对等服务器运行，为网络中的其他计算机提供时间服务。

它被设计成在各种条件下都能很好地运行，包括断续的网络连接、严重拥挤的网络、不断变化的温度（普通的计算机时钟对温度很敏感），以及不连续运行或在虚拟机上运行的系统。

chrony是ntpd的替代方案。在互联网上同步的两台机器之间的典型精度在几毫秒内；在局域网上，精度通常在几十微秒内。使用硬件时间戳或硬件参考时钟，可以达到亚微秒精度。

chrony中包含两个程序，chronyd是一个可以在启动时启动的守护程序，chronyc是一个命令行接口程序，可用于监视chronyd的性能，并在运行时更改各种操作参数。

如果非要把NTP和chrony做一个对比的话，我们就以手动调整手表时间为例，我们假设手表时间和实际服务器时间相差3小时:
ntpd的解决思路就是飞速的转动秒针，以最快的速度调准时间，可想而是，我们需要非常快的速度转动180圈秒针才能追上时间服务器的时间,真个转动过程是相当费时间的。
chrony的解决思路就是直接调整时针,可想而知，我们挑拨时针不到一圈就能把问题解决掉了，这就是为什么生产环境中大家使用的时间服务器基本上都是chrony啦。