背景
檔案網關在一個事務中将客戶戶端資料寫入緩存盤傳回,然後以異步的方式在背景線程中上傳到OSS,如果存在多個網關共享同時寫入一個檔案,對象的完整性是由OSS語義來保證的,網關始終能夠保證正向同步的資料一緻性。當網關需要反向同步OSS端的中繼資料時,之前采用的政策是定期在使用者所進入的目錄内進行全掃描,也可以保證網關的中繼資料最終與OSS一緻。為了實作高效的資料共享,網關推出了極速同步功能,以初始全量掃描+增量事件通知的方式快速同步雲上的中繼資料。在使用者體驗到秒級同步的極速性能時,網關是如何保證反向同步的一緻性呢?是否會存在丢失增量資訊的情況?如果由于網絡原因導緻MNS服務不可用又如何處理?下面我們就着這些問題展開讨論。
狀态機管理
在極速同步的生命周期管理中,我們引入了幾個狀态位。

全量同步等待:網關建立同步組時會同時建立OSS事件通知規則,規則會同步到OSS叢集,生效需要10分鐘時間,如果同步組建立之後共享立即開啟同步功能,則需要等待最長時間,稍後開啟的話等待時間會随之減少。
全量同步進行中:建立全量同步掃描任務,多線程快速掃描OSS同步中繼資料到網關,監控任務狀态,直至任務完成
同步正常:全量同步任務完成後,開始增量同步,處理消息隊列的通知消息,并監控消息主題和消息隊列的狀态以及心跳包監聽。需要注意的是,在全量同步等待中,網關已經開啟消息監聽,在全量同步的過程中有OSS事件發生,也會進行處理。雖然與全量同步可能存在重複對象處理,保證了全量同步完成時,網關的中繼資料和雲上是完全一緻的。
同步異常:異常是一個統稱,會細化為消息主題不可通路,消息隊列不可通路。
狀态機異常處理
全量同步等待中:如果網關重新開機或者背景程序重新開機,會持久化儲存等待時間,保證事件規則生效。
全量同步進行中:如果全量掃描任務出現異常,會重新發起掃描任務。
同步正常:如果健康檢查中發現消息主題或者消息隊列不可通路,會上報異常狀态。同時每個開啟極速同步的共享會發送心跳包到消息主題,如果沒有收到心跳包,有可能是消息主題/消息隊列不可通路導緻消息通路中斷或者是網關當機很長一段時間才恢複。MNS可以保證已經成功投遞的消息至少會被消費一次,如果長期沒有收到心跳包,投遞的消息會在消息隊列中堆積,考慮到消息有其存活周期,心跳包中斷超過一定的期限,我們會重新開機全量掃描任務保證極速同步共享重新獲得跟OSS一緻的中繼資料資訊。
消息投遞失敗處理
對于消息主題和消息隊列的持續異常網關會通過健康檢查上報,這裡讨論的是偶發性的OSS事件通知投遞失敗。OSS投遞事件消息,會有簡單重試機制,如果還是失敗的話,會把投遞狀态位傳回給網關,網關會生成自定義的消息往消息主題,重試直至投遞成功。
小結
本文介紹了極速同步的生命周期管理,包括同步中的狀态機管理以及異常處理。網關確定極速同步共享的消息投遞成功,MNS保證了消息最少被消費一次,可以保證消息都能夠被處理。在異常情況下,會有健康檢測上報和心跳包實效管理,重新開機全量同步掃描保證資料的最終一緻性。