查看原文
其他

听过闰年闰月,可你听过闰秒吗?

艾小仙 艾小仙 2022-02-01

闰年闰月大家都知道,可是你听说过闰秒这回事情吗?

闰年是为了弥补是我们的历法365天和地球实际公转365.25天的差距,所以每4年会一年是闰年,多出来的那一天就是2月29日。

闰月则是和阴历有关,不同于阳历的以公转制定的方式,阴历以月亮绕地球的时间来计算,所以会和阳历的365.25天相差10天21小时,于是,多出来的时间累积下来凑成一个月,也就是闰月了。

那么什么是闰秒?闰秒会带来什么影响?怎么解决闰秒带来的问题?

闰秒定义

要了解闰秒,首先需要了解几个基本的概念。

平均太阳日:天空中的太阳连续两次出现最大仰角(90度)所经历的时间就是一个太阳日,而又由于太阳日的长短不同,所以取一年内的太阳日平均值,所以可以大致的认为一个平均太阳日就是一天24小时。

UTC:英文为Coordinated Universal Time,中文叫做协调世界时或者世界标准时间,相信开发的同学都很清楚,他是世界上调节时钟和时间的主要时间标准,也是最接近格林威治标准时间GMT的时间系统之一。

最早的时候,一秒根据平均太阳日的1/86400来定义,这个时间依赖于地球的自转和公转。后来直到1967年,秒被物理学重新定义,以铯133的振荡频率来定义秒,并可以用原子钟来测量。

UTC的时间就是基于此来定义,而且他是一个固定的时间长度。

但是由于地球自转的速度受到潮汐加速等众多因素的影响,平均太阳日的时间并不固定。

为了让UTC贴近平均太阳日的时间,所以就产生了闰秒。

闰秒分为两种形式:

  1. 正闰秒,也就是在23:59:59之后一秒是23:59:60,然后才是00:00:00,很奇葩很诡异是不是。
  2. 负闰秒,23:59:58的下一秒就是00:00:00,但是目前没有出现过负闰秒。

闰秒的时间调整一般是在6月30日或者12月31日,而离我们最近的一次闰秒的调整则是在2016年的12月31日。

从1972年到现在,已经发生了20多次闰秒,对于我们的系统配置来说,通过NTP的服务来进行时间同步,如果服务器收到闰秒的处理通知,则会一级级下发到最边缘的NTP服务器,然后通知到客户端的操作系统,最终由操作系统来处理闰秒。

下面的表格是历年发生闰秒的时间:

6月30日12月31日
1972年+1+1
1973年0+1
1974年0+1
1975年0+1
1976年0+1
1977年0+1
1978年0+1
1979年0+1
1981年+10
1982年+10
1983年+10
1985年+10
1987年0+1
1989年0+1
1990年0+1
1992年+10
1993年+10
1994年+10
1995年0+1
1997年+10
1998年0+1
2005年0+1
2008年0+1
2012年+10
2015年+10
2016年0+1

带来的影响

虽然闰秒对普通人的日常生活没有任何影响,但是对于开启NTP服务的Linux系统来说有致命的风险,在Linux kernel 2.6.29之前版本存在bug,在进行闰秒调整时可能会引起系统导致ntpd进程死锁,从而导致crash。另外由于应用程序不能处理闰秒的问题导致时间的变化,会导致CPU load激增。

在上一次闰秒产生,国外Reddit、Mozilla、FourSquare、Yelp、LinkedIn和Gawker都产生了一定的问题,其中Reddit宕机时间超过1个半小时。其中,或许你能很明显的看到异常错误信息:kernel[81951.244556] Clock: inserting leap second 23:59:60 UTC

另外,针对数据库方面,23:59:60时间的问题兼容也不尽相同。

PostgreSQL:PostgreSQL可以兼容23:59:60的写法,不会报错。

Mysql:Mysql还不支持60秒写法,闰秒时必须使用unix time来表示时间,否则会报错。

根据目前的信息来看,Linux内核版本高于2.6.29修复了这个问题,NTP版本高于4.2.2p1-9会把这一秒的时间分散到大约2000秒中,低于该版本的话则会直接加一秒或者减一秒。

解决方案

最简单直接的方法就是闰秒发生前停止ntpd服务,闰秒结束后再开启。

提前一天停止ntp /etc/init.d/ntpd stop
重置系统时间 date -s "`date`"
重新开启ntp ntp/etc/init.d/ntpd start

但是有一个很明显的问题就是,大公司一个服务上千台机器,操作起来成功太高,而且停止同步是否会带来其他的问题不好评估影响面。

目前像google、阿里、amazon都有一些具体的应对方案,使用云服务的话可能不需要用户关心这方面的问题,如果是自己机房托管的话那么可能需要运维开发人员手动处理了。

以国内阿里云的处理方案举例,amazon同样也是采用该方案

阿里云的ECS云服务器的NTP服务采用忽略闰秒时刻的跳秒,缓慢同步消除闰秒带来的1秒误差的方案来面对闰秒事件,实际上采用的方案是闰秒发生前,每秒比UTC慢1/86400,经过12小时(43200秒)后,会比UTC慢0.5秒,闰秒发生之后,每秒和UTC误差减少1/86400,经过12小时(43200秒)后,-0.5的误差消除。国外Amazon也是这样的解决方案。

具体时间同步方案如下表格所示:

UTC阿里云时间(北京时区阿里云时间和UTC误差备注
2016/12/31 11:59:592016/12/31 19:59:59+0和UTC完全同步
12:00:0020:00:00+0
12:00:01

每秒比UTC慢1/86400,经过12小时(43200秒)后,会比UTC慢0.5秒

20:00:01+1/86400
12:00:02



20:00:02+2/86400

23:59:59



2017/1/1 07:59:59+43199/86400
23:59:60

闰秒

2017/1/1 08:00:00-0.5秒和UTC误差-0.5秒
2017/1/1 00:00:00

每秒和UTC误差减少1/86400,经过12小时(43200秒)后,-0.5的误差消除

08:00:01-43199/86400
00:00:01



08:00:02-43198/86400


19:59:59-1/86400
11:59:59
2017/1/1 12:00:002017/1/1 20:00:000再一次和UTC同步
12:00:0120:00:010

如何预测避免

实际上,由于地球自转的时间无法计算,他有可能变快,也有可能变慢,受到潮汐、天气和熔态金属在地球核心的流动等各方面因素的影响,下一次闰秒的时间无法预估,但是国际地球自转和参考系服务(IERS)会提前6个月公布下一次闰秒的时间。

巨人的肩膀:

https://zh.wikipedia.org/wiki/%E9%97%B0%E7%A7%92

https://developer.aliyun.com/article/68260

https://yq.aliyun.com/articles/80045?spm=5176.10695662.1996646101.searchclickresult.746332ab0yvJRw

https://www.cnblogs.com/luxianghao/p/6339470.html

- END -

往期推荐



《我想进大厂》之网络篇夺命连环12问


面试官:缓存一致性问题怎么解决?


没人告诉过你更复杂的缓存穿透怎么解决


面试官:数据库自增ID用完了会怎么样?

 

点击二维码识别关注



点在看,让更多看见。


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存