文章作者：luxianghao 文章來源：http://www.cnblogs.com/luxianghao/p/6339470.html 轉載請註明，謝謝合作。 免責聲明：文章內容僅代表個人觀點，如有不當，歡迎指正。 為什麼會有閏秒？ 世界上有幾種計量時間的方式， 世界時（UT1）：是一種天文計量 ...
文章作者：luxianghao
文章來源：http://www.cnblogs.com/luxianghao/p/6339470.html 轉載請註明，謝謝合作。
免責聲明：文章內容僅代表個人觀點，如有不當，歡迎指正。
---
為什麼會有閏秒？
世界上有幾種計量時間的方式，
世界時（UT1）：是一種天文計量的方式，天文學家通過觀測地球的自轉，並將自轉一周的時間（一天）等分為864000份，每份為一秒，
受潮汐等因素的影響，地球自轉一周的時間並不是恆定的，這也是造成閏秒現象的直接原因。
原子時（TAI）：由於上面描述的世界時並不穩定，物理學家用更為穩定的量子計量的方式來統計時間，1967年，國際計量大會用銫133
（Cs133）原子基態的兩個超精細能級之間的躍遷所對應輻射的9192631770個周期所持續的時間定義為1秒，這個是目前最精確的時間
計量方式，其誤差為1400000年一秒，基本可忽略不計
協調世界時（UTC）：又稱世界標準時間或世界協調時間，UTC以TAI為基礎，又要兼顧UT1，當UTC，和UT1之間的偏差接近1秒時，
國際地球自轉和參考系服務（IERS）會提前6個月公佈下一次閏秒的時間。
閏秒是否有規律，多長時間閏秒一次？
如下圖所示，看起來並沒有什麼規律，如之前所說，影響地球自轉的因素沒什麼規律，那麼閏秒自然也沒什麼規律。
閏秒有什麼影響？
對於普通人來說，正常的上班、下班、工作、學習，生命中偏差的這一秒無關痛癢，這個倒不會像閏年，閏月那樣，影響人的生日
對於對時間要求比較精確的航空、航天、軍工等，影響就會比較大了
對於我所在的互聯網行業，伺服器清一色的linux系統，閏秒可能會造成機器cpu突然增高，機器宕機等，對應的服務就會掛掉，
因為互聯網是最近幾年才蓬勃發展起來，所以之前的閏秒對linux的影響就沒被放大，隨著linux的普遍使用，閏秒也被越來越多的被關註。
閏秒對linux以及在linux上run的應用的影響
系統列印閏秒插入信息的時候夯住：當NTP通知內核關於閏秒的動作時，這個bug會被觸發，這個bug會發生在閏秒發生的前一天的任何時候，
這個bug提前被觸發的原因是NTP時間伺服器會提前一天通知連接它的linux伺服器，將來的某個時刻會發生閏秒，linux伺服器的ntp收到這個信息
後會在閏秒時刻對linux的時間做一些處理，增加一秒，或者減去一秒
閏秒活鎖導致系統夯住：由於這個bug，NMI看門狗會檢測到系統夯住，系統會不停的crash；閏秒被插入後這個bug就會被觸發，目前還沒確定
哪個版本修複了這個bug
cpu load快速增高：其原因為應用程式不能處理閏秒帶來的系統時間的突然變化，linux系統提供兩種系統時間，wall time和montonic time，其中
wall time記錄的是事實時間，可以向前或者向後調整，montonic time記錄的是系統從啟動以來的秒數，只能向前遞增，因此如果應用程式在獲取時間
時用的wall time則會受到系統時間調整（如閏秒）的影響，而採用後者則不會受到影響，具體到jdk來說明在jdk 7u6開始採用後者。
不能處理閏秒的內核在處理閏秒發生故障時會有什麼樣的系統日誌
eg： Kernel panic - not syncing: Watchdog detected hard LOCK UP on cpu 21
閏秒後系統日誌會有什麼記錄？
eg: kernel[81951.244556] Clock: inserting leap second 23:59:60 UTC
內核bug修複情況
以上提到的bug在linux各個版本陸陸續續有修複，這裡提供一個安全的版本，內核是2.6.39-200.3或者更高版本的可以認為是安全的
ntp && 閏秒
主機使用了ntp
此時主機在閏秒時的表現將取決於使用的ntp的版本
1 版本高於等於4.2.2p1-9 或者更高版本（除了ntp-4.2.6p5-19.el7, ntp-4.2.6p5-1.el6 and ntp-4.2.6p5-2.el6_6）
a 帶-x參數運行：閏秒不是直接在內核中添加，而是把這一秒分散到大約2000秒中，1秒比之前長一些，緩慢的更改時間，
這樣做的優點：
1）避免時間倒退造成的應用邏輯問題
2）比較奇怪的時間點23:59:60不會出現
3）由於實際上沒有增加閏秒，所以上面描述的內核bug也不會出現
這樣做的缺點：
1）由於調整的時間段內，一秒的長短實際上是不准確的，所以對時間精度要求高的場景就不適用了
2）由於ntp的更新機制，這個辦法同樣也不適用於那些要求所有節點時間一致的集群
b 不帶-x參數運行，ntp會通知內核直接增加一秒(是突增的，非連續的)
2 版本低於4.2.2p1-9
ntp會通知內核直接增加一秒，或者在停止一秒
註意：如果主機上運行了ntp，那麼運行“file /etc/localtime”，確保輸出結果中有“no leap seconds”（這表明不會添加閏秒）
主機沒有使用ntp
1 沒有使用tzdata
那麼主機的時間完全由自己調整，建議使用ntp加上-x參數
2 使用了tzdata
a 版本低於2015a，不會添加閏秒
b 大於等於2015a，並且運行“file /etc/localtime”，輸出結果中有“X leap seconds”（X是個數字）
那麼閏秒會以“23:59:60”這樣的形式出現，這會導致DATE/TIMESTAMP數據類型出現問題，
你需要複製適當的/usr/share/zoneinfo文件覆蓋/etc/localtime（這個操作是動態調整的，不需要重啟）
應對閏秒的總結
1 升級內核使版本大於等於2.6.39-200.3，內核能夠處理閏秒，但是依然要提防應用程式對時間的敏感度，具體情況可參考這個，
針對這樣的應用程式，你需要
a 重構代碼
b 升級對應的軟體如jdk
2 在主機是任何版本內核的情況下，升級ntp是版本大於等於4.2.2p1-9，來應對那些對時間精度要求不高的場景
3 對於那些既不關心時間精度，也不想升級任何東西的，那就重啟ntp
a 在上級時間伺服器發閏秒通知開始之前停止ntp（需提前一天 /etc/init.d/ntpd stop），
b date -s "`date`" （重置系統時間，個人認為這樣做可能是為瞭解開閏秒造成的死鎖）
c 啟動ntp/etc/init.d/ntpd start
4 copy時間文件應對tzdata添加的閏秒
後記
以上內容是本人查看資料的總結，目前還沒有做實際的驗證，如果需要在生產環境中應用，請提前檢驗方法的合理性
