總結：

多活基本思路： 每個中心都是活的，可以實時承擔流量，任何一點出問題，都可以直接切掉，由另外一點直接接管，非傳統的兩地三中心冷備方式。挑戰及解決方法： 服務延時。

讓操作全部在同一中心內完成，單元化 比如使用者進入以後，比如說在淘寶上看商品，瀏覽商品，搜尋、下單、放進購物車等等操作，還包括寫資料庫，就都是在所進入的那個資料中心中完成的，而不需要跨資料中心部署： 異地部署的是流量會爆發式增長的，流量很大的那部分。流量小的，用的不多的，不用異地部署。 其他一些功能就會缺失，所以我們在異地部署的並非全站，而是一組業務，這組業務就成為單元 比如：在異地只部署跟買家交易相關的核心業務，確保一個買家在淘寶上瀏覽商品，一直到買完東西的全過程都可以完成路由一致性

： 買家相關的資料在寫的時候，一定是要寫在那個單元裡。要保障這個使用者從進來一直到訪問服務，到訪問資料庫，全鏈路的路由規則都是完全一致的。如果說某個使用者本來應該進A城市的資料中心，但是卻因為路由錯誤，進入了B城市，那看到的資料就是錯的了。造成的結果，可能是使用者看到的購買列表是空的，這是不能接受的。

延時： 異地部署，我們需要同步賣家的資料、商品的資料。能接受的延時必須要做到一秒內，即在全國的範圍內，都必須做到一秒內把資料同步完

中心之間骨幹網。

資料一致性： 把使用者操作封閉在一個單元內完成，最關鍵的是資料。在某個點，必須確保單行的資料在一個地方寫，絕對不能在多個地方寫。 為了做到這一點，必須確定資料的維度。淘寶除了使用者本身的資訊以外，還會看到所有商品的資料、所有賣家的資料，面對的是買家、賣家和商品三個維度。因為異地的是買家的核心鏈路，所以選擇買家這個維度。按買家維度來切分資料。但因為有三個維度的資料，當操作賣家、商品資料時，就無法封閉。 在所有的異地多活專案中，最重要的是保障某個點寫進去的資料一定是正確的。這是最大的挑戰，也是我們在設計整個方案中的第一原則。業務這一層出故障我們都可以接受，但是不能接受資料故障。 多個單元之間一定會有資料同步。一方面，每個單元都需要賣家的資料、商品的資料； 另一方面，我們的單元不是全量業務，那一定會有業務需要這個單元，比如說買家在這個單元下了一筆定單，而其他業務有可能也是需要這筆資料，否則可能操作不了，所以需要同步該資料。 所以怎樣確保每個單元之間的商品、賣家的資料是一致的，然後買家資料中心和單元是一致的，這是非常關鍵的。  

-------------------

http://mp.weixin.qq.com/s?__biz=MzAwMjQ5NjM0Ng==&mid=205245348&idx=2&sn=e335139f3f69b899afc1b2ca5e63d24c&3rd=MzA3MDU4NTYzMw==&scene=6#rd

昨日（5月27日）下午17時許，支付寶被多網友反映故障，18時許，支付寶通過微博給出迴應，坦承系統故障，並做出解釋原因為光纜被挖。19時許，支付寶服務恢復正常。

而事實上，支付寶服務恢復正常之後，事故的罪魁禍首——被挖斷的光纜，還並沒有被還原。對此次事故的做出快速響應並幫助解除的正是——異地多活系統。

那麼，阿里的異地多活到底有那些優勢？專案又是如何部署？成功部署一個異地多活專案需要攻克的堡壘又有哪些？如果阿里的異地多活其他公司對異地多活又是如何部署的？本文將從回顧InfoQ對阿里異地多活專案主導者畢玄的專訪，及新浪微博劉道儒對微博的“異地多活”經驗談中一起尋找答案。

異地多活是什麼

所謂異地多活，故名思義，就是在不同地點的資料中心起多個我們的交易，並且每個地點的那個交易都是用來支撐流量的。

異地多活是如何部署的

首先來看看阿里對於為什麼做這件事兒，畢玄做出的回答：

其實我們大概在2009還是2010年左右的時候，就開始嘗試在異地去做一個數據中心，把我們的業務放過去。更早之前，我們做過同城，就是在同一個城市建多個數據中心，應用部署在多個數據中心裡面。同城的好處就是，如果同城的任何一個機房掛掉了，另外一個機房都可以接管。

做到這個以後，我們就在想，異地是不是也能做到這樣？

整個業界傳統的做法，異地是用來做一個冷備份的，等這邊另外一個城市全部掛掉了，才會切過去。我們當時也是按照這個方式去嘗試的，嘗試了一年左右，我們覺得冷備的方向對我們來講有兩個問題：第一個問題是成本太高。我們需要備份全站，而整個阿里巴巴網站，包括淘寶、天貓、聚划算等等，所有加起來，是一個非常大的量，備份成本非常高。第二個問題是，冷備並不是一直在跑流量的，所以有個問題，一旦真的出問題了，未必敢切過去。因為不知道切過去到底能不能起來，而且整個冷備恢復起來要花多長時間，也不敢保證。因此在嘗試之後，我們發現這個方向對我們而言並不好。

那為什麼我們最後下定決心去做異地多活呢？

最關鍵的原因是，我們在2013年左右碰到了幾個問題。首先，阿里巴巴的機房不僅僅給電商用，我們有電商，有物流，有云，有大資料，所有業務共用機房。隨著各種業務規模的不斷增長，單個城市可能很難容納下我們，所以我們面臨的問題是，一定需要去不同的城市建設我們的資料中心。其次是我們的伸縮規模的問題。整個淘寶的量，交易量不斷攀升，每年的雙十一大家都看到了，增長非常快。而我們的架構更多還是在2009年以前確定的一套架構，要不斷的加機器，這套架構會面臨風險。

如果能夠做到異地部署，就可以把伸縮規模縮小。雖然原來就是一套巨大的分散式應用，但是其實可以認為是一個叢集，然後不斷的加機器。但是在這種情況下，隨著不斷加機器，最終在整個分散式體系中，一定會有一個點是會出現風險的，會再次到達瓶頸，那時就無法解決了。

這兩個問題讓我們下定決心去做異地多活這個專案。

為什麼我們之前那麼糾結呢？因為整個業界還沒有可供參考的異地多活實現，這就意味著我們必須完全靠自己摸索。而且相對來講，它的風險以及週期可能也是比較大的。

關於專案的具體部署，畢玄說：

以去年雙十一為例，當時我們在杭州有一個數據中心，在另外一個城市還有個資料中心，一共是兩個，分別承擔50%使用者的流量。就是有50%的使用者會進入杭州，另外50%會進入到另外一個城市。當用戶進入以後，比如說在淘寶上看商品，瀏覽商品，搜尋、下單、放進購物車等等操作，還包括寫資料庫，就都是在所進入的那個資料中心中完成的，而不需要跨資料中心。

優勢

異地部署，從整個業界的做法上來講，主要有幾家公司，比如Google、Facebook，這兩家是比較典型的，Google做到了全球多個數據中心，都是多活的。但是Google具體怎麼做的，也沒有多少人瞭解。另外一家就是Facebook，我們相對更瞭解一些，Facebook在做多個數據中心時，比如說美國和歐洲兩個資料中心，確實都在支撐流量。但是歐洲的使用者有可能需要訪問美國的資料中心，當出現這種狀況時，整個使用者體驗不是很好。

國內的情況，我們知道的像銀行，還有其他一些行業，傾向於做異地災備。銀行一般都會有兩地，一個地方是熱點，另一個地方是冷備。當遇到故障時，就沒有辦法做出決定，到底要不要切到災備資料中心，他們會碰到我們以前摸索時所面對的問題，就是不確定切換過程到底要多久，災備中心到底多久才能把流量接管起來。而且接管以後，整個功能是不是都正常，也可能無法確定。

剛才也提到過，冷備的話，我們要備份全站，成本是非常高的。

如果每個地點都是活的，這些資料中心就可以實時承擔流量，任何一點出問題，都可以直接切掉，由另外一點直接接管。相對冷備而言，這是一套可以執行的模式，而且風險非常低。

挑戰

對於我們來講，異地專案最大的挑戰是延時。跨城市一定會有延時的問題。在中國範圍內，延時可能在一百毫秒以內。

看起來單次好像沒什麼，但是像淘寶是個很大的分散式系統，一次頁面的展現，背後的互動次數可能在一兩百次。如果這一兩百次全部是跨城市做的，整個響應時間會增加很多，所以延時帶來的挑戰非常大。

在解決挑戰的過程中，我們會面臨更細節的一些問題。怎樣降低延時的影響，我們能想到的最簡單、最好的辦法，就是讓操作全部在同一機房內完成，那就不存在延時的挑戰了。所以最關鍵的問題，就是怎樣讓所有操作在一個機房內完成。這就是單元化。

為什麼叫單元化，而沒有叫其他名字呢？原因在於，要在異地部署我們的網站，首先要做一個決定。比如說，冷備是把整個站全部備過去，這樣可以確保可以全部接管。但是多活的情況下，要考慮成本，所以不能部署全站。

整個淘寶的業務非常豐富，其實有很多非交易型別的應用，這些功能可能大家平時用的不算很多。但對我們來講，又是不能缺失的。這部分流量可能相對很小。如果這些應用也全國到處部署，冗餘量就太大了。所以我們需要在異地部署的是流量會爆發式增長的，流量很大的那部分。雖然有冗餘，但是因為流量會爆發式增長，成本比較好平衡。異地部署，我們要在成本之間找到一個平衡點。所以我們決定在異地只部署跟買家交易相關的核心業務，確保一個買家在淘寶上瀏覽商品，一直到買完東西的全過程都可以完成。

其他一些功能就會缺失，所以我們在異地部署的並非全站，而是一組業務，這組業務就成為單元。比如說我們現在做的就是交易單元。

這時淘寶會面臨一個比Google、Facebook等公司更大的一個挑戰。像Facebook目前做的全球化資料中心，因為Facebook更多的是使用者和使用者之間發訊息，屬於社交領域。但淘寶是電商領域，對資料的一致性要求非常高，延時要求也非常高。

還有個更大的挑戰，那就是淘寶的資料。如果要把使用者操作封閉在一個單元內完成，最關鍵的是資料。跟冷備相比，異地多活最大的風險在於，它的資料會同時在多個地方寫，冷備則不存在資料會寫錯的問題。如果多個地方在寫同一行資料，那就沒有辦法判斷哪條資料是正確的。在某個點，必須確保單行的資料在一個地方寫，絕對不能在多個地方寫。

為了做到這一點，必須確定資料的維度。如果資料只有一個維度，就像Facebook的資料，可以認為只有一個緯度，就是使用者。但是像淘寶，如果要在淘寶上買一個東西，除了使用者本身的資訊以外，還會看到所有商品的資料、所有賣家的資料，面對的是買家、賣家和商品三個維度。這時就必須做出一個選擇，到底用哪個維度作為我們唯一的一個封閉的維度。

單元化時，走向異地的就是買家的核心鏈路，所以我們選擇了買家這個維度。但是這樣自然會帶來一個問題，因為我們有三個維度的資料，當操作賣家商品資料時，就無法封閉了，因為這時一定會出現需要集中到一個點去寫的現象。

從我們的角度看，目前實現整個單元化專案最大的幾個難點是：

第一個是路由的一致性。因為我們是按買家維度來切分資料的，就是資料會封閉在不同的單元裡。這時就要確保，這個買家相關的資料在寫的時候，一定是要寫在那個單元裡，而不能在另外一個單元，否則就會出現同一行資料在兩個地方寫的現象。所以這時一定要保證，一個使用者進到淘寶，要通過一個路由規則來決定這個使用者去哪裡。這個使用者進來以後，到了前端的一組Web頁面，而Web頁面背後還要訪問很多後端服務，服務又要訪問資料庫，所以最關鍵的是要保障這個使用者從進來一直到訪問服務，到訪問資料庫，全鏈路的路由規則都是完全一致的。如果說某個使用者本來應該進A城市的資料中心，但是卻因為路由錯誤，進入了B城市，那看到的資料就是錯的了。造成的結果，可能是使用者看到的購買列表是空的，這是不能接受的。所以如何保障路由的一致性，非常關鍵。

第二個是挑戰是資料的延時問題。因為是異地部署，我們需要同步賣家的資料、商品的資料。如果同步的延時太長，就會影響使用者體驗。我們能接受的範圍是有限的，如果是10秒、30秒，使用者就會感知到。比如說賣家改了一個價格，改了一個庫存，而使用者隔了很久才看到，這對買家和賣家都是傷害。所以我們能接受的延時必須要做到一秒內，即在全國的範圍內，都必須做到一秒內把資料同步完。當時所有的開源方案，或者公開的方案，包括MySQL自己的主備等，其實都不可能做到一秒內，所以資料延時是我們當時面臨的第二個挑戰。

第三個挑戰，在所有的異地專案中，雖然冷備成本很高，多活可以降低成本，但是為什麼大家更喜歡冷備，而不喜歡多活呢？因為資料的正確性很難保證。資料在多點同時寫的時候，一定不能寫錯。因為資料故障跟業務故障還不一樣，跟應用層故障不一樣。如果應用出故障了，可能就是使用者不能訪問。但是如果資料寫錯了，對使用者來說，就徹底亂了。而且這個故障是無法恢復的，因為無法確定到底那裡寫的才是對的。所以在所有的異地多活專案中，最重要的是保障某個點寫進去的資料一定是正確的。這是最大的挑戰，也是我們在設計整個方案中的第一原則。業務這一層出故障我們都可以接受，但是不能接受資料故障。

還有一個挑戰是資料的一致性。多個單元之間一定會有資料同步。一方面，每個單元都需要賣家的資料、商品的資料；另一方面，我們的單元不是全量業務，那一定會有業務需要這個單元，比如說買家在這個單元下了一筆定單，而其他業務有可能也是需要這筆資料，否則可能操作不了，所以需要同步該資料。所以怎樣確保每個單元之間的商品、賣家的資料是一致的，然後買家資料中心和單元是一致的，這是非常關鍵的。

這幾個挑戰可能是整個異地多活專案中最複雜的。另外還有一點，淘寶目前還是一個高速發展的業務，在這樣的過程中，去做一次比較純技術的改造，怎樣確保對業務的影響最小，也是一個挑戰。

解決方案

同樣對於異地多活有時間的微博，在與阿里的解決方案進行對比後，也給出了關於解決方案的思考方向，一下是新浪微博劉道儒對於方案選型是需要進行的維度思考給出的方向：

能否整業務遷移：如果機器資源不足，建議優先將一些體系獨立的服務整體遷移，這樣可以為核心服務節省出大量的機架資源。如果這樣之後，機架資源仍然不足，再做異地多活部署。

服務關聯是否複雜：如果服務關聯比較簡單，則單元化、基於跨機房訊息同步的解決方案都可以採用。不管哪種方式，關聯的服務也都要做異地多活部署，以確保各個機房對關聯業務的請求都落在本機房內。

是否方便對使用者分割槽：比如很多遊戲類、郵箱類服務，由於使用者可以很方便地分割槽，就非常適合單元化，而SNS類的產品因為關係公用等問題不太適合單元化。

謹慎挑選第二機房：儘量挑選離主機房較近（網路延時在10ms以內）且專線質量好的機房做第二中心。這樣大多數的小服務依賴問題都可以簡化掉，可以集中精力處理核心業務的異地多活問題。同時，專線的成本佔比也比較小。以北京為例，做異地多活建議選擇天津、內蒙古、山西等地的機房。

控制部署規模：在資料層自身支援跨機房服務之前，不建議部署超過兩個的機房。因為異地兩個機房，異地容災的目的已經達成，且伺服器規模足夠大，各種配套的設施也會比較健全，運維成本也相對可控。當擴充套件到三個點之後，新機房基礎設施磨合、運維決策的成本等都會大幅增加。

訊息同步服務化：建議擴充套件各自的訊息服務，從中介軟體或者服務層面直接支援跨機房訊息同步，將訊息體大小控制在10k以下，跨機房訊息同步的效能和成本都比較可控。機房間的資料一致性只通過訊息同步服務解決，機房內部解決快取等與訊息的一致性問題。跨機房訊息同步的核心點在於訊息不能丟，微博由於使用的是MCQ，通過本地寫遠端讀的方式，可以很方便的實現高效穩定的跨機房訊息同步。

--------------------- 本文來自 mylibrary1 的CSDN 部落格 ，全文地址請點選：https://blog.csdn.net/u013793650/article/details/49358507?utm_source=copy