其實大部分問題我們之前也遇到過，這些問題當時也困擾著我們，後來我們經過討論和思考，發現其實很多時候我們困擾的主要原因是過於“追求完美的異地多活方案”，這樣導致“異地多活”設計中出現很多了的思維誤區，而如果不意識到這些思維誤區，就會陷入死衚衕，導致無法實現真正的“異地多活”方案。

接下來我將總結常見的思維誤區，看看你踩中了哪個坑？

“異地多活”是為了保證業務的高可用，但很多朋友在考慮這個“業務”的時候，會不自覺的陷入一個思維誤區：我要保證所有業務的“異地多活”！

比如說假設我們需要做一個“使用者子系統”，這個子系統負責“註冊”、“登入”、“使用者資訊”三個業務。為了支援海量使用者，我們設計了一個“使用者分割槽”的架構，即：正常情況下使用者屬於某個主分割槽，每個分割槽都有其它資料的備份，使用者用郵箱或者手機號註冊，路由層拿到郵箱或者手機號後，通過hash計算屬於哪個中心，然後請求對應的業務中心。基本的架構如下：

考慮這樣一個系統，如果3個業務要同時實現異地多活，我們會發現如下一些難以解決的問題：

註冊

A中心註冊了使用者，資料還未同步到B中心，此時A中心宕機，為了支援註冊業務多活，那我們可以挑選B中心讓使用者去重新註冊。看起來很容易就支援多活了，但仔細思考一下會發現這樣做會有問題：一個手機號只能註冊一個賬號，A中心的資料沒有同步過來，B中心無法判斷這個手機號是否重複，如果B中心讓使用者註冊，後來A中心恢復了，發現數據有衝突，怎麼解決？

實際上是無法解決的，因為註冊賬號不能說挑選最後一個生效；而如果B中心不支援本來屬於A中心的業務進行註冊，註冊業務的雙活又成了空談。

有的朋友可能會說：那我修改業務規則，允許一個手機號註冊多個賬號不就可以了麼？

這樣做是不可行的，類似一個手機號只能註冊一個賬號這種規則，是核心業務規則，修改核心業務規則的代價非常大，幾乎所有的業務都要重新設計，為了架構設計去改變業務規則，而且是這麼核心的業務規則是得不償失的。

使用者資訊

使用者資訊的修改和註冊有類似的問題，即：A、B兩個中心在異常的情況下都修改了使用者資訊，如何處理衝突？

由於使用者資訊並沒有賬號那麼關鍵，一種簡單的處理方式是按照時間合併，即：最後修改的生效。業務邏輯上沒問題，但實際操作也有一個很關鍵的坑：怎麼保證多箇中心所有機器時間絕對一致？在異地多中心的網路下，這個是無法保證的，即使有時間同步也無法完全保證，只要兩個中心的時間誤差超過1s，資料就可能出現混亂，即：先修改的反而生效。

還有一種方式是生成全域性唯一遞增ID，這個方案的成本很高，因為這個全域性唯一遞增ID的系統本身又要考慮異地多活，同樣涉及資料一致性和衝突的問題。

綜合上面的簡單分析，我們可以發現，如果“註冊”“登入”、“使用者資訊”全部都要支援異地多活的話，實際上是挺難的，有的問題甚至是無解的。那這種情況下我們應該如何考慮“異地多活”的方案設計呢？答案其實很簡單：優先實現核心業務的異地多活方案！

對於我們的這個模擬案例來說，“登入”才是最核心的業務，“註冊”和“使用者資訊”雖然也是主要業務，但並不一定要實現異地多活。主要原因在於業務影響。對於一個日活1000萬的業務來說，每天註冊使用者可能是幾萬，修改使用者資訊的可能還不到1萬，但登入使用者是1000萬，很明顯我們應該保證登入的異地多活。

對於新使用者來說，註冊不了影響並不很明顯，因為他還沒有真正開始業務；使用者資訊修改也類似，使用者暫時修改不了使用者資訊，對於其業務不會有很大影響，而如果有幾百萬使用者登入不了，就相當於幾百萬使用者無法使用業務，對業務的影響就非常大了：公司的客服熱線很快就被打爆了，微博微信上到處都在傳業務宕機，論壇裡面到處是在罵孃的使用者，那就是網際網路大事件了！

而登入實現“異地多活”恰恰是最簡單的，因為每個中心都有所有使用者的賬號和密碼資訊，使用者在哪個中心都可以登入。使用者在A中心登入，A中心宕機後，使用者到B中心重新登入即可。

有的朋友可能會問，如果某個使用者在A中心修改了密碼，此時資料還沒有同步到B中心，使用者到B中心登入是無法登入的，這個怎麼處理？這個問題其實就涉及另外一個思維誤區了，我們稍後再談。

異地多活本質上是通過異地的資料冗餘，來保證在極端異常的情況下業務也能夠正常提供給使用者，因此資料同步是異地多活設計方案的核心，但我們大部分人在考慮資料同步方案的時候，也會不知不覺的陷入完美主義誤區：我要所有資料都實時同步！

資料冗餘就要將資料從A地同步到B地，從業務的角度來看是越快越好，最好和本地機房一樣的速度最好，但讓人頭疼的問題正在這裡：異地多活理論上就不可能很快，因為這是物理定律決定的，即：光速真空傳播是每秒30萬公里，在光纖中傳輸的速度大約是每秒20萬公里，再加上傳輸中的各種網路裝置的處理，實際還遠遠達不到光速的速度。

除了距離上的限制外，中間傳輸各種不可控的因素也非常多，例如挖掘機把光纖挖斷，中美海底電纜被拖船扯斷、骨幹網故障等，這些故障是第三方維護，我們根本無能為力也無法預知。例如廣州機房到北京機房，正常情況下RTT大約是50ms左右，遇到網路波動之類的情況，RTT可能飆升到500ms甚至1s，更不用說經常發生的線路丟包問題，那延遲可能就是幾秒幾十秒了。

因此異地多活方案面臨一個無法徹底解決的矛盾：業務上要求資料快速同步，物理上正好做不到資料快速同步，因此所有資料都實時同步，實際上是一個無法達到的目標。

既然是無法徹底解決的矛盾，那就只能想辦法儘量減少影響。有幾種方法可以參考：

1. 儘量減少異地多活機房的距離，搭建高速網路；

2. 儘量減少資料同步；

3. 保證最終一致性，不保證實時一致性；

減少距離：同城多中心

為了減少兩個業務中心的距離，選擇在同一個城市不同的區搭建機房，機房間通過高速網路連通，例如在北京的海定區和通州區各搭建一個機房，兩個機房間採用高速光纖網路連通，能夠達到近似在一個機房的效能。

這個方案的優勢在於對業務幾乎沒有影響，業務可以無縫的切換到同城多中心方案；缺點就是無法應對例如新奧爾良全城被水淹，或者2003美加大停電這種極端情況。所以即使採用這種方案，也還必須有一個其它城市的業務中心作為備份，最終的方案同樣還是要考慮遠距離的資料傳輸問題。

減少資料同步

另外一種方式就是減少需要同步的資料。簡單來說就是不重要的資料不要同步，同步後沒用的資料不同步。

以前面的“使用者子系統”為例，使用者登入所產生的token或者session資訊，資料量很大，但其實並不需要同步到其它業務中心，因為這些資料丟失後重新登入就可以了。

有的朋友會問：這些資料丟失後要求使用者重新登入，影響使用者體驗的呀！

確實如此，畢竟需要使用者重新輸入賬戶和密碼資訊，或者至少要彈出登入介面讓使用者點選一次，但相比為了同步所有資料帶來的代價，這個影響完全可以接受，其實這個問題也涉及了一個異地多活設計的典型思維誤區，後面我們會詳細講到。

保證最終一致性

第三種方式就是業務不依賴資料同步的實時性，只要資料最終能一致即可。例如：A機房註冊了一個使用者，業務上不要求能夠在50ms內就同步到所有機房，正常情況下要求5分鐘同步到所有機房即可，異常情況下甚至可以允許1小時或者1天后能夠一致。

最終一致性在具體實現的時候，還需要根據不同的資料特徵，進行差異化的處理，以滿足業務需要。例如對“賬號”資訊來說，如果在A機房新註冊的使用者5分鐘內正好跑到B機房了，此時B機房還沒有這個使用者的資訊，為了保證業務的正確，B機房就需要根據路由規則到A機房請求資料（這種處理方式其實就是後面講的“二次讀取”）。

而對“使用者資訊”來說，5分鐘後同步也沒有問題，也不需要採取其它措施來彌補，但還是會影響使用者體驗，即使用者看到了舊的使用者資訊，這個問題怎麼解決呢？這個問題實際上也涉及到了一個思維誤區，在最後我們統一分析。

資料同步是異地多活方案設計的核心，幸運的是基本上儲存系統本身都會有同步的功能，例如MySQL的主備複製、Redis的Cluster功能、elasticsearch的叢集功能。這些系統本身的同步功能已經比較強大，能夠直接拿來就用，但這也無形中將我們引入了一個思維誤區：只使用儲存系統的同步功能！

既然說儲存系統本身就有同步功能，而且同步功能還很強大，為何說只使用儲存系統是一個思維誤區呢？因為雖然絕大部分場景下，儲存系統本身的同步功能基本上也夠用了，但在某些比較極端的情況下，儲存系統本身的同步功能可能難以滿足業務需求。

以MySQL為例，MySQL5.1版本的複製是單執行緒的複製，在網路抖動或者大量資料同步的時候，經常發生延遲較長的問題，短則延遲十幾秒，長則可能達到十幾分鍾。而且即使我們通過監控的手段知道了MySQL同步時延較長，也難以採取什麼措施，只能乾等。

Redis又是另外一個問題，Redis 3.0之前沒有Cluster功能，只有主從複製功能，而為了設計上的簡單，Redis主從複製有一個比較大的隱患：從機宕機或者和主機斷開連線都需要重新連線主機，重新連線主機都會觸發全量的主從複製，這時候主機會生成記憶體快照，主機依然可以對外提供服務，但是作為讀的從機，就無法提供對外服務了，如果資料量大，恢復的時間會相當的長。

綜合上述的案例可以看出，儲存系統本身自帶的同步功能，在某些場景下是無法滿足我們業務需要的。尤其是異地多機房這種部署，各種各樣的異常都可能出現，當我們只考慮儲存系統本身的同步功能時，就會發現無法做到真正的異地多活。

解決的方案就是拓開思路，避免只使用儲存系統的同步功能，可以將多種手段配合儲存系統的同步來使用，甚至可以不採用儲存系統的同步方案，改用自己的同步方案。

例如，還是以前面的“使用者子系統”為例，我們可以採用如下幾種方式同步資料：

1. 訊息佇列方式：對於賬號資料，由於賬號只會建立，不會修改和刪除（假設我們不提供刪除功能），我們可以將賬號資料通過訊息佇列同步到其它業務中心。

2. 二次讀取方式：某些情況下可能出現訊息佇列同步也延遲了，使用者在A中心註冊，然後訪問B中心的業務，此時B中心本地拿不到使用者的賬號資料。為了解決這個問題，B中心在讀取本地資料失敗的時候，可以根據路由規則，再去A中心訪問一次（這就是所謂的二次讀取，第一次讀取本地，本地失敗後第二次讀取對端），這樣就能夠解決異常情況下同步延遲的問題。

3. 儲存系統同步方式：對於密碼資料，由於使用者改密碼頻率較低，而且使用者不可能在1s內連續改多次密碼，所以通過資料庫的同步機制將資料複製到其它業務中心即可，使用者資訊資料和密碼類似。

4. 回源讀取方式：對於登入的session資料，由於資料量很大，我們可以不同步資料；但當用戶在A中心登入後，然後又在B中心登入，B中心拿到使用者上傳的session id後，根據路由判斷session屬於A中心，直接去A中心請求session資料即可，反之亦然，A中心也可以到B中心去拿取session資料。

5. 重新生成資料方式：對於第4中場景，如果異常情況下，A中心宕機了，B中心請求session資料失敗，此時就只能登入失敗，讓使用者重新在B中心登入，生成新的session資料。

（注意：以上方案僅僅是示意，實際的設計方案要比這個複雜一些，還有很多細節要考慮）

綜合上述的各種措施，最後我們的“使用者子系統”同步方式整體如下：

前面我們在給出每個思維誤區對應的解決方案的時候，其實都遺留了一些小尾巴：某些場景下我們無法保證100%的業務可用性，總是會有一定的損失。例如密碼不同步導致無法登入、使用者資訊不同步導致使用者看到舊的使用者資訊等等，這個問題怎麼解決？

其實這個問題涉及異地多活設計方案中一個典型的思維誤區：我要保證業務100%可用！但極端情況下就是會丟一部分資料，就是會有一部分資料不能同步，怎麼辦呢，有沒有什麼巧妙和神通的辦法能做到？

很遺憾，答案是沒有！異地多活也無法保證100%的業務可用，這是由物理規律決定的，光速和網路的傳播速度、硬碟的讀寫速度、極端異常情況的不可控等，都是無法100%解決的。所以針對這個思維誤區，我的答案是“忍”！也就是說我們要忍受這一小部分使用者或者業務上的損失，否則本來想為了保證最後的0.01%的使用者的可用性，做個完美方案，結果卻發現99.99%的使用者都保證不了了。

對於某些實時強一致性的業務，實際上受影響的使用者會更多，甚至可能達到1/3的使用者。以銀行轉賬這個業務為例，假設小明在北京XX銀行開了賬號，如果小明要轉賬，一定要北京的銀行業務中心是可用的，否則就不允許小明自己轉賬。

如果不這樣的話，假設在北京和上海兩個業務中心實現了實時轉賬的異地多活，某些異常情況下就可能出現小明只有1萬存款，他在北京轉給了張三1萬，然後又到上海轉給了李四1萬，兩次轉賬都成功了。這種漏洞如果被人利用，後果不堪設想。

當然，針對銀行轉賬這個業務，可以有很多特殊的業務手段來實現異地多活。例如分為“實時轉賬”和“轉賬申請”。

實時轉賬就是我們上述的案例，是無法做到“異地多活”的；但“轉賬申請”是可以做到“異地多活”的，即：小明在上海業務中心提交轉賬請求，但上海的業務中心並不立即轉賬，而是記錄這個轉賬請求，然後後臺非同步發起真正的轉賬操作，如果此時北京業務中心不可用，轉賬請求就可以繼續等待重試；假設等待2個小時後北京業務中心恢復了，此時上海業務中心去請求轉賬，發現餘額不夠，這個轉賬請求就失敗了。

小明再登入上來就會看到轉賬申請失敗，原因是“餘額不足”。不過需要注意的是“轉賬申請”的這種方式雖然有助於實現異地多活，但其實還是犧牲了使用者體驗的，對於小明來說，本來一次操作的事情，需要分為兩次：一次提交轉賬申請，另外一次要確認是否轉賬成功。

雖然我們無法做到100%可用性，但並不意味著我們什麼都不能做，為了讓使用者心裡更好受一些，我們可以採取一些措施進行安撫或者補償，例如：

1. 掛公告：說明現在有問題和基本的問題原因，如果不明確原因或者不方便說出原因，可以說“技術哥哥正在緊急處理”比較輕鬆和有趣的公告。

2. 事後對使用者進行補償：例如送一些業務上可用的代金券、小禮包等，降低使用者的抱怨。

3. 補充體驗：對於為了做異地多活而帶來的體驗損失，可以想一些方法減少或者規避。以“轉賬申請”為例，為了讓使用者不用確認轉賬申請是否成功，我們可以在轉賬成功或者失敗後直接給使用者發個簡訊，告訴他轉賬結果，這樣使用者就不用不時的登入系統來確認轉賬是否成功了。

綜合前面的分析，異地多活設計的理念可以總結為一句話：採用多種手段，保證絕大部分使用者的核心業務異地多活！