共計 829 個字符，預計需要花費 3 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關如何避免 GitHub 那樣斷網 43 秒癱瘓 24 個小時，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

造成斷網 43 秒癱瘓 24 小時的罪魁禍首是數據庫。由于部署在兩個數據中心的數據庫集群沒有實時同步。意外發生時，Github 的工程師擔心數據丟失，不敢快速將主數據庫安全切換到東海岸的備份數據中心。

程序員們在 GitHub 這篇“懺悔錄”下面留言，表達對數據庫集群的“哀悼”。但更多 IT 從業者關心的問題是，如何避免這樣的災難事件降臨到自己的公司，自己維護的系統。

螞蟻金服 OceanBase 分布式數據庫專家認為，此次 Github 事件是典型的城市級故障。如果系統采用的是高可用的三地五中心解決方案，就可以自如應對。

就在一個月前，今年的杭州云棲大會上，螞蟻金服副 CTO 胡喜現場模擬剪斷支付寶近一半的服務器光纜。只用了 26 秒，模擬環境中的支付寶就完全恢復了正常，這背后即是 OceanBase 城市級別故障的自愈能力。

原來，Github 類似銀行采用的傳統數據庫兩地三中心模式，即“主庫（主機房）+ 同城熱備庫（同城熱備機房）+ 異地災備庫（異地災備機房）”。這種方式下通常只有主機房的服務器能提供寫服務。如果主城市出現城市級故障，災備城市的數據庫雖然可以工作，但由于沒有同步的最新數據，因此災備庫的數據是有損的。

但在三地五中心部署下，任何單個城市故障，OceanBase 都不會停止服務，數據也不會有任何損失。

Github 表示，為了保證數據完整性，他們不得不犧牲恢復時間。其實，這個問題采用三地五中心方案可以更好的應對。城市故障時，OceanBase 只要活著的兩個城市的三個機房兩兩之間能夠通信，就可以正常服務，也不會有任何的數據損失。

關于如何避免 GitHub 那樣斷網 43 秒癱瘓 24 個小時就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。