上篇文章我們總結了一下同城雙活、異地多活、兩地三中心等一些部署架構，那麼這篇文章我來發表一下我對三地五中心的理解。 我們上篇文章講過兩地三中心這個架構，如下圖：
這種架構具備容災能力，比如生產數據中心停電了，那麼可以把所有流量都切到同城災備中心或異地災備中心，那麼現在的問題是假如真到了停電的那一天，你敢把所有的流量都切到災備中心去嗎？ ** 上篇文章說了，災備中心它主要的功能是作爲生產數據中心的一個備份，所以它並沒有如同生產數據中心一樣不停的在對外提供服務，那麼就有問題了，災備相當於一個新人，一個一直在模仿大哥的一個新人，現在大哥受傷了，按道理是應該小弟頂上，但是小弟還是個新人，硬頂上去是不是很有可能會出錯？也就是說：
第一，不能保證災備中心有能力接管線上所有的用戶流量，可能剛已接收災備中心被壓垮，或者出現其他各種各樣預估不到的錯誤；
第二，如果生產數據中心接收了用戶的寫請求，還沒來得及同步到災備中心，這個時候停電了，這種情況下，也不能直接把用戶流量切到災備中心。
所以基於上面的分析，並不是說災備中心一定不能頂上，只是在頂上之前可能還要做很多其他的檢查和準備，這個時間是不確定的，至少不會很快...。
那麼問題來了，該怎麼辦？
首先對於上面列出來的兩點中的第一點，如果我們能夠讓災備中心不再僅僅只能用來做災備，還能和生產數據中心一樣正常的對外提供服務呢？如下圖：
可以看到上面的架構圖：
不再區分生產數據中心和災備數據中心，只有數據中心，而且數據中心之間相互備份數據，保證每個數據中心都是全量數據。
用戶可以在任意一個數據中心上進行讀寫操作。
好，首先我們不管這種架構能不能實現，至少它的好處是非常明顯的：
每個數據中心一直在對外提供服務（不是一個新手），所以當一個數據中心停電後，直接把用戶流量切到另外一個數據中心也是問題不大的。
用戶可以就近訪問數據中心，這樣用戶的體驗更好，並且整個架構的流量也比較平均。
優點很明顯，如果能實現就再好不過了，那麼這種架構實現起來最重要的一點就是：用戶同時向不同數據中心寫入數據，數據中心雙向同步數據時，如果出現衝突該如何解決？ ** 那麼這個問題，目前阿里和螞蟻金服的解決辦法是：將用戶按某一個規則進行分組，每組用戶寫入數據時只能寫入到指定的數據中心，相當於用戶與數據中心綁定在一起了，這樣保證了數據中心在雙向同步之前數據是不會衝突的，因爲按用戶分組了，不同用戶的數據不會衝突。 ** 當然思路非常簡單，但是實現起來肯定是非常麻煩的，但是思路肯定是可以的，阿里也用實踐證明了，我們先把上面的架構稍微完善一下：
用戶使用網站時，由運營商網絡或CDN選擇最近的機房，機房內部署一個負載均衡，由這個負載均衡最終判斷用戶屬於機房（前文中的數據中心），也就是可能出現，用戶在註冊時在北京，那麼他的uid就和北京某個機房綁定了，那麼當這個用戶在上海使用時，會由上海的負載均衡按照用戶分組規則將請求轉發到北京綁定的那個機房去（當然並不是所有請求，比如讀請求肯定可以直接在上海機房進行讀取，所以具體的實現都要看業務怎麼實現了，以及負載均衡具體的配置，這裏只是把最簡單易懂的思路說一下）。
所以，我們現在可以
假設北京機房1應用程序或數據庫對應的機器停電了，那麼我們可以調整負載均衡是原本屬於這個機房的用戶流量轉移到機房2去，注意這裏不要有疑問，將用戶進行分組是爲了防止用戶同時寫兩個數據庫發生衝突，那麼現在機房1裏其實已經不能寫入數據了，所以將流量遷移到機房2是沒有問題的。
假設北京機房1整個停電了，那麼可以通過運營商網絡或CDN將流量遷移到北京機房2。
假設北京停電了，那麼一樣可以將流量遷移到上海。
這個架構中最重要的其實就是用戶分組，所以包括我們的應用程序、數據庫負載均衡、數據庫分表等等都需要按用戶進行分組，我們要保證針對同一個用戶的請求與操作都在同一個機房內，不去跨機房，這樣纔是最快的，這就是單元化。
那麼上面這個架構實際上就是一個高級版的“兩地三中心”，只是這種單元化架構我們可以任意去擴展（只要你足夠有錢，因爲搭一套全配置的數據中心是需要很高成本的），比如你在上海在增加一個數據中心，在杭州也增加一個，那麼就如下圖：
這就叫三地五中心。
市面上淺顯的講述三地五中心的文章不多，希望這篇文章能給你幫助，當然我也是參考了其他文章有了自己的理解，如果錯誤的地方歡迎大家指正。
相信大家不喜歡在小小的手機屏幕上還看到一大塊的代碼，閱讀體驗不好，所以我寫作的風格會文字偏多一點。如果覺得有所收穫就給個小小的贊吧。
推薦閱讀
金三銀四季，阿里工作10多年Java大牛的“心得”，獻給迷茫中的你