兩地三中心這個架構，如下圖：

?

這種架構具備容災能力，比如生產數據中心停電了，那么可以把所有流量都切到同城災備中心或異地災備中心，那么現在的問題是假如真到了停電的那一天，你敢把所有的流量都切到災備中心去嗎？上篇文章說了，災備中心它主要的功能是作為生產數據中心的一個備份，所以它并沒有如同生產數據中心一樣不停的在對外提供服務，那么就有問題了，災備相當于一個新人，一個一直在模仿大哥的一個新人，現在大哥受傷了，按道理是應該小弟頂上，但是小弟還是個新人，硬頂上去是不是很有可能會出錯？也就是說：

• 第一，不能保證災備中心有能力接管線上所有的用戶流量，可能剛已接收災備中心被壓垮，或者出現其他各種各樣預估不到的錯誤；

• 第二，如果生產數據中心接收了用戶的寫請求，還沒來得及同步到災備中心，這個時候停電了，這種情況下，也不能直接把用戶流量切到災備中心。

所以基于上面的分析，并不是說災備中心一定不能頂上，只是在頂上之前可能還要做很多其他的檢查和準備，這個時間是不確定的，至少不會很快...。

那么問題來了，該怎么辦？

首先對于上面列出來的兩點中的第一點，如果我們能夠讓災備中心不再僅僅只能用來做災備，還能和生產數據中心一樣正常的對外提供服務呢？如下圖：

可以看到上面的架構圖：

• 不再區分生產數據中心和災備數據中心，只有數據中心，而且數據中心之間相互備份數據，保證每個數據中心都是全量數據。

• 用戶可以在任意一個數據中心上進行讀寫操作。

好，首先我們不管這種架構能不能實現，至少它的好處是非常明顯的：

每個數據中心一直在對外提供服務（不是一個新手），所以當一個數據中心停電后，直接把用戶流量切到另外一個數據中心也是問題不大的。

用戶可以就近訪問數據中心，這樣用戶的體驗更好，并且整個架構的流量也比較平均。

優點很明顯，如果能實現就再好不過了，那么這種架構實現起來最重要的一點就是：用戶同時向不同數據中心寫入數據，數據中心雙向同步數據時，如果出現沖突該如何解決？那么這個問題，目前阿里和螞蟻金服的解決辦法是：將用戶按某一個規則進行分組，每組用戶寫入數據時只能寫入到指定的數據中心，相當于用戶與數據中心綁定在一起了，這樣保證了數據中心在雙向同步之前數據是不會沖突的，因為按用戶分組了，不同用戶的數據不會沖突。當然思路非常簡單，但是實現起來肯定是非常麻煩的，但是思路肯定是可以的，阿里也用實踐證明了，我們先把上面的架構稍微完善一下：

?

用戶使用網站時，由運營商網絡或CDN選擇最近的機房，機房內部署一個負載均衡，由這個負載均衡最終判斷用戶屬于機房（前文中的數據中心），也就是可能出現，用戶在注冊時在北京，那么他的uid就和北京某個機房綁定了，那么當這個用戶在上海使用時，會由上海的負載均衡按照用戶分組規則將請求轉發到北京綁定的那個機房去（當然并不是所有請求，比如讀請求肯定可以直接在上海機房進行讀取，所以具體的實現都要看業務怎么實現了，以及負載均衡具體的配置，這里只是把最簡單易懂的思路說一下）。

所以，我們現在可以

• 假設北京機房1應用程序或數據庫對應的機器停電了，那么我們可以調整負載均衡是原本屬于這個機房的用戶流量轉移到機房2去，注意這里不要有疑問，將用戶進行分組是為了防止用戶同時寫兩個數據庫發生沖突，那么現在機房1里其實已經不能寫入數據了，所以將流量遷移到機房2是沒有問題的。

• 假設北京機房1整個停電了，那么可以通過運營商網絡或CDN將流量遷移到北京機房2。

• 假設北京停電了，那么一樣可以將流量遷移到上海。

這個架構中最重要的其實就是用戶分組，所以包括我們的應用程序、數據庫負載均衡、數據庫分表等等都需要按用戶進行分組，我們要保證針對同一個用戶的請求與操作都在同一個機房內，不去跨機房，這樣才是最快的，這就是單元化。

那么上面這個架構實際上就是一個高級版的“兩地三中心”，只是這種單元化架構我們可以任意去擴展（只要你足夠有錢，因為搭一套全配置的數據中心是需要很高成本的），比如你在上海在增加一個數據中心，在杭州也增加一個，那么就如下圖：

這就叫三地五中心。

總結

以上是生活随笔為你收集整理的你知道三地五中心吗的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。