互聯網時代，服務器機房可謂心臟，大型機房出故障是小概率事件。但即便如此，依然可能出現自然災害、斷電、光纜被挖斷等黑天鵝事件。

有人斗膽下了個戰書：如果多個機房的光纜同時被挖斷，40%的服務器突然無法工作，結果會怎樣?

結果，居然還真的有人敢來應戰。此人便是螞蟻金服副CTO胡喜。

據報道，在9月20日的云棲ATEC主論壇上，螞蟻金服副CTO胡喜在現場特別模擬了剪斷支付寶位于一個城市中兩個模擬機房的光纜。

一旦機房發生故障，會怎么辦?

首先，設想一下服務器機房如果發生了故障，我們的生活會出現什么樣的變化?

斷網了，或許打不通網頁，或許撥不出電話，或許各種失聯……

有人說如果服務器機房發生變化，在支付寶領域，遇到的最大困擾就是轉賬失敗。

轉賬失敗?付不了帳?買不了東東，這可腫么辦?

螞蟻金服正是這樣做了這樣一次嘗試性實驗，此次實驗被差評君（ID:Chaping321）全程記錄。

現場在模擬支付寶轉賬的同時，程序員剪斷了位于杭州一個模擬機房的光纖，當光纖被剪斷后，這個模擬機房所負責區域的任何業務都不能處理。這就是轉賬失敗的原因。

螞蟻金服副CTO胡喜現場解釋，這是演習。

然而，在真實環境下，如果支付寶部署在兩個城市的兩個機房同時出問題，據官方宣稱，跑在這兩個機房上的支付寶賬戶，恢復正常的速度是分鐘級。精確地說，只需要26秒，模擬環境中的支付寶就能完全恢復正常。

分分鐘就能完全恢復，這完全顛覆了宕機停服幾個小時的傳統印象。

為什么能在這么短的時間，能讓故障排除，迅速恢復到正常工作的情況?

據悉，這是因為這一機房架構叫“三地五中心”，即在三座城市部署五個機房，一旦其中一個或兩個機房發生故障，其底層技術系統會將故障城市的流量全部切換到運行正常的機房，并且能做到數據保持一致且零丟失。

目前，互聯網和金融科技行業普遍采用的是“兩地三中心”部署架構，即在一個城市設兩個機房，在另一個城市設一個冷備機房。

而在這個實驗中，城市A的兩個機房是服務大眾的，不管是轉賬、繳費還是查賬全部都由這兩個機房提供服務，而且兩個機房是同步在處理數據且數據一致的。但在城市B的備份機房只是做備份而已，并不參與服務大眾這一活動。

一旦城市A的兩個機房被自然災害等毀壞就不能繼續對外服務，那只能讓程序員熬夜去切換另一個城市的備份數據。但是由于B城市的機房常年沒有工作(提供服務)，整個機器都處于“冷凍人”的狀態，所以切換前還需要校驗數據，再預熱等等復雜的操作后才能讓服務再次暢通。

這就是為什么很多App服務器掛掉的時候，要花很久時間才能恢復的原因。

據悉，上圖是支付寶的城市級故障自動容災系統，是它支撐了26秒的災后恢復。

災備方案有備無患

目前來看，主要的數據備份方式如下：

定期磁帶備份：包括遠程磁帶庫、光盤庫備份和遠程關鍵數據+磁帶備份。

數據庫備份：就是在與主數據庫所在生產機相分離的備份機上建立主數據庫的一個拷貝。

網絡數據：這種方式是對生產系統的數據庫數據和所需跟蹤的重要目標文件的更新進行監控與跟蹤，并將更新日志實時通過網絡傳送到備份系統，備份系統則根據日志對磁盤進行更新。

遠程鏡像：通過高速光纖通道線路和磁盤控制技術將鏡像磁盤延伸到遠離生產機的地方，鏡像磁盤數據與主磁盤數據完全一致，更新方式為同步或異步。

這些措施能夠在系統發生故障后進行系統恢復，但是這些措施一般只能處理計算機單點故障，對區域性、毀滅性災難比如地震、火災等則束手無策，免備案主機，也不具備災難恢復能力。

災備場景涵蓋面廣，方案復雜，傳統數據中心容災方案存在CAPEX、OPEX高昂、數據同步策略復雜、災難恢復效果有限等問題。企業有必要采用多云災備策略，以保證業務連續性及關鍵數據可靠性。我們就需要建立異地容災中心，做數據的遠程備份，在災難發生之后要確保原有的數據不會丟失或者遭到破壞。建立的異地容災中心可以簡單地把它理解成一個遠程的數據備份中心。