ntp导致的时钟回拨
ntp导致的时钟回拨
时钟回拨
我们的服务器时间校准一般是通过ntp进程去校准的。但由于校准这个动作,会导致时钟跳跃变化的现象。而这种情况里面,往往回拨最能引起我们的困扰,回拨如下所示:
会引起什么问题
准点调度任务的误判
假设有一个任务每天0点时候获取昨天所有的数据进行对账,正常情况和时钟回拨的情况如下图所示:
针对这种情况,笔者让业务调整了调度触发时间,不要精确在准点,以避免此问题。
唯一序列号(雪花算法)
时钟回拨的情况也会影响到采用雪花算法这种对时间戳要求单调的算法。很明显的,时间戳回调后,极易形成重复的序列号。
对于这种情况我们采用预留序列号段,在检测到这种情况后,将预留序列号分配出去,进而解决这一问题。
ntpd的时钟回拨(跳变)条件
事实上,ntpd本身还有另一种方案,即通过调整滴答频率来让我们的本地时钟慢慢的和精确时间match。但是,如果本机时间和精确时间(从ntpd服务器获取的时间)相差过大(> stepout threshold 128ms),则ntpd会直接采用跳跃变化的方式修正时间。代码如下所示:
ntp_loopfilter.c
double clock_max = CLOCK_MAX; // .128也就是128ms
int local_lock(...) {
// 差距>128ms之后,选择跳变
if (fabs(fp_offset) > clock_max && clock_max > 0) {
......
// 修正simclock.local_time
step_systime(fp_offset);
......
}
}
而在我们的线上,在/var/log/message中经常能见到时钟跳变的输出。
-x选项
我们采用-x选项,可以将stepout threshold(128ms)提升到600s。这样,不是太极端的情况,应该都不会触发到时钟回拨。但这会导致长时间时间戳不准确的问题(毕竟,调整滴答频率来慢慢match比较慢)。
stepback stepback
在高版本的ntpd中,还可以有stepback选项,如果设置为0的话,则不会回拨。
代码写累了,吃点碧根果吧:
评论