想要徹底搞懂“異地多活”，看完這篇就夠了
[導讀]在軟件開發(fā)領(lǐng)域，「異地多活」是分布式系統(tǒng)架構(gòu)設(shè)計的一座高峰，很多人經(jīng)常聽過它，但很少人理解其中的原理。異地多活到底是什么？為什么需要異地多活？它到底解決了什么問題？究竟是怎么解決的？這些疑問，想必是每個程序看到異地多活這個名詞時，都想要搞明白的問題。有幸，我曾經(jīng)深度參與過一個中等...
在軟件開發(fā)領(lǐng)域，「異地多活」是分布式系統(tǒng)架構(gòu)設(shè)計的一座高峰，很多人經(jīng)常聽過它，但很少人理解其中的原理。
異地多活到底是什么？為什么需要異地多活？它到底解決了什么問題？究竟是怎么解決的？這些疑問，想必是每個程序看到異地多活這個名詞時，都想要搞明白的問題。有幸，我曾經(jīng)深度參與過一個中等互聯(lián)網(wǎng)公司，建設(shè)異地多活系統(tǒng)的設(shè)計與實施過程。所以今天，我就來和你聊一聊異地多活背后的的實現(xiàn)原理。認真讀完這篇文章，我相信你會對異地多活架構(gòu)，有更加深刻的理解。這篇文章干貨很多，希望你可以耐心讀完。
2021 年 7 月 13 日，B 站部分服務器機房發(fā)生故障，造成整站持續(xù) 3 個小時無法訪問
2021 年 10 月 9 日，富途證券服務器機房發(fā)生電力閃斷故障，造成用戶 2 個小時無法登陸、交易
…可見，即使機房級別的防護已經(jīng)做得足夠好，但只要有「概率」出問題，那現(xiàn)實情況就有可能發(fā)生。雖然概率很小，但一旦真的發(fā)生，影響之大可見一斑。看到這里你可能會想，機房出現(xiàn)問題的概率也太小了吧，工作了這么多年，也沒讓我碰上一次，有必要考慮得這么復雜嗎？但你有沒有思考這樣一個問題：不同體量的系統(tǒng)，它們各自關(guān)注的重點是什么？體量很小的系統(tǒng)，它會重點關(guān)注「用戶」規(guī)模、增長，這個階段獲取用戶是一切。等用戶體量上來了，這個階段會重點關(guān)注「性能」，優(yōu)化接口響應時間、頁面打開速度等等，這個階段更多是關(guān)注用戶體驗。等體量再大到一定規(guī)模后你會發(fā)現(xiàn)，「可用性」就變得尤為重要。像微信、支付寶這種全民級的應用，如果機房發(fā)生一次故障，那整個影響范圍可以說是非常巨大的。所以，再小概率的風險，我們在提高系統(tǒng)可用性時，也不能忽視。分析了風險，再說回我們的架構(gòu)。那到底該怎么應對機房級別的故障呢？沒錯，還是冗余。
異地多活到底是什么？為什么需要異地多活？它到底解決了什么問題？究竟是怎么解決的？這些疑問，想必是每個程序看到異地多活這個名詞時，都想要搞明白的問題。有幸，我曾經(jīng)深度參與過一個中等互聯(lián)網(wǎng)公司，建設(shè)異地多活系統(tǒng)的設(shè)計與實施過程。所以今天，我就來和你聊一聊異地多活背后的的實現(xiàn)原理。認真讀完這篇文章，我相信你會對異地多活架構(gòu)，有更加深刻的理解。這篇文章干貨很多，希望你可以耐心讀完。
01 系統(tǒng)可用性
要想理解異地多活，我們需要從架構(gòu)設(shè)計的原則說起。現(xiàn)如今，我們開發(fā)一個軟件系統(tǒng)，對其要求越來越高，如果你了解一些「架構(gòu)設(shè)計」的要求，就知道一個好的軟件架構(gòu)應該遵循以下 3 個原則：- 高性能
- 高可用
- 易擴展
- 平均故障間隔 MTBF（Mean Time Between Failure）：表示兩次故障的間隔時間，也就是系統(tǒng)「正常運行」的平均時間，這個時間越長，說明系統(tǒng)穩(wěn)定性越高
- 故障恢復時間 MTTR（Mean Time To Repair）：表示系統(tǒng)發(fā)生故障后「恢復的時間」，這個值越小，故障對用戶的影響越小
可用性（Availability）= MTBF / (MTBF MTTR) * 100%這個公式得出的結(jié)果是一個「比例」，通常我們會用「N 個 9」來描述一個系統(tǒng)的可用性。從這張圖你可以看到，要想達到 4 個 9 以上的可用性，平均每天故障時間必須控制在 10 秒以內(nèi)。也就是說，只有故障的時間「越短」，整個系統(tǒng)的可用性才會越高，每提升 1 個 9，都會對系統(tǒng)提出更高的要求。我們都知道，系統(tǒng)發(fā)生故障其實是不可避免的，尤其是規(guī)模越大的系統(tǒng)，發(fā)生問題的概率也越大。這些故障一般體現(xiàn)在 3 個方面：
- 硬件故障：CPU、內(nèi)存、磁盤、網(wǎng)卡、交換機、路由器
- 軟件問題：代碼 Bug、版本迭代
- 不可抗力：地震、水災、火災、戰(zhàn)爭
02 單機架構(gòu)
我們從最簡單的開始講起。假設(shè)你的業(yè)務處于起步階段，體量非常小，那你的架構(gòu)是這樣的：這個架構(gòu)模型非常簡單，客戶端請求進來，業(yè)務應用讀寫數(shù)據(jù)庫，返回結(jié)果，非常好理解。但需要注意的是，這里的數(shù)據(jù)庫是「單機」部署的，所以它有一個致命的缺點：一旦遭遇意外，例如磁盤損壞、操作系統(tǒng)異常、誤刪數(shù)據(jù)，那這意味著所有數(shù)據(jù)就全部「丟失」了，這個損失是巨大的。如何避免這個問題呢？我們很容易想到一個方案：備份。你可以對數(shù)據(jù)做備份，把數(shù)據(jù)庫文件「定期」cp 到另一臺機器上，這樣，即使原機器丟失數(shù)據(jù)，你依舊可以通過備份把數(shù)據(jù)「恢復」回來，以此保證數(shù)據(jù)安全。這個方案實施起來雖然比較簡單，但存在 2 個問題：- 恢復需要時間：業(yè)務需先停機，再恢復數(shù)據(jù)，停機時間取決于恢復的速度，恢復期間服務「不可用」
- 數(shù)據(jù)不完整：因為是定期備份，數(shù)據(jù)肯定不是「最新」的，數(shù)據(jù)完整程度取決于備份的周期
03 主從副本
你可以在另一臺機器上，再部署一個數(shù)據(jù)庫實例，讓這個新實例成為原實例的「副本」，讓兩者保持「實時同步」，就像這樣：我們一般把原實例叫作主庫（master），新實例叫作從庫（slave）。這個方案的優(yōu)點在于：- 數(shù)據(jù)完整性高：主從副本實時同步，數(shù)據(jù)「差異」很小
- 抗故障能力提升：主庫有任何異常，從庫可隨時「切換」為主庫，繼續(xù)提供服務
- 讀性能提升：業(yè)務應用可直接讀從庫，分擔主庫「壓力」讀壓力
04 風險不可控
現(xiàn)在讓我們把視角下放，把焦點放到具體的「部署細節(jié)」上來。按照前面的分析，為了避免單點故障，你的應用雖然部署了多臺機器，但這些機器的分布情況，我們并沒有去深究。而一個機房有很多服務器，這些服務器通常會分布在一個個「機柜」上，如果你使用的這些機器，剛好在一個機柜，還是存在風險。如果恰好連接這個機柜的交換機 / 路由器發(fā)生故障，那么你的應用依舊有「不可用」的風險。雖然交換機 / 路由器也做了路線冗余，但不能保證一定不出問題。部署在一個機柜有風險，那把這些機器打散，分散到不同機柜上，是不是就沒問題了？這樣確實會大大降低出問題的概率。但我們依舊不能掉以輕心，因為無論怎么分散，它們總歸還是在一個相同的環(huán)境下：機房。那繼續(xù)追問，機房會不會發(fā)生故障呢？一般來講，建設(shè)一個機房的要求其實是很高的，地理位置、溫濕度控制、備用電源等等，機房廠商會在各方面做好防護。但即使這樣，我們每隔一段時間還會看到這樣的新聞：2015 年 5 月 27 日，杭州市某地光纖被挖斷，近 3 億用戶長達 5 小時無法訪問支付寶
2021 年 7 月 13 日，B 站部分服務器機房發(fā)生故障，造成整站持續(xù) 3 個小時無法訪問
2021 年 10 月 9 日，富途證券服務器機房發(fā)生電力閃斷故障，造成用戶 2 個小時無法登陸、交易
…可見，即使機房級別的防護已經(jīng)做得足夠好，但只要有「概率」出問題，那現(xiàn)實情況就有可能發(fā)生。雖然概率很小，但一旦真的發(fā)生，影響之大可見一斑。看到這里你可能會想，機房出現(xiàn)問題的概率也太小了吧，工作了這么多年，也沒讓我碰上一次，有必要考慮得這么復雜嗎？但你有沒有思考這樣一個問題：不同體量的系統(tǒng)，它們各自關(guān)注的重點是什么？體量很小的系統(tǒng)，它會重點關(guān)注「用戶」規(guī)模、增長，這個階段獲取用戶是一切。等用戶體量上來了，這個階段會重點關(guān)注「性能」，優(yōu)化接口響應時間、頁面打開速度等等，這個階段更多是關(guān)注用戶體驗。等體量再大到一定規(guī)模后你會發(fā)現(xiàn)，「可用性」就變得尤為重要。像微信、支付寶這種全民級的應用，如果機房發(fā)生一次故障，那整個影響范圍可以說是非常巨大的。所以，再小概率的風險，我們在提高系統(tǒng)可用性時，也不能忽視。分析了風險，再說回我們的架構(gòu)。那到底該怎么應對機房級別的故障呢？沒錯，還是冗余。
05 同城災備
想要抵御「機房」級別的風險，那應對方案就不能局限在一個機房內(nèi)了。現(xiàn)在，你需要做機房級別的冗余方案，也就是說，你需要再搭建一個機房，來部署你的服務。簡單起見，你可以在「同一個城市」再搭建一個機房，原機房我們叫作 A 機房，新機房叫 B 機房，這兩個機房的網(wǎng)絡(luò)用一條「專線」連通。有了新機房，怎么把它用起來呢？這里還是要優(yōu)先考慮「數(shù)據(jù)」風險。為了避免 A 機房故障導致數(shù)據(jù)丟失，所以我們需要把數(shù)據(jù)在 B 機房也存一份。最簡單的方案還是和前面提到的一樣：備份。A 機房的數(shù)據(jù)，定時在 B 機房做備份（拷貝數(shù)據(jù)文件），這樣即使整個 A 機房遭到嚴重的損壞，B 機房的數(shù)據(jù)不會丟，通過備份可以把數(shù)據(jù)「恢復」回來，重啟服務。這種方案，我們稱之為「冷備」。為什么叫冷備呢？因為 B 機房只做備份，不提供實時服務，它是冷的，只會在 A 機房故障時才會啟用。但備份的問題依舊和之前描述的一樣：數(shù)據(jù)不完整、恢復數(shù)據(jù)期間業(yè)務不可用，整個系統(tǒng)的可用性還是無法得到保證。所以，我們還是需要用「主從副本」的方式，在 B 機房部署 A 機房的數(shù)據(jù)副本，架構(gòu)就變成了這樣：這樣，就算整個 A 機房掛掉，我們在 B 機房也有比較「完整」的數(shù)據(jù)。數(shù)據(jù)是保住了，但這時你需要考慮另外一個問題：如果 A 機房真掛掉了，要想保證服務不中斷，你還需要在 B 機房「緊急」做這些事情：- B 機房所有從庫提升為主庫
- 在 B 機房部署應用，啟動服務
- 部署接入層，配置轉(zhuǎn)發(fā)規(guī)則
- DNS 指向 B 機房，接入流量，業(yè)務恢復
- B 機房所有從庫提升為主庫
- DNS 指向 B 機房，接入流量，業(yè)務恢復
06 同城雙活
我們繼續(xù)來看這個架構(gòu)。雖然我們有了應對機房故障的解決方案，但這里有個問題是我們不能忽視的：A 機房掛掉，全部流量切到 B 機房，B 機房能否真的如我們所愿，正常提供服務？這是個值得思考的問題。這就好比有兩支軍隊 A 和 B，A 軍隊歷經(jīng)沙場，作戰(zhàn)經(jīng)驗豐富，而 B 軍隊只是后備軍，除了有軍人的基本素養(yǎng)之外，并沒有實戰(zhàn)經(jīng)驗，戰(zhàn)斗經(jīng)驗基本為 0。如果 A 軍隊喪失戰(zhàn)斗能力，需要 B 軍隊立即頂上時，作為指揮官的你，肯定也會擔心 B 軍隊能否真的擔此重任吧？我們的架構(gòu)也是如此，此時的 B 機房雖然是隨時「待命」狀態(tài)，但 A 機房真的發(fā)生故障，我們要把全部流量切到 B 機房，其實是不敢百分百保證它可以「如期」工作的。你想，我們在一個機房內(nèi)部署服務，還總是發(fā)生各種各樣的問題，例如：發(fā)布應用的版本不一致、系統(tǒng)資源不足、操作系統(tǒng)參數(shù)不一樣等等?，F(xiàn)在多部署一個機房，這些問題只會增多，不會減少。另外，從「成本」的角度來看，我們新部署一個機房，需要購買服務器、內(nèi)存、硬盤、帶寬資源，花費成本也是非常高昂的，只讓它當一個后備軍，未免也太「大材小用」了！因此，我們需要讓 B 機房也接入流量，實時提供服務，這樣做的好處，一是可以實時訓練這支后備軍，讓它達到與 A 機房相同的作戰(zhàn)水平，隨時可切換，二是 B 機房接入流量后，可以分擔 A 機房的流量壓力。這才是把 B 機房資源優(yōu)勢，發(fā)揮最大化的最好方案！那怎么讓 B 機房也接入流量呢？很簡單，就是把 B 機房的接入層 IP 地址，加入到 DNS 中，這樣，B 機房從上層就可以有流量進來了。但這里有一個問題：別忘了，B 機房的存儲，現(xiàn)在可都是 A 機房的「從庫」，從庫默認可都是「不可寫」的，B 機房的寫請求打到本機房存儲上，肯定會報錯，這還是不符合我們預期。怎么辦？這時，你就需要在「業(yè)務應用」層做改造了。你的業(yè)務應用在操作數(shù)據(jù)庫時，需要區(qū)分「讀寫分離」（一般用中間件實現(xiàn)），即兩個機房的「讀」流量，可以讀任意機房的存儲，但「寫」流量，只允許寫 A 機房，因為主庫在 A 機房。這會涉及到你用的所有存儲，例如項目中用到了 MySQL、Redis、MongoDB 等等，操作這些數(shù)據(jù)庫，都需要區(qū)分讀寫請求，所以這塊需要一定的業(yè)務「改造」成本。因為 A 機房的存儲都是主庫，所以我們把 A 機房叫做「主機房」，B 機房叫「從機房」。兩個機房部署在「同城」，物理距離比較近，而且兩個機房用「專線」網(wǎng)絡(luò)連接，雖然跨機房訪問的延遲，比單個機房內(nèi)要大一些，但整體的延遲還是可以接受的。業(yè)務改造完成后，B 機房可以慢慢接入流量，從 10%、30%、50% 逐漸覆蓋到 100%，你可以持續(xù)觀察 B 機房的業(yè)務是否存在問題，有問題及時修復，逐漸讓 B 機房的工作能力，達到和 A 機房相同水平。現(xiàn)在，因為 B 機房實時接入了流量，此時如果 A 機房掛了，那我們就可以「大膽」地把 A 的流量，全部切換到 B 機房，完成快速切換！到這里你可以看到，我們部署的 B 機房，在物理上雖然與 A 有一定距離，但整個系統(tǒng)從「邏輯」上來看，我們是把這兩個機房看做一個「整體」來規(guī)劃的，也就是說，相當于把 2 個機房當作 1 個機房來用。這種架構(gòu)方案，比前面的同城災備更「進了一步」，B 機房實時接入了流量，還能應對隨時的故障切換，這種方案我們把它叫做「同城雙活」。因為兩個機房都能處理業(yè)務請求，這對我們系統(tǒng)的內(nèi)部維護、改造、升級提供了更多的可實施空間（流量隨時切換），現(xiàn)在，整個系統(tǒng)的彈性也變大了，是不是更爽了？那這種架構(gòu)有什么問題呢？07 兩地三中心
還是回到風險上來說。雖然我們把 2 個機房當做一個整體來規(guī)劃，但這 2 個機房在物理層面上，還是處于「一個城市」內(nèi)，如果是整個城市發(fā)生自然災害，例如地震、水災（河南水災剛過去不久），那 2 個機房依舊存在「全局覆沒」的風險。真是防不勝防??？怎么辦？沒辦法，繼續(xù)冗余。但這次冗余機房，就不能部署在同一個城市了，你需要把它放到距離更遠的地方，部署在「異地」。通常建議兩個機房的距離要在 1000 公里以上，這樣才能應對城市級別的災難。假設(shè)之前的 A、B 機房在北京，那這次新部署的 C 機房可以放在上海。按照前面的思路，把 C 機房用起來，最簡單粗暴的方案還就是做「冷備」，即定時把 A、B 機房的數(shù)據(jù)，在 C 機房做備份，防止數(shù)據(jù)丟失。這種方案，就是我們經(jīng)常聽到的「兩地三中心」。兩地是指 2 個城市，三中心是指有 3 個機房，其中 2 個機房在同一個城市，并且同時提供服務，第 3 個機房部署在異地，只做數(shù)據(jù)災備。這種架構(gòu)方案，通常用在銀行、金融、政企相關(guān)的項目中。它的問題還是前面所說的，啟用災備機房需要時間，而且啟用后的服務，不確定能否如期工作。所以，要想真正的抵御城市級別的故障，越來越多的互聯(lián)網(wǎng)公司，開始實施「異地雙活」。
08 偽異地雙活
這里，我們還是分析 2 個機房的架構(gòu)情況。我們不再把 A、B 機房部署在同一個城市，而是分開部署，例如 A 機房放在北京，B 機房放在上海。前面我們講了同城雙活，那異地雙活是不是直接「照搬」同城雙活的模式去部署就可以了呢？事情沒你想的那么簡單。如果還是按照同城雙活的架構(gòu)來部署，那異地雙活的架構(gòu)就是這樣的：注意看，兩個機房的網(wǎng)絡(luò)是通過「跨城專線」連通的。此時兩個機房都接入流量，那上海機房的請求，可能要去讀寫北京機房的存儲，這里存在一個很大的問題：網(wǎng)絡(luò)延遲。因為兩個機房距離較遠，受到物理距離的限制，現(xiàn)在，兩地之間的網(wǎng)絡(luò)延遲就變成了「不可忽視」的因素了。北京到上海的距離大約 1300 公里，即使架設(shè)一條高速的「網(wǎng)絡(luò)專線」，光纖以光速傳輸，一個來回也需要近 10ms 的延遲。況且，網(wǎng)絡(luò)線路之間還會經(jīng)歷各種路由器、交換機等網(wǎng)絡(luò)設(shè)備，實際延遲可能會達到 30ms ~ 100ms，如果網(wǎng)絡(luò)發(fā)生抖動，延遲甚至會達到 1 秒。不止是延遲，遠距離的網(wǎng)絡(luò)專線質(zhì)量，是遠遠達不到機房內(nèi)網(wǎng)絡(luò)質(zhì)量的，專線網(wǎng)絡(luò)經(jīng)常會發(fā)生延遲、丟包、甚至中斷的情況。總之，不能過度信任和依賴「跨城專線」。你可能會問，這點延遲對業(yè)務影響很大嗎？影響非常大！試想，一個客戶端請求打到上海機房，上海機房要去讀寫北京機房的存儲，一次跨機房訪問延遲就達到了 30ms，這大致是機房內(nèi)網(wǎng)網(wǎng)絡(luò)（0.5 ms）訪問速度的 60 倍（30ms / 0.5ms），一次請求慢 60 倍，來回往返就要慢 100 倍以上。而我們在 App 打開一個頁面，可能會訪問后端幾十個 API，每次都跨機房訪問，整個頁面的響應延遲有可能就達到了秒級，這個性能簡直慘不忍睹，難以接受。看到了么，雖然我們只是簡單的把機房部署在了「異地」，但「同城雙活」的架構(gòu)模型，在這里就不適用了，還是按照這種方式部署，這是「偽異地雙活」！那如何做到真正的異地雙活呢？
09 真正的異地雙活
既然「跨機房」調(diào)用延遲是不容忽視的因素，那我們只能盡量避免跨機房「調(diào)用」，規(guī)避這個延遲問題。也就是說，上海機房的應用，不能再「跨機房」去讀寫北京機房的存儲，只允許讀寫上海本地的存儲，實現(xiàn)「就近訪問」，這樣才能避免延遲問題。還是之前提到的問題：上海機房存儲都是從庫，不允許寫入啊，除非我們只允許上海機房接入「讀流量」，不接收「寫流量」，否則無法滿足不再跨機房的要求。很顯然，只讓上海機房接收讀流量的方案不現(xiàn)實，因為很少有項目是只有讀流量，沒有寫流量的。所以這種方案還是不行，這怎么辦？此時，你就必須在「存儲層」做改造了。要想上海機房讀寫本機房的存儲，那上海機房的存儲不能再是北京機房的從庫，而是也要變?yōu)椤钢鲙臁埂?/span>你沒看錯，兩個機房的存儲必須都是「主庫」，而且兩個機房的數(shù)據(jù)還要「互相同步」數(shù)據(jù)，即客戶端無論寫哪一個機房，都能把這條數(shù)據(jù)同步到另一個機房。因為只有兩個機房都擁有「全量數(shù)據(jù)」，才能支持任意切換機房，持續(xù)提供服務。怎么實現(xiàn)這種「雙主」架構(gòu)呢？它們之間如何互相同步數(shù)據(jù)？如果你對 MySQL 有所了解，MySQL 本身就提供了雙主架構(gòu)，它支持雙向復制數(shù)據(jù)，但平時用的并不多。而且 Redis、MongoDB 等數(shù)據(jù)庫并沒有提供這個功能，所以，你必須開發(fā)對應的「數(shù)據(jù)同步中間件」來實現(xiàn)雙向同步的功能。此外，除了數(shù)據(jù)庫這種有狀態(tài)的軟件之外，你的項目通常還會使用到消息隊列，例如 RabbitMQ、Kafka，這些也是有狀態(tài)的服務，所以它們也需要開發(fā)雙向同步的中間件，支持任意機房寫入數(shù)據(jù)，同步至另一個機房。看到了么，這一下子復雜度就上來了，單單針對每個數(shù)據(jù)庫、隊列開發(fā)同步中間件，就需要投入很大精力了。業(yè)界也開源出了很多數(shù)據(jù)同步中間件，例如阿里的 Canal、RedisShake、MongoShake，可分別在兩個機房同步 MySQL、Redis、MongoDB 數(shù)據(jù)。很多有能力的公司，也會采用自研同步中間件的方式來做，例如餓了么、攜程、美團都開發(fā)了自己的同步中間件。我也有幸參與設(shè)計開發(fā)了 MySQL、Redis/Codis、MongoDB 的同步中間件，有時間寫一篇文章詳細聊聊實現(xiàn)細節(jié)，歡迎持續(xù)關(guān)注。:)現(xiàn)在，整個架構(gòu)就變成了這樣：注意看，兩個機房的存儲層都互相同步數(shù)據(jù)的。有了數(shù)據(jù)同步中間件，就可以達到這樣的效果：
- 北京機房寫入 X = 1
- 上海機房寫入 Y = 2
- 數(shù)據(jù)通過中間件雙向同步
- 北京、上海機房都有 X = 1、Y = 2 的數(shù)據(jù)
- 用戶短時間內(nèi)發(fā)了 2 個修改請求，都是修改同一條數(shù)據(jù)
- 一個請求落在北京機房，修改 X = 1（還未同步到上海機房）
- 另一個請求落在上海機房，修改 X = 2（還未同步到北京機房）
- 兩個機房以哪個為準？
- 第 1 個請求落到北京機房，北京機房時鐘是 10:01，修改 X = 1
- 第 2 個請求落到上海機房，上海機房時鐘是 10:00，修改 X = 2
10 如何實施異地雙活
既然自動合并數(shù)據(jù)的方案實現(xiàn)成本高，那我們就要想，能否從源頭就「避免」數(shù)據(jù)沖突呢？這個思路非常棒！從源頭避免數(shù)據(jù)沖突的思路是：在最上層接入流量時，就不要讓沖突的情況發(fā)生。具體來講就是，要在最上層就把用戶「區(qū)分」開，部分用戶請求固定打到北京機房，其它用戶請求固定打到上海 機房，進入某個機房的用戶請求，之后的所有業(yè)務操作，都在這一個機房內(nèi)完成，從根源上避免「跨機房」。所以這時，你需要在接入層之上，再部署一個「路由層」（通常部署在云服務器上），自己可以配置路由規(guī)則，把用戶「分流」到不同的機房內(nèi)。但這個路由規(guī)則，具體怎么定呢？有很多種實現(xiàn)方式，最常見的我總結(jié)了 3 類：- 按業(yè)務類型分片
- 直接哈希分片
- 按地理位置分片
這里按業(yè)務類型在不同機房接入流量，還需要考慮多個應用之間的依賴關(guān)系，要盡可能的把完成「相關(guān)」業(yè)務的應用部署在同一個機房，避免跨機房調(diào)用。例如，訂單、支付服務有依賴關(guān)系，會產(chǎn)生互相調(diào)用，那這 2 個服務在 A 機房接入流量。社區(qū)、發(fā)帖服務有依賴關(guān)系，那這 2 個服務在 B 機房接入流量。2、直接哈希分片這種方案就是，最上層的路由層，會根據(jù)用戶 ID 計算「哈希」取模，然后從路由表中找到對應的機房，之后把請求轉(zhuǎn)發(fā)到指定機房內(nèi)。舉例：一共 200 個用戶，根據(jù)用戶 ID 計算哈希值，然后根據(jù)路由規(guī)則，把用戶 1 - 100 路由到北京機房，101 - 200 用戶路由到上海機房，這樣，就避免了同一個用戶修改同一條數(shù)據(jù)的情況發(fā)生。3、按地理位置分片這種方案，非常適合與地理位置密切相關(guān)的業(yè)務，例如打車、外賣服務就非常適合這種方案。拿外賣服務舉例，你要點外賣肯定是「就近」點餐，整個業(yè)務范圍相關(guān)的有商家、用戶、騎手，它們都是在相同的地理位置內(nèi)的。針對這種特征，就可以在最上層，按用戶的「地理位置」來做分片，分散到不同的機房。舉例：北京、河北地區(qū)的用戶點餐，請求只會打到北京機房，而上海、浙江地區(qū)的用戶，請求則只會打到上海機房。這樣的分片規(guī)則，也能避免數(shù)據(jù)沖突。
提醒：這 3 種常見的分片規(guī)則，第一次看不太好理解，建議配合圖多理解幾遍。搞懂這 3 個分片規(guī)則，你才能真正明白怎么做異地多活。總之，分片的核心思路在于，讓同一個用戶的相關(guān)請求，只在一個機房內(nèi)完成所有業(yè)務「閉環(huán)」，不再出現(xiàn)「跨機房」訪問。阿里在實施這種方案時，給它起了個名字，叫做「單元化」。
當然，最上層的路由層把用戶分片后，理論來說同一個用戶只會落在同一個機房內(nèi)，但不排除程序 Bug 導致用戶會在兩個機房「漂移」。安全起見，每個機房在寫存儲時，還需要有一套機制，能夠檢測「數(shù)據(jù)歸屬」，應用層操作存儲時，需要通過中間件來做「兜底」，避免不該寫本機房的情況發(fā)生。（篇幅限制，這里不展開講，理解思路即可）現(xiàn)在，兩個機房就可以都接收「讀寫」流量（做好分片的請求），底層存儲保持「雙向」同步，兩個機房都擁有全量數(shù)據(jù)，當任意機房故障時，另一個機房就可以「接管」全部流量，實現(xiàn)快速切換，簡直不要太爽。不僅如此，因為機房部署在異地，我們還可以更細化地「優(yōu)化」路由規(guī)則，讓用戶訪問就近的機房，這樣整個系統(tǒng)的性能也會大大提升。
這里還有一種情況，是無法做數(shù)據(jù)分片的：全局數(shù)據(jù)。例如系統(tǒng)配置、商品庫存這類需要強一致的數(shù)據(jù)，這類服務依舊只能采用寫主機房，讀從機房的方案，不做雙活。雙活的重點，是要優(yōu)先保證「核心」業(yè)務先實現(xiàn)雙活，并不是「全部」業(yè)務實現(xiàn)雙活。至此，我們才算實現(xiàn)了真正的「異地雙活」！
到這里你可以看出，完成這樣一套架構(gòu)，需要投入的成本是巨大的。路由規(guī)則、路由轉(zhuǎn)發(fā)、數(shù)據(jù)同步中間件、數(shù)據(jù)校驗兜底策略，不僅需要開發(fā)強大的中間件，同時還要業(yè)務配合改造（業(yè)務邊界劃分、依賴拆分）等一些列工作，沒有足夠的人力物力，這套架構(gòu)很難實施。
下載文檔
