http://www.sohu.com/a/158859741_444159?qq-pf-to=pcqq.discussion

對于阿里的交易以及支付來講，我們做異地多活最重要的目的除了災備之外，更重要的點是追求持續可用，整個支付交易的體量對于用戶來講是持續可用。我們可以看一下業界比較主流的災備是怎么做的，以及阿里在這方面整個的演進。業界最重要的很多人都知道，最主流的災備技術是兩地三中心，數據中心A和數據中心B在同城作為生產級的機房，當用戶訪問的時候隨機訪問到數據中心A或B。之所以隨便訪問，因為A和B會同步做數據復制，所以兩邊的數據是完全一樣的。但是因為是同步復制的，所以只能在同城去做兩個數據中心，否則太遠的話同步復制的延時會太長。在兩地三中心的概念里，一定會要求這兩個生產級的數據中心是必須在同一個城市，或者在距離很近的另外一個城市也可以，但是距離是有要求的。

異地備份數據中心通過異步復制去走，但是兩地三中心很明顯的是異地備份的數據中心是不起用的，正常情況下不對外服務，所以用戶不會訪問到異地的點。原因是因為數據從生產級數據中心到異地的節點是異步去復制，所以整個有延時。這是整個業界目前用的比較多的業界。兩地三中心對于阿里來講看到的問題，最重要的問題：

1、這個模式不一定Work。大家可能都看到某些新聞里講過，比如說某些地方用了兩地三中心之后，當一地的數據中心出問題的時候，是不敢流量切往異地的備份數據中心，原因是異地的備份數據中心是冷的，平時是沒有用戶流量進去的。如果要把流量切到那邊起來之后，其實沒有人有多強的信心能夠保障起用以后是可以正常服務的，畢竟平時都是冷的。因為是冷的，就意味著整個起用的過程需要時間，不可能說起用就起用，一定會有時間周期。這是兩地三中心的最大問題，看起來模式是很安全的，也是可用的，但是事實上不一定是這樣。

2、異地備份中心因為不對外提供服務，所以整個資源會處于浪費狀態，成本比較高及

3、對于阿里的規模來講有一個很大的問題，在兩地三中心中，數據一定是單點去寫。其實數據只在一個地方去寫，這個時候如果整個壓力比較高，比如像“雙十一”的場景中壓力非常高的情況下，就意味著在兩地三中心的情況下所有的數據還是寫上的單個點，對于存儲成本壓力會不斷增加。比如去年8萬、今年14萬意味著每年壓力都在增加，這時候數據庫整個伸縮和外層業務的伸縮都面臨著更大挑戰。

對于我們來講這三個問題是比較明顯的。阿里在整個高可用上也經歷過了一段時間，主要是做了三個步驟。第一個是做了同城的雙活，第二個做了異地只讀及冷備，第三個是做了異地多活，經歷了三代體系的演進才走到了今天。

異地多活對于我們來講，其實很多人都可以看到異地多活最大的挑戰是什么？

1、距離。看起來距離沒有什么，比如說1000公里以上也就是30毫秒的網絡延遲，來回一次是30毫秒左右。30毫秒對于用戶來講，如果只是給你增加30毫秒，用戶其實沒有感受。但是當你打開一個淘寶頁面的時候，事實上當你在商品頁面看到一個商品點立刻購買的時候，頁面的背后大概有100多次以上的后端交互，如果100多次全部跨地域完成的話，就意味著頁面的響應時間將增加3秒。如果增加3秒，用戶絕對會有明顯感受。因為對于阿里來講，很多頁面就出不來了，3秒已經超時了。對于我們來講，這第一點是直接帶來用戶體驗的不可用。成本，當系統響應時間增高的時候，意味著每年“雙十一”增加的QPS將付出更大的成本，因為吞吐量在下降，這個時候的成本也是很難接受的。距離帶來的延時問題是最大的問題。

2、既然要解決掉距離的問題，多點寫是解決距離的問題，如果沒有延時問題可以不多點寫。只要開始多點寫了就會帶來第二個最復雜的問題，其實我們認為第一點延時問題一定程度也許可以強制接受，也就是能夠打開，打不開就有問題了。如果一旦出現多點寫帶來的數據正確性問題，這對我們來講是最致命的。多點寫，比如說出現這一次訪問在A數據中心寫的數據，然后再訪問的時候到B數據中心又寫了一條數據，兩條數據如果合不到一起的話。對于大家最直觀的感受是有可能買了一個東西付了錢，然后看到可能是沒付錢。或者干脆買了一個東西，壓根就沒有看到購買。對于阿里來講，這是最大的一個問題。

對于我們來講，當阿里整個架構能力進一步提升到了異地多活時代以后，對于我們來講帶來了兩個好處：

第一、有極強的水平伸縮能力。以前做“雙十一”的時候，都必須去算，比如去年8萬筆，今年14萬筆的時候，必須要算增加的6萬。還有因為每年業務模式的變化需要算每個應用加多少機器。但是在單元的情況下，一組單元就是多大的能力，然后只要按照單元擴充就結束了。假設一個單元可以做到2萬筆，其實14萬筆對于我們來講是建設7個單元就結束了，整個伸縮能力會比以前強大非常多。而且每個單元都是寫自己的數據庫和存儲層，包括cache全部寫自己的，這個時候伸縮規模是可控的，不像以前不斷加，數據庫有可能抗不住。在抗不住的時候可能會做分布等等，但其實也是比較復雜的，現在我們改變了伸縮力度的模式。

第二、異地多活怎么去應對故障。比如在阿里內部會按照這樣的等級去劃分所有業務能夠支持故障應對能力，比如說單實例出故障在多久能恢復，或者單機房或單城市或全局的服務，比如DNS等等，我們會按照這個對每個業務，然后就知道每個業務當出現故障時整個應對能力是怎樣的。

轉載于:https://www.cnblogs.com/davidwang456/articles/8192860.html

總結

以上是生活随笔為你收集整理的阿里异地多活与同城双活的架构演进的全部內容，希望文章能夠幫你解決所遇到的問題。

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