2.1.6 異地多活架構設計

兩地三中心容災設計帶來極大的浪費，并且沒有解決訪問效率問題。兩個可用的數據中心都部署在同一個城市或相鄰的城市，例如，服務器部署在北京，則只有華北、華中等周邊地區訪問速度較快，而華南地區、海外地區訪問速度較慢。

因此，最好的架構應該是異地多活架構，就是全國乃至全球部署數據中心，這些數據中心同時對外提供服務，讓不同地區的用戶訪問距離他們最近的數據中心。但是，部署成本極高，并且技術復雜，資金和人員投入巨大。

例如，分別設立北京、上海、香港數據中心，通過域名解析將不同地區的用戶請求分發到不同的數據中心，如圖2-17所示。

異地雙活是異地多活的特例，是指在兩個距離較遠的城市建立IDC（Internet Data Center，互聯網數據中心），同時對外提供服務。

異地多活架構主要存在以下兩個問題。

（1）跨數據中心訪問，導致處理速度慢。用戶的一次請求，對于分布式系統，可能在服務器發生數十次的調用，如果這些調用不能發生在同一個IDC內，延遲就會較高。

例如，某北京用戶的一次購買行為，服務器需要200個服務調用完成，如果這200次調用全部在北京IDC內完成，每次調用耗時2毫秒，則全部串行化總計需要200×2=400(毫秒)給用戶應答。如果這200次調用中有100次發生在北京IDC內，每次調用耗時2毫秒，另外有100次發生在上海IDC內（發生跨IDC調用），每次調用耗時20毫秒，則全部串行化總計需要(100×2+100×20)/1000=2.2(秒)給用戶應答，會造成極差的用戶體驗，甚至有些頁面直接超時，如圖2-18所示。

所以，異地多活的第一個要求就是盡量讓所有的交易發生在同一個IDC內，避免出現跨區訪問。

（2）數據無法實時同步。由于各個IDC的距離較遠，網絡延遲是無法避免的，因此數據無法達到實時復制。如果不進行特殊的控制，則會產生很嚴重的不一致性問題。

例如，某用戶購買商品時，交易是在北京機房完成，訂單數據也存儲在北京機房內。緊接著用戶去查看訂單信息，這時請求到了上海機房，而此時數據還未同步過來，就會導致用戶無法看到訂單，這是用戶無法容忍的錯誤。

為了解決數據同步延遲問題，最簡單的方式就是數據庫不拆分也不同步，都集中在一個IDC中，多個IDC中的服務共享一套數據源，即偽異地多活架構，如圖2-19所示。

每個IDC中除數據庫外均正常部署，所有服務都對一個數據源（并非一個數據庫）進行讀寫。這樣就保證了數據的一致性。這種方式部署實現相對簡單，但是數據庫壓力過大，并且跨區訪問時由于數據庫遠程訪問，依然會造成交易效率很低。這種方案依然只適合多個IDC同城或鄰城部署，因此通常作為異地多活的一種過渡方案。

真正的異地多活架構則是數據庫都是完全獨立拆分部署的，通過同步的方式進行數據同步，但是復制延遲是無法避免的，因此這個問題無須糾結（因為現代的通信技術還無法徹底解決長距離數據傳輸的延遲問題）。所以，異地多活架構并不是將所有業務都進行異地部署，對于一些賬戶余額、轉賬等一致性、實時性要求極高的業務并不適合，而且對于一些非常用的交易也沒有必要進行異地多活設計。例如，登錄操作是使用極其頻繁的，用戶可能一天要登錄10次，而用戶信息修改可能一個月才修改1次，并且用戶登錄十分重要，是一切業務的起點，而用戶信息修改并不重要。

用戶的位置幾乎是固定的，不會出現現在在北京登錄，而10分鐘之后在上海登錄。所以，對于登錄業務、用戶注冊、產品訂單等數據只需要異步復制到其他IDC即可，達到最終的數據一致性。

所以，將同一個地區的用戶交易控制在一個IDC內，數據存儲在一個IDC內，再將數據異步復制到其他IDC是一種較好的方案。