背景

BIGO的服務器分布在全球各地,各種服務如分布式追蹤等都對全球機器存在時鐘對齊的需求。而客觀上,受限于服務器本身的時間源設備精度以及內核時鐘系統的軟件設計實現等多種復雜因素制約,常見的服務器秒級別的設備時鐘誤差大約在萬分之二左右,而累積誤差會出現正反向補償,根據經驗觀測值,一年存在至少分鐘級別的時鐘誤差。

此類問題最常見的解決手段就是接入網絡授時服務如NTP,但是作為一個全球分布幾萬+服務器的公司,簡單接入NTP服務,并不能徹底解決全球時鐘對齊的問題。

BIGO的服務器很早期就接入了time.nist.gov的NTP網絡時間同步服務,但是觀測到公司內部的機器普遍存在百毫秒級別的時鐘誤差,單機視圖存在時間跳變等問題,而且誤差分布幾乎是隨機的,同機房內部都可能出現極大誤差。

基于以上現狀,結合BIGO的業務需求,我們的全球時鐘true time服務開啟調研和建設。在業界相關領域,google的spanner論文有提到true time服務的建設,facebook也有公開過chrony時鐘對齊服務解決方案。前者核心是依賴全球多機房部署原子鐘+GPS構建了一個雙層的架構,配合Marzullo變種算法來提供7ms時間區間服務。而后者本質上也是基于原子鐘+GPS構建了一個最高可以達到16層的架構來提供true time服務。

業界的現有技術方案,一方面存在硬件設備依賴,另一方面直接作為開箱即用的時間源在BIGO實際場景會制約我們的服務部署情況。于是我們基于外部NTP網絡時間源+內部UTC時間源集群+多PTP集群的方案來構建了BIGO自己的全球true time時鐘對齊服務,目標是在不依賴內部原子鐘的前提下,把BIGO全球機器99.99%場景時鐘誤差控制在亞毫秒。

該基礎能力的建設,可以應用于BIGO內部不少場景:

1) 解決分布式追蹤場景的時間誤差問題;

2) 可以賦能BIGO的音視頻優化直播幀時間戳跳變引起的卡頓問題,以及音視頻和文件傳輸在重傳準確率,擁塞控制等方向的提升;

3) 解決時間跳變問題,提升BIGO基礎框架等服務的穩定性,避免跳變引起的服務卡頓和掛死。

NTP

在了解時鐘對齊相關原理時,NTP協議(Network Time Protocal)和相應的ntpd和ntpdate服務是必須要了解的。這里我們簡單回顧一下相關原理。

NTP協議的提出是為了解決這樣一個問題:已知有一個基準服務器A,A的時間是準確的,怎么通過網絡讓B本地時鐘跟A對齊?

聰明的讀者可能已經很快想到答案,B發包詢問A,A把本地時間回給B就搞定了。但是問題沒有這么簡單,B->A的網絡包延時d1,A->B的網絡包延時d2,甚至A收到請求再回包過程的耗時d3都會導致B拿到的時間存在誤差。

針對此問題David L. Mills提出了NTP協議,最早出現在rfc958。

圖1是單次NTP授時過程,首先B向A發送一個NTP包,包里包含了離開B的本地時間戳T1。A收到NTP請求包之后,依次記錄包到達的本地時間戳T2,回包離開的時間戳T3,然后立即把包返回給B。B收到回包后,記錄本地時間戳T4。

其中我們把d1=T2-T1定義為上行延時,d2=T4-T3定義為下行延時。假設A-B的時鐘絕對誤差為diff,則有如下公式:

d=d1+d2

T2=T1+diff+d1

T4=T3-diff+d2

如上推算,A-B的時鐘誤差公式求解如下:

假設網絡的上下行延時對等無波動,即d1=d2,則A-B的時鐘誤差近似值diff_appro跟diff相等,diff_appro的表達公式如下:

在單次的ntp對齊過程中,工程上往往基于diff_appro公式去計算A-B的時鐘差,此時并未剔除上下行網絡波動的影響,我們把diff稱為A,B機對齊前時鐘誤差(簡稱前誤差),把diff_appro-diff稱為A,B機對齊后的時鐘誤差(簡稱后誤差)。

后誤差的公式表達為diff_appro-diff=(d1-d2)/2,當d1或者d2等于d時,后誤差最大為±d/2。

NTP算法簡單來說,就是基于diff_appro公式計算diff值,并對B機的時鐘做出加diff_appro的調整,從而讓B機的時鐘向A機盡量對齊。對齊過程還會存在后誤差(diff_appro-diff),后誤差最大可以到±d/2。

看到這里,可能聰明的讀者要發出靈魂拷問了,A直接回時間給B,B完全不考慮任何誤差直接使用A返回的時間設置為本機時間,這個過程存在的誤差也就是d2而已,最大誤差可以換算為d。這NTP繞了這么一圈,僅僅是把后誤差縮小到到d/2而已,反正是不準,優化一半的精度似乎沒什么價值。

其實本質不是這樣的,僅僅關注最大誤差確實只優化了一半的精度。但是直接使用A返回的時間,A和B的時鐘誤差是恒等于d2的,而NTP的時鐘誤差本質上是跟上行延時和下行延時的差值成正比,網絡延時是永恒存在的,而上下行延時差值(簡述為網絡波動)卻不一定是永恒存在的,只要配合一些多次采樣平滑調整,是可以基于NTP把時鐘對齊的精度控制在比較理想的范圍的。

ntpd和ntpdate就是2種基于ntp協議封裝的時鐘對齊服務方式,前者利用了多時鐘源以及一些平滑算法來規避對齊過程中的時鐘跳變問題。而后者僅僅是對ntp協議過程的定期應用,容易存在誤差和跳變。

架構權衡與設計

前面提到BIGO一開始全球機器都基于ntpdate接入了time.nist.gov,但是效果顯而易見是不好的,普遍存在百毫秒誤差,時鐘跳變,誤差無視機房,每個問題都很致命。

那么簡單換成ntpd會不會變好,我們的實踐表明ntpd本機房同步誤差可以控制在毫秒級別,但是跨大區同步存在10毫秒級別的誤差,雖然對比ntpdate會有改善,但是這個效果還不夠滿足業務需求。或者我們的服務器可以物理距離跟ntp源保持靠近部署,但這不是一個好擴展的服務架構,也不符合我們全球多機房的運維現狀。

我們后續還嘗試引入facebook的chrony(facebook提供的一種NTP時間源)作為時間源,其對比ntpd有更優秀的同步算法,但是我們驗證跨大區同步的誤差依然在6毫秒級別,主要原因在于公網跨大區上下行delay差異導致。此外chrony對第三方使用者的調優成本較高,其提供了如mindelay等十幾種同步模式,缺乏最佳實踐指引。

簡單總結一些權衡,如果要開箱即用一些ntp源服務,則BIGO的服務器部署會受到限制,如部署地點,同步頻率等。因此我們在這一期放棄了全網直接使用相關ntp服務,而是開始在BIGO內部分層構建true time服務。

架構上,我們要在沒有內部原子鐘設備的前提下,解決2個問題。

1. BIGO的機器時間要和UTC時間保持較高精度的同步;

2. BIGO各個內部機器之間的時間要盡量保持較高精度同步,且ping延時越小的機器之間精度要求越高。

問題1即時間源的問題,google spanner里的true time的處理方式是依賴硬件設備,引入原子鐘+GPS組成分布全球的master群,利用原子鐘和GPS故障概率和故障原因存在差異這個特性做雙保險保障master可用性。同時master和daemon(即slave)都會通過一些算法識別明顯異常的時鐘,從而在內部建設了一套全球高可用的高精度時間源。

而BIGO在面對這個問題時,尚沒有大規模的原子鐘設備,為了低成本的解決時間源問題,最終我們選擇了建設一個單機房的時間源,我們稱為super master。super master為了保證可用性,應該是集群。Super master的時間并不是來自自身的時鐘,而是基于ntpd跟一個物理距離上最接近的NTP源做時鐘對齊。

至此,我們在沒有原子鐘的情況下,得到了一個可用性對比google spanner里的 true time稍差一點的時間源。

問題2,我們希望按機房分層建設架構。最終確定在每個機房建設一些master節點,本機房的其他節點(我們稱為slave)只會跟這些master做時鐘同步,基于PTP協議來進行。看到這里可能讀者會疑惑,PTP是個什么協議,這里不急,后面會有篇幅對該協議做一個回顧,你可以先簡單理解PTP是在NTP上做的一種工程優化,其比較適合子網內的高精度時鐘同步(在毫秒內精度進一步提升),支持廣播,單播等工作模式。

最終,我們得到BIGO true time服務一期架構圖如下:

架構里的相關名詞解釋如下:

NTP源——基于ntpd或者ntpdate形式提供時鐘對齊服務的標準機構(例如time.nist.gov是由美國國家標準技術研究所提供),NTP源的時間同步報文里包含的時間是UTC時間(等效于GMT格林威治時間)。

Super Master——角色定位為BIGO內部的可靠UTC時間源,前面說了,super master是沒有原子鐘的,基于ntpd跟物理最近的NTP源做UTC時鐘同步。Super master一期暫時是單機房的,后面為了更高的可用性,會規劃多機房的分布式UTC源架構。

Name Service——BIGO內部的分布式名字服務,具體架構不細講了,可以對標Etcd等架構,這里該模塊主要用于給master發現super master做ptp單播時鐘同步用。

Master——某個機房內的時鐘源,僅僅服務本機房的節點。一個機房內可以有多個master存在。Master會定期基于PTP單播配合我們的平滑算法去super master做時鐘同步,同時,也會秒級對子網內做ptp的sync廣播達成master和slave的時鐘同步。

關于master的選舉決策,這里涉及到PTP里的BMC算法,原則上一個機房不需要唯一的master,該算法不同于其他分布式強一致算法如paxos,不需要達成全局唯一共識。關于BMC選舉master機制我們后面會展開講解。

Slave——機房里的普通服務器,會周期秒級收到同機房master的PTP sync同步廣播,達成時鐘同步,當前由于只會在同機房做時鐘同步,該過程暫未做平滑處理。

機房內Master選舉

提起Master選舉,可能很多讀者會想到Raft,Paxos等相關技術方案。而在我們這個具體的問題領域,關于在一堆機器里選出合適的主機作為master來成為時鐘源,比較經典的是IEEE1588里的BMC(Best Master Clock)算法。

該算法比較適合子網內部Master選舉的特點,只負責選出確定的Master群,并動態保障slave一定可以較快找到可用的Master,但是不考慮slave使用的master是否是最優解,BIGO內部為該算法設計了保底策略,用于規避極端情況長期使用較差的master。

BMC算法本身為每臺機器設置了幾個屬性:

1)機器優先級:根據機器屬性賦予機器的一個優先級,值越小優先級越高;

2)分組優先級:對機器進行分組,每個組有一個優先級值越小優先級越高;

3)唯一標識:進程的唯一標識,一般使用MAC地址。

BIGO這邊由于子網天然是同機房的,所以1和2默認都是不配置的,基于保底策略來動態解決機器網絡狀況波動問題。

原始的BMC算法選主流程如下:

1) 進程接收子網內的master的廣播信息,并加入自身的foreignMaster列表;

2)進程根據foreignMaster列表信息(可能為空)和本進程信息通過BMC算法按機器屬性選擇出最優的master;

3)如果進程成為master的話,則開始廣播信息。

圖3是選主過程的狀態遷移圖,子網內任何一臺機器都會周期的check自身的foreignMaster列表,選出當前的自己的master(可以是自己),然后相應把自身角色設置為master(slave)。

該算法集群多機狀態收斂過程還是比較清晰簡單的。

1) 初始的時候,不考慮引入任何隨機退讓算法,子網內所有機器都沒有收到任何master的announce請求,則會將自己提升為master,并開始廣播自己的信息。此時,子網內全部機器都是master;

2) 子網內的機器開始陸續收到子網內master的信息,在這過程中,不斷執行bmc算法,進而將更優的進程設置為master,最后一般在幾個廣播周期內,整個集群的master,slvae狀態達到穩定。

下面的圖4簡要的展示了BMC算法從初始化到收斂過程:

總結來看,BMC算法優點就是快速,簡潔,而由于選主條件是靜態的(如MAC地址大小),無法保證選出的master是網絡情況最優的,這種算法在子網內比較合適。

為了保證該算法在網絡變化后可以剔除掉明顯異常的Master點,BIGO嘗試引入網絡波動保底策略。即在保持BMC算法主流程情況下,引入master->slave的網絡波動情況來優化master選擇策略。

為什么基于網絡波動來做選主決策,而不考慮網絡延時大小,根據我們前面描述的NTP原理,讀者應該清楚,時鐘同步的誤差受上下行網絡差值影響較大,而延時的絕對大小是沒有影響的。

BIGO這邊會基于PTP的delay過程(后面一節PTP協議會詳細講解),在本機維護slave跟他foreignMaster列表的機器的歷史delay值集合——foreignMaster’s delay_list。然后基于標準方差公式計算每臺master的delay方差S(關于方差的概念,本文不再贅述)。我們認為方差S可以較好的表達foreignMaster的網絡波動。

在原BMC選主過程,BIGO會額外判斷目標master的方差S是否超出了閾值,如果是則會把該Master機器從slave的foreignMaster列表里暫時踢掉,當S恢復小于閾值后,會再加回foreignMaster列表,全過程對BMC選主機制沒有任何收斂性相關的破壞。

最后說一下,為什么BIGO不嘗試改變BMC選主順序條件,比如按照master的S大小來優先選主。主要基于2點考慮:

1. 子網內機器間的網絡狀況一般都是平等,我們沒有強烈的需求需要選出最優的master,我們需要做的是規避毛刺和異常節點;

2. 改變BMC選主順序,引入動態變量S來調整Master優先級,意味著每臺slave機的Master優先級視圖可以不一樣,BMC簡潔的Master收斂過程被破壞,我們需要很小心的去review整個算法的全過程,避免出現極端的Bug,而如1所述,這項工作的收益并不大。

PTP

單機房內部,master和slave之間通過PTP協議來完成時鐘同步。這里簡單回顧一下PTP協議,以及BIGO內部使用情況。

首先,NTP的原理讀者應該已經清楚了,那么我們可以認為PTP是嘗試對NTP做工程落地的一種優化實現方式。PTP全稱為Precision Timing Protocol,也是在IEEE1588里提出的。PTP主要解決了2個工程上的問題:

1.解決NTP里面精準獲取d1,d2的問題;

2.怎么高效的在一個子網內對多個slave同步時鐘的問題。

先講下問題1,精準獲取d1,d2是什么意思呢?

首先,PTP是基于UDP協議來通信的,我們把d1,d2定義為網絡延時,但是在工程實現上,假如B給A發包,A給B回包,A發回包前獲取本機時間T3‘的話,那么T3’=T3-UC。其中T3是網絡包從內核發出去的時間,UC是A獲取本機時間到回包從內核發出去的時間差,為什么會有UC存在,因為linux并不是一個實時操作系統。UC的耗時組成會很復雜,cpu調度的繁忙程度,緩沖到發送的耗時都會影響UC,且會動態變化。而真正的延時d2=T4-T3,如果僅僅把T3’打到包里回給B,那么B在計算d2的時候就會存在誤差。

關于問題2,PTP這邊利用廣播機制來主動對多個slave進行時鐘同步,工程上具備容易配置,快速收斂(參考前面的機房內master選舉算法過程),以及網絡帶寬和資源占用少等優點

PTP具體同步過程分為delay機制和sync機制:

圖5為PTP時鐘delay機制的同步過程,該過程重點解決一個問題:工程上精準算A到B的網絡時延delay值。

為什么要算這個值呢?基于PTP子網同步的場景特點,PTP假設短時間內,一個子網的網絡波動較小,即D1=D2,且D1值短時間內不會變化。基于這個假設,PTP后面可以以較低開銷完成sync機制的時間同步。

簡單來說,PTP在一個子網內,slave會長周期的進行delay廣播機制,該過程開銷偏大。而master側會短周期的進行sync機制,來達成對子網內全部slave的時鐘同步,該過程開銷相對小。

回到delay機制過程本身,是怎么做到精準測算A到B的delay值呢。圖中T1’,T2’,T3’,T4’都是PTP程序用戶態可以拿到的時間,這些時間都含有誤差。要精準測算delay,B就需要獲取T1,T2,T3,T4,即req和resp從網卡發出,以及達到收包方內核協議棧的時間。

先說T2和T4值,這2個值在udp包達到內核協議棧之后會記錄下來,用戶態可以拿到該時間。從B的視角,T4本身就可以拿到,T2可以讓A的程序在回包的包體里帶上。

再來說T3,這個值的獲取原理,是ptp delay機制需要廣播發起的主要原因。PDelayResp包回包是廣播到子網,由于是廣播包,A自己也可以收到PDelayResp,基于回環廣播特性此時A收到的PDelayResp包的到達時間就是該包的網卡發出時間,即T3。此時A只需要再發一個PDelayRespFollowUp包,包體里帶上T3時間,則B就可以正確獲取T3時間了。

最后說T1,只要明白T3的獲取原理,則類似T3,B本身獲取T1也是基于PDelayReq包的回環達到時間判定。

至此,基于公式delay = (T2-T1+T4-T3)/2即可在工程上完成精準測算A到B的網絡時延delay值。

圖6為PTP時鐘同步的sync過程,該過程運行時,B已經成功獲取到A到B的網絡時延dealy。此時A作為master主動廣播sync請求幫助B精準測算出A,B本地時鐘差值offset。

本次過程依然A,B只能拿到T1’,T2’,但是基于前面delay過程的描述,讀者應該可以比較直接的知道如何獲取到T1和T2。過程不再贅述,B可以直接拿到T2,而followup包會把T1帶給B。

于是我們知道T1+offset+dealy=T2,故A,B機器時鐘誤差滿足offset=T2-T1-delay。B得到offset之后,修改本地時鐘即完成了一次PTP的子網時鐘對齊的過程。

最后提一下,PTP本身的工程源碼也存在一些亂序和時鐘同步錯誤的bug,BIGO內部基于一個版本做了一些改造優化。

跨機房同步

Master機器周期跨機房與super master做時鐘同步,是本架構里主要誤差來源。BIGO內部跨機房,跨大洲以走公網為主,網絡延時大,網絡波動比較明顯。即使內部建設很好的光纖內網,雙向鏈路的延時對稱性也不一定可以保證,在實際運行中受很多因素影響。

在這一層實現上,BIGO基于ptp單播協議(這個不細講了,就是ntp協議的工程實現)來做同步,但是該協議顯而易見在網絡波動下存在誤差和跳變。

針對這個問題,BIGO參考了Ntpd的平滑實現并加入自研的異常波動剔除算法,來優化ptp單播跨機房同步過程存在的誤差和跳變,主要有2個策略:

1. 當計算出offset(即ntp里的diff)在128ms以內時,對master本地時鐘往super master時鐘方向調整最多0.5ms。當計算出offset(即ntp里的diff)大于128ms時,默認忽略該offset,除非該offset持續了一個較大閾值周期(300s),才會基于此offset調整master時鐘;

2. 基于波動閾值x剔除無效同步。當本次ptp單播的delay比最近30次delay值誤差大于閾值x,則本次ptp單播的結果不被應用,同時x相應增加。只有當前ptp結果被采納,且offset值小于2ms,才會把x重置為初始值。

策略1可以保證時鐘對齊過程的平滑,同時時鐘對齊導致的時鐘回退問題也解決了。這里的0.5ms/s不是人為設置一個絕對值,而是調用linux內核封裝的Phase-locked loop機制來對本機時鐘進行調整。從而保證時間調整不會在應用上層體現為時間回退。該機制原理,本文不做展開。

策略2可以剔除網絡波動對同步結果的影響,有點類似chrony的mindelay機制。

BIGO在上線該策略后,對比之前無平滑策略的ntpdate效果明顯,在跨機房同步場景,比nptd和facebook的chrony效果也要更好,相關效果檢驗下面會完整闡述。

效果評測與仿真

關于精度和效果評測這個話題,業界如facebook的chrony內部聲稱做到0.1ms以內的的誤差精度,而google的spanner里的true time是100%確信在7ms的區間內。BIGO在開展此項工作的一期目標是在沒有內部原子鐘的前提下,把99.99%場景誤差精度控制在亞毫秒。

關于精度的測算,本身就是一個跟全球時鐘對齊同等難度的命題。

為什么這么說呢,因為如果我們可以在上帝視角完美0誤差識別任意2臺機器的時間誤差,那么也就代表著我們可以把任意2臺機器的時間誤差調整為0。

已知比較好的評測手段,有facebook提到的基于1PPS(每秒脈沖數)來檢測任意2臺機器的時鐘誤差,該評測可以做到納秒級的誤差,但是對硬件有很多依賴,如需要在機器間鋪設專用同軸電纜,需要定制的網卡硬件。

這個話題,我們主要從2個方向來展開:評價指標和評價手段。

首先關于用什么指標來評價集群內機器之間的時鐘誤差情況,比較直觀的就是機器間誤差的時間軸坐標圖,基于坐標圖我們抽象了2個主要指標:

1)可用性——基于我們對誤差精度的要求是是亞毫秒,則每秒進行一次機器間時鐘誤差判斷,大于1ms則認為這1秒時鐘服務不可用,最后可用時間占比即為可用性;

2)最大誤差值——機器間誤差值波動過大,我們認為需要重點關注。

評價手段這塊,我們沒有相關硬件來支撐我們做1PPS的效果評測,所以我們這里基于仿真的思路來做評測。

我們僅僅觀察同機房的2臺機器A和B的時間誤差,由于同機房機器ping 延時可以穩定在0.1ms以下,此時我們近似具備了較高精度觀測誤差的能力。然后我們僅僅先評測以下3個場景:

1)A和B各自基于某種同步算法,跟本機房(或者同城)的時間源做時間同步,觀測A和B的誤差時間軸坐標圖;

2)A和B各自基于某種同步算法,跟遠端跨大區的時間源做時間同步,觀測A和B的誤差時間軸坐標圖;

3)A基于某種同步算法,跟遠端跨大區的時間源做時間同步,B基于相同同步算法,跟本機房(或者同城)的時間源做時間同步,觀測A和B的誤差時間軸坐標圖。

圖7簡單描述了前面所說的3種評測場景。需要注意一點,待評測的UTC時間源可能是跟我們的機器在一個機房,也可能僅僅是同城,取決于待評測服務本身實際部署情況。

我們再來關注怎么評測一個時鐘同步算法在跨大區機器間的誤差,比如圖中A1和B2之間的時鐘誤差?

軟件層面這個問題看起來是無法評測的,但是我們先假設UTC時間源(外部原子鐘設備)之間是沒有毫秒級誤差,那么A3和B3的時鐘誤差我們暫時可以基于0.1ms的精度進行評測,我們定義A3和B3的時鐘誤差為diff(A3,B3),則diff(A1,B2)近似等于 diff(A3,B3)。

一句話總結,我們可用觀測diff(A3,B3)的結果認為其實仿真表達了diff(A1,B2),等價于我們成功評測了一個時鐘同步算法在跨大區機器間的誤差(本質上還是有2套本機房外部原子鐘UTC源加持,但是僅僅是做評測時依賴而已,我們的系統的機器部署實質不依賴外部UTC時間源的具體部署情況)。

至此,我們已經具備不依賴內部硬件設備,在BIGO全球機房仿真評測同機房,跨大區機器的毫秒級時鐘誤差的能力。

圖8到圖13分別為跨大洲和同機房情況下BIGO,NTP和facebook的chrony時鐘同步誤差測量表。

圖8～圖13為我們觀測BIGO同機房機器,基于不同算法和不同區域源時鐘同步之后,取得的誤差表。全部場景都觀測了3個小時,每秒觀測一次,每張圖都是1萬個橫軸坐標點。需要注意的是,ntpdate本身明顯過于粗糙,我們認為不值得浪費時間進行對比,所以這里只對比了ntpd和facebook的chrony。

此外,這里的對比結果不一定就代表facebook的chrony內部精度情況,僅僅表達了BIGO作為一個第三方,去依賴這些服務,我們能獲得的精度能力。而且chrony本身提供了數十種參數來調優精度和波動,因為精力有限,我們對比時使用默認配置。

圖14為我們對6張評測效果做的總結。

前面3行是跨大洲場景的表現,以前面定義的可用性而言,ntpd和chrony直接使用都無法滿足我們的可用性需求,而最大誤差這塊,BIGO自研架構下的機器時鐘誤差控制在0.5ms內,而直接接入ntpd有近10ms最大誤差,接入chrony的誤差接近6ms。

后3行是同機房或者同大區的表現,此時BIGO自研架構下的機器時鐘誤差的可用性和最大誤差依然是好過直接接入ntpd或者chrony的。其表達的含義為,即使BIGO選擇限制自身的機房部署情況,做架構設計去適配ntpd和chrony源來復用他們提供的時鐘對齊服務,效果依然不如當前版本的BIGO自研架構。

總結

總結一下BIGO在全球時鐘同步服務的工作,在沒有內部原子鐘的前提下,基于雙層架構設計,建設了穩定的內部UTC時間源。同時基于ptp單播配合平滑+異常剔除算法保證了第一層跨機房時鐘同步精度控制在亞毫秒。然后在第二層機房子網內,基于ptp算法實現,優化了網卡發包到用戶代碼層的時間誤差問題,進而把機房內的時鐘精度在毫秒內進一步提升。

最終我們收獲了一個99.99%場景下,集群時鐘誤差都在亞毫秒精度的時鐘服務,且隨著ping值減少,同機房的精度有進一步的提升。該服務架構具備良好的內部可擴展性,不依賴外部NTP時鐘源的部署和服務能力。同時我們提供了有效的評測手段來驗證我們的毫秒級誤差情況。

該系統在內部UTC時間源的精度以及集群可用性,還有對抗上下行延時差值,高精度時鐘評測等方向還有諸多工作待進一步展開優化,這些將規劃到我們的后期工作中。

該系統當前作為基礎設施,為BIGO的全鏈路trace系統等多項服務提供時鐘對齊保證,成功解決了負調用耗時等業務問題。