閏年閏月大家都知道，可是你聽說過閏秒這回事情嗎？

閏年是為了彌補是我們的歷法365天和地球實際公轉365.25天的差距，所以每4年會一年是閏年，多出來的那一天就是2月29日。

閏月則是和陰歷有關，不同于陽歷的以公轉制定的方式，陰歷以月亮繞地球的時間來計算，所以會和陽歷的365.25天相差10天21小時，于是，多出來的時間累積下來湊成一個月，也就是閏月了。

那么什么是閏秒？閏秒會帶來什么影響？怎么解決閏秒帶來的問題？

閏秒定義

要了解閏秒，首先需要了解幾個基本的概念。

平均太陽日：天空中的太陽連續兩次出現最大仰角(90度)所經歷的時間就是一個太陽日，而又由于太陽日的長短不同，所以取一年內的太陽日平均值，所以可以大致的認為一個平均太陽日就是一天24小時。

UTC：英文為Coordinated Universal Time，中文叫做協調世界時或者世界標準時間，相信開發的同學都很清楚，他是世界上調節時鐘和時間的主要時間標準，也是最接近格林威治標準時間GMT的時間系統之一。

最早的時候，一秒根據平均太陽日的1/86400來定義，這個時間依賴于地球的自轉和公轉。后來直到1967年，秒被物理學重新定義，以銫133的振蕩頻率來定義秒，并可以用原子鐘來測量。

UTC的時間就是基于此來定義，而且他是一個固定的時間長度。

但是由于地球自轉的速度受到潮汐加速等眾多因素的影響，平均太陽日的時間并不固定。

為了讓UTC貼近平均太陽日的時間，所以就產生了閏秒。

閏秒分為兩種形式：

正閏秒，也就是在23:59:59之后一秒是23:59:60，然后才是00:00:00，很奇葩很詭異是不是。

負閏秒，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年	+1	0
1982年	+1	0
1983年	+1	0
1985年	+1	0
1987年	0	+1
1989年	0	+1
1990年	0	+1
1992年	+1	0
1993年	+1	0
1994年	+1	0
1995年	0	+1
1997年	+1	0
1998年	0	+1
2005年	0	+1
2008年	0	+1
2012年	+1	0
2015年	+1	0
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

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

巨人的肩膀：

?

實際上，由于地球自轉的時間無法計算，他有可能變快，也有可能變慢，受到潮汐、天氣和熔態金屬在地球核心的流動等各方面因素的影響，下一次閏秒的時間無法預估，但是國際地球自轉和參考系服務（IERS）會提前6個月公布下一次閏秒的時間。

如何預測避免

?

UTC阿里云時間（北京時區阿里云時間和UTC誤差備注

2016/12/31 11:59:59	2016/12/31 19:59:59	+0	和UTC完全同步
12:00:00	20: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:00	2017/1/1 20:00:00	0	再一次和UTC同步
12:00:01	20:00:01	0	?
…	…	…	?

具體時間同步方案如下表格所示：

阿里云的ECS云服務器的NTP服務采用忽略閏秒時刻的跳秒，緩慢同步消除閏秒帶來的1秒誤差的方案來面對閏秒事件，實際上采用的方案是閏秒發生前，每秒比UTC慢1/86400，經過12小時（43200秒）后，會比UTC慢0.5秒，閏秒發生之后，每秒和UTC誤差減少1/86400，經過12小時（43200秒）后，-0.5的誤差消除。國外Amazon也是這樣的解決方案。

以國內阿里云的處理方案舉例，amazon同樣也是采用該方案

目前像google、阿里、amazon都有一些具體的應對方案，使用云服務的話可能不需要用戶關心這方面的問題，如果是自己機房托管的話那么可能需要運維開發人員手動處理了。

但是有一個很明顯的問題就是，大公司一個服務上千臺機器，操作起來成功太高，而且停止同步是否會帶來其他的問題不好評估影響面。

總結

以上是生活随笔為你收集整理的听过闰年闰月，听过闰秒吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。