科技圈最火的新聞應該是“AWS中國區光纜被挖，導致三星、小米等衆多企業服務不可用”。 又是光纜被挖，咦！？爲什麼是又，讓我們來一起回到過去：
2019.6.02：亞馬遜光纜被挖斷,國內部分地區網絡出現異常
2019.3.23：施工隊挖斷騰訊光纖,致騰訊旗下100多款遊戲受影響,損失大了
2015.5.27：由於杭州市蕭山區某地光纖被挖斷，造成目前少部分用戶無法使用支付寶
我這裏只是列出來了幾家大公司所涉及到的光纜被挖事故，其餘還包括什麼廣電光纜被挖，社保局光纜被挖就不列了，感興趣的自己去百度。
好，我們發現“公司再大，也怕施工隊”，那麼這種事故能怪施工隊嗎？個人覺得不能把責任都推給施工隊，當然我們這裏不討論這些，我們做爲大公司，我們以後怎麼預防這種現象呢？ 這個我們可以來看下支付寶的解決辦法，畢竟它老人家在2015年就經歷過這種慘況了。
2018年9月20日，杭州雲棲大會ATEC主論壇現場上演了一場特別的技術秀。螞蟻金服副CTO胡喜現場模擬挖斷支付寶近一半服務器的光纜。結果只過了26秒，模擬環境中的支付寶就完全恢復了正常。
這種解決辦法就是“三地五中心”，這是一種機房架構，即在三座城市部署五個機房，一旦其中一個或兩個機房發生故障，依靠技術可以將故障城市的流量全部切換到運行正常的機房。 那麼在“三地五中心”之前還存在很多其他架構，我們一一來看一下他們的特點。
最初，我們把應用(一個非常簡單的只讀應用，比如一個顯示Hello World的網頁，不考慮數據存儲)只放在一個機器上，那麼當這個服務器down機了，我們的應用便不可用了。 所以，我們考慮把我們的應用放在多個機器上，在公司單獨開闢一個機房來放置這些機器，這樣單獨某一個臺機器down機了並不影響我們的應用。 但是，如果你們公司某一天停電了呢？這個時候我們就考慮在這座城市的另外一個地方在放置一個機房，這是應用就被部署在了同城的兩個機房（這個叫同城雙活） 但是，如果你們城市某一天經歷了海嘯、颱風、地震等自然災害，兩個機房都不能使用了，這個時候我們就會考慮在另外一個城市再搭建一個機房來部署我們的應用，這樣我們應用的可用性就更高了（這個叫異地多活）。 好，到此爲止不管出現什麼樣的狀況，我們的應用基本上都可用（除非地球毀滅...）
那麼我們上面考慮的應用是一個非常簡單的只讀應用，所以各個地方的應用是可以同時對外提供服務的，那麼如果我們的應用涉及到數據存儲，這個時候各個地方的應用就不能同時對外提供寫入數據的服務了，因爲很有可能會出現數據衝突，那麼我們暫且規定只有公司內部機房裏的服務器（後文我們叫主機房）可以提供寫數據服務，而同城的另外一個機房以及異地的另外一個機房只能從主機房同步數據，這樣這兩個地方的機房的功能就叫災備，因爲數據會同步，所以就算主機房停電了，另外兩個機房還是可以臨時來對外提供服務的。所以現在的架構可以如下：
當主機房停電後，用戶會去請求北京備份機房，當北京備份機房也停電後，用戶會去請求上海備份機房。 好，對於這個架構，我們剛剛說只有主機房能對外提供服務，另外兩個機房都只是作爲容災的備份，那麼也就是說備份機房利用率不高，因爲畢竟正常請求下主機房不可能老停電，所以對於備份機房能不能提高它的利用率呢？當然可以，我們可以讓北京的備份機房也去接收部分業務請求，只是這些請求可以沒那麼重要，比如一些讀請求，而上海的備份機房不去接收請求，還是單純作爲容災備份機器，因爲如果誰都不能保證當備份機房接收業務請求會不會出現其他不可預知的問題，那麼現在三個機房的角色實際上已經有些不同了：
這個就叫兩地三中心。 那麼兩地三中心這種架構是目前很多銀行或大型企業正在使用的一種架構，因爲國家針對銀行的災備能力做過要求，資產超過多少多少的一定要做兩地三中心架構，以保證銀行系統的穩定。
那麼這種架構有沒有它的缺點呢？我們來考慮一下它的可用性高不高？可用性的意思就是這個架構處理用戶請求時夠不夠快？ 我們發現這種架構，中心之間是需要數據備份的，那麼對於數據備份只有兩種方式，要麼異步，要麼同步。
最大性能模式：如果是異步，表示用戶一個寫數據請求，只要在生產數據中心存儲完數據後就會直接返回結果給用戶，同時異步去備份數據，但是，如果正準備去異步備份數據的時候生產數據中心停電了~，那麼這個時候還能將災備服務器暴露出去給用戶提供服務嗎？不能了，因爲很有可能災備中心的數據是過時的數據。
最大保護模式：如果是同步，表示用戶一個寫數據請求，不僅要等待生產數據中心存儲完數據，還需要等其他災備中心備份完數據後才能返回，而且僅僅當災備中心出現問題時，因爲不能完成數據的備份，所以整個架構也不能對外提供服務，這種可用性是很低的。
最大可用模式：這是普遍採用的方案，正常情況下使用最大保護模式，同時生產數據中心監控災備數據中心，一旦發現某一災備中心出現了問題，那麼則會改爲最大性能模式，這樣就保證了生產數據中心不受其他災備中心影響。
三寫兩同步：這是阿里之前的架構模式，意思是同城三個中心，數據備份不是發生在數據庫層面，而是應用層，當應用向數據庫去寫數據時，會同時向三個中心去寫數據，只要有兩個中心返回成功即可，這樣就算三個中心有一箇中心停電了，那麼並不影響整個架構的高可用，這個思路和我們前面三種是不一樣的，性能肯定會高很多。
好，我們介紹了一下兩地三中心，總結一下它的缺點：
災備中心利用率不高
生產數據中心停止運行後，災備中心中不一定有100%一模一樣的數據
成本高，但又無法真正實現期望的高可用能力
那麼爲了解決這個問題，就出現了三地五中心，雖然名字和兩地三中心類似，但提供的功能完全不同。 三地五中心是指三個城市，5箇中心， 三地五中心基於的概念是單元化，還得花很大篇幅來講，下一篇繼續吧。
相信大家不喜歡在小小的手機屏幕上還看到一大塊的代碼，閱讀體驗不好，所以我寫作的風格會文字偏多一點。如果覺得有所收穫就給個小小的贊吧。
推薦閱讀
金三銀四季，阿里工作10多年Java大牛的“心得”，獻給迷茫中的你