今天，github技術負責人jason warner的技術深度解析稿成為了it圈的爆款。 在本文中，jason坦率地敘述了10月21日100g光纜設備故障后，github服務降級的應急過程和反思總結。

從jason warner的副本可以看出，互聯(lián)網(wǎng)癱瘓43秒全天候的原因是數(shù)據(jù)庫。 因為部署在兩個數(shù)據(jù)中心的數(shù)據(jù)庫群集沒有實時同步。 在發(fā)生意外情況時，github工程師擔心數(shù)據(jù)丟失，無法迅速安全地將主數(shù)據(jù)庫切換到東海岸的備份數(shù)據(jù)中心。

程序員們在名為github的懺悔下留言，表達對數(shù)據(jù)庫集群的哀悼。 但是，越來越多的it人員關心的問題是，不讓這種災害降臨到自己的企業(yè)，而是自己維持的系統(tǒng)。

螞蟻金服oceanbase分布式數(shù)據(jù)庫專家認為，此次github是典型的城市級障礙。 如果系統(tǒng)使用高可用性的三地五中心處理方案，則可以自由應對。

一個月前，在今年的杭州云棲大會上，螞蟻金服副cto胡喜現(xiàn)場模擬切斷了支付寶( Alipay )近一半的服務器光纜。 僅僅26秒鐘，模擬環(huán)境的“支付寶”( Alipay )就完全恢復了正常。 其背后是oceanbase城市級障礙的自我修復能力。

原來，github如銀行使用的那樣，傳達了2個地區(qū)的3個中心模式:主庫(主機房) +同城熱備盤(同城熱備室) +異地災害恢復庫(異地災害恢復室) 在這種方式中，一般只有主機室的服務器可以提供寫入服務。 在主城市發(fā)生城市級故障的情況下，災難恢復城市的數(shù)據(jù)庫可以運行，但由于沒有同步的最新數(shù)據(jù)，該災難恢復庫中的數(shù)據(jù)已損壞。

但是，在三地五中心的部署中，即使單個城市發(fā)生故障，oceanbase也不會停止服務，數(shù)據(jù)也不會丟失。

github先生說，為了保證數(shù)據(jù)的完整性，必須犧牲恢復時間。 其實，這個問題如果使用三地五中心方案的話，會得到更好的應對。 如果城市發(fā)生故障，oceanbase只要能夠在活的兩個城市的三個機房的兩個之間進行通信，就可以正常服務，也不會有數(shù)據(jù)丟失。