本篇文章833字,讀完約2分鐘

幕墻鋁板

今天,github技術(shù)負(fù)責(zé)人jason warner的技術(shù)深度解析稿成為了it圈的爆款。 在本文中,jason坦率地?cái)⑹隽?0月21日100g光纜設(shè)備故障后,github服務(wù)降級(jí)的應(yīng)急過程和反思總結(jié)。

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


程序員們?cè)诿麨間ithub的懺悔下留言,表達(dá)對(duì)數(shù)據(jù)庫集群的哀悼。 但是,越來越多的it人員關(guān)心的問題是,不讓這種災(zāi)害降臨到自己的企業(yè),而是自己維持的系統(tǒng)。

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

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


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

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

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

標(biāo)題:“怎么不使GitHub那樣斷網(wǎng)43秒癱瘓 24 個(gè)小時(shí)?”

地址:http://www.kungfu-fish.com//xwdt/36376.html