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