752
神不知鬼不覺，阿裏程序員把地球多出的1秒“變沒”了
在談到“閏秒”的時候，大部分人可能會有點陌生，也許大家都知道有“閏年”，“閏月”一說，但是可能還真沒有想到還有“閏秒”這一說。事實上，這幾年，隨著科技的發展，尤其IT和金融業的突起，在計算精細的領域，對一秒也不容忽視，所以“閏秒”這個概念也被越來越多的人知道。對於阿裏巴巴這麼一個大體量的互聯網公司，麵對的挑戰總是巨大的。下麵我們來講講阿裏巴巴是如何應對閏秒的。
為了讓大家對“秒”有更深的理解，我們來回顧一下“秒”的曆史，究竟是怎麼過來的？“秒”究竟是如何定義的？
- 1956年，秒定義為平均太陽日的1/86400
- 1960至1967年之間，定義為1960 年地球自轉一周時間的1/86400
- 1967年，國際計量大會決定，以銫原子基態的兩個超精細能級間在零磁場下躍遷輻射 9,192,631,770 周期所持續的時間。
- 1977年，人類認識到了引力時間膨脹會導致在不同高度的原子鍾時間不同，重新定義為”水平麵的銫 原子”基態的兩個超精細能級間在零磁場下躍遷輻射 9,192,631,770 周期所持續的時間。
- 2019年，國際時間頻率谘詢委員會將討論“秒”的重新定義問題。 隨著人類認知的進步，對秒的定義逐漸發生了變化，從1967年開始，時間的計量標準便正式由天文學的宏觀領域過渡到了物理學的微觀領域。
隨著科技的發展，科學家對“秒”的定義其實也在發生變化。
在這個地球上，每個地區，國家的人都有自己本地的時間。由於曆史的原因，和近代國際組織對時間的統一，使得現在有多種對時間的定義方法。
UT(世界時)
UT(Universal Time，世界時)是一種以格林尼治子夜起算的平太陽時，由於以地球自轉為基準，觀測精度受限於地球的自轉速度的穩定，地球體積不均勻、潮汐引力以及其他星球的擾動的原因，導致地球轉速不穩定，每日誤差達數毫秒。
TAI(國際原子時)
TAI(international atomic time)為國際原子時，1971年建立，利用某些元素(如銫、氫、銣)的原子能級躍遷頻率有極高穩定性的特性定義時間標準，現為國際計量局(BIPM)的時間部門維持，綜合全球約60個實驗室中的大約240台各種自由運轉的原子鍾提供的數據進行處理，得出“國際時間標準”稱為國際原子時 (TAI)，每日誤差為數納秒。
TAI時間原點為UT 1958 年1月1日 00:00:00 ，在此之後TAI就沿著原子秒的節拍一直走下去，和UT誤差也越來越大。
UTC(協調世界時)
上麵已經說過，科學上有兩種時間計量係統:基於天文測量而得出的“世界時”和以物理學發展發現的原子振蕩周期固定這一特性而來的“原子時”，UTC就是用於將世界時(UT，天文時間)和國際原子時(TAI，原子時間)協調起來的另外一套計量係統， 1971年國際計量大會通過決議，使用UTC(協調世界時)來計量時間， 協調的原則就是UTC以原子秒長節拍，在時刻上盡量接近於世界時(UT)。
目前UTC是事實上的時間標準，比如所有計算機中的時間就是UTC時間(通過時區換算為本地時間)， 而閏秒，實際上就是UTC特有的。
地球自轉被稱為“世界時間”。不過，由於潮汐、地殼運動、冰川融化、地震等自然現象，地球的自轉速度並非恒定，而是有時快，有時慢。
1967 年原子鍾的出現意味著人類計時不用再依賴於地球的自轉，時間的計量標準正式由天文學的宏觀領域過渡到物理學的微觀領域，也就是所謂的“原子時間”。
細心的科學家發現，兩者之間存在微妙差異。於是，國際地球自轉和參考係服務會（IERS）在差異超過 0.9秒時，會協調“世界時間”加上或減去 1 秒，消除這個誤差。
這多出來的1秒，就是閏秒。
閏秒究竟是多一秒，還是少一秒，也是有依據的，國際地球自轉和參考係服務會（IERS）基於實際觀測，地球自轉和參考係服務會提前六個月公布下一次閏秒的時間。
通常在該年度的 6 月 30 日或 12 月 31 日午夜進行。
由於北京時間與格林尼治時間相差8小時，中國是在2017年1月1日迎來7時59分60秒的特殊現象。
最近四次閏秒分別發生在 2005 年 12 月 31 日、2008 年 12 月 31 日和 2012 年 6 月 30 日，2015年7月1日。
從 1988 年這一做法被確立至今，一共發生過 26 次閏秒。2017 年 1 月 1 日這次是第 27 次閏秒。
本次閏秒公告在 國家授時中心閏秒公告和IERS關於閏秒公告中有權威的發布。
由於我們在正八區，所以，閏秒時刻我們是在早上八點，所以這次閏秒實際是這樣子的：
沒錯，我們的生活多了整整1秒哦～
北京時間2017年1月1日7時59分59秒後，全球同步多出1秒這事兒，對日常生活影響不大。但是對於IT，金融，航天行業，若處理不當，也可能引發危機。比如說，2012年閏秒發生時，包括LinkedIn在內不少國外知名網站都曾遇到故障。
因為“閏秒”不是一個規律的東西，而是那些科學家發現，“哎呀，今年地球轉的有點快，我們年底要加個閏秒吧”，於是，“閏秒”就產生了。但是，程序員在寫代碼的時候，卻沒有考慮到會有閏秒，除了程序員寫的代碼，其實還有大量的操作係統處理不了閏秒也會有影響，會導致各種異常。
最常見的情況是，如果服務器操作係統是Linux，在一些老的內核版本中存在BUG無法處理閏秒，導致收到閏秒通告消息可能會宕機、插入閏秒可能會宕機、打印閏秒日誌也能引發宕機。就說說紅帽的老發行版，出現的“Systems hang due to leap-second livelock.,High CPU usage after inserting leap second”。
鏈接：https://access.redhat.com/solutions/154793
即便不宕機，在應用層，應用程序也可能無法處理這多出來的1s導致應用core掉。甚至可能影響到那些對時間敏感、事務性較強的應用，比如DB。
目前，國際大公司通用的解決方案是將這一秒分成許多份，再平均分配到一整天中。
日本有一家股票交易所將這一秒平均分成 7200 份，分攤到兩個小時裏，在分攤結束時間恢複同步時，剛好趕上開市。
Google則是在閏秒時刻前的24小時開始逐步調慢時間，理論上在閏秒時刻前，和標準UTC時間最大誤差趨近於1秒。
這次我們依然采用的方案是“將1秒拆分成86400份”應對本次閏秒，緩慢同步消除閏秒帶來的 1 秒誤差這一基本方案。
在NTP中存在兩種時間同步機製：一種是“slew”，一種是“step”，雖然“slew”的方式也是緩慢的調整，但是麵對阿裏巴巴複雜的業務，這種方式並不能滿足和解決這個問題，我們在5k集群下測試和驗證，探索出一個更佳優秀的方案，就是將1s拆分成86400份。這個方案相比之間的“slew”的方案有如下改進：
- 同步速率由 0.5ms/s 調整為 0.011574ms/s
- 同步窗口由之前的 2000 秒調整為 86400 秒（24 小時）
- 同步起止時刻由之前的閏秒時刻後，調整為閏秒時刻前 12 小時開始，閏秒時刻後 12 小時終止
- 整個同步窗口和標準 UTC 時間的最大誤差由之前的 1 秒減小到 0.5 秒（500 毫秒）
在閏秒發生前2個月，我們對閏秒過度方案進行了多次測試，並且在超大規模的集群中測試，結合過去經驗，根據我們的方案如果把在client的每分鍾采集的時間和標準時間產生的offset數據匯總成圖，可以看到時間的變化是極其緩慢和微小的。
橫坐標: 時間，單位:分鍾，24小時一共有1440分鍾
縱坐標: offset, 單位:ms
對於阿裏巴巴如此大體量的互聯網公司，遇到的挑戰總是更大的，在方案實施過程中我們也有發現了若幹問題，在內部時間源時間聚合期間，個體時間服務器的時間變化收到本身硬件，以及網絡，溫度等，各種外部因素的影響。這些因素產生的影響也是要引起注意的。
最後更新：2017-06-20 15:01:51