當(dāng)時(shí)我們做跨地域部署的時(shí)候，其實(shí)是沒有做到完全的異地多活的描扯。
入口方面通過dns就近將流量轉(zhuǎn)往Slave機(jī)房，S只提供讀服務(wù)
前端接入層將寫流量轉(zhuǎn)回Master機(jī)房
主庫部署在M趟薄，通過MySQL主從同步將數(shù)據(jù)同步至S
這個(gè)方案的缺點(diǎn)是友多，主機(jī)房故障之后沒地方切溶浴。
如果機(jī)房故障，可以快速切到另外一個(gè)機(jī)房，需要保障多機(jī)房的數(shù)據(jù)是一致的渊跋。
保障數(shù)據(jù)一致性的方案禁灼，
- 數(shù)據(jù)雙向/多向同步
- 業(yè)務(wù)方雙份/多份寫
這里的數(shù)據(jù)包括MySQL中存儲(chǔ)的關(guān)系型數(shù)據(jù)昵仅、MFS/NFS上存儲(chǔ)的業(yè)務(wù)數(shù)據(jù)退渗、緩存數(shù)據(jù)、消息等犀勒。
業(yè)務(wù)方多份寫肯定不現(xiàn)實(shí)屎飘，平均響應(yīng)時(shí)間受不了的。
數(shù)據(jù)多向同步需要保證同一時(shí)刻只在一個(gè)地方寫贾费，不然沒法解決沖突钦购。在數(shù)據(jù)同步方面還有兩種場景，
- 用戶一個(gè)時(shí)刻只在同一個(gè)地方寫褂萧，但多個(gè)時(shí)刻可能寫在不同地方押桃，沖突后以最后一次寫入為正確值。在分布式系統(tǒng)遇到的挑戰(zhàn)是服務(wù)器時(shí)鐘的完全精確性导犹。這個(gè)基本是做不到的唱凯，線上的服務(wù)器是每半小時(shí)去ntp服務(wù)器同步一次時(shí)鐘羡忘，期間會(huì)有毫秒~秒之間的誤差，在這樣的背景下磕昼，基本沒法解決沖突的問題卷雕。
- 用戶平時(shí)只一個(gè)地方寫（路由規(guī)則），只有當(dāng)故障的時(shí)候票从，觸發(fā)路由規(guī)則的修改漫雕，將用戶的請(qǐng)求切到其他機(jī)房。技術(shù)點(diǎn)
- 業(yè)務(wù)上需要設(shè)置路由規(guī)則峰鄙，并且路由規(guī)則需要經(jīng)常變化浸间。我們一般的路由規(guī)則肯定是就近訪問，但用戶的地理位置是可能發(fā)生變化的吟榴。如果客戶在S訪問過魁蒜，之后來M城市定居，我們的路由規(guī)則需要感知到這種場景煤墙，并把用戶的流量轉(zhuǎn)到北京梅惯。
- 由于故障時(shí)還是需要切流量宪拥，所以多機(jī)房之間還是需要做數(shù)據(jù)同步的仿野。在數(shù)據(jù)同步延遲期間，發(fā)生故障她君，切流量脚作，可能存在臟數(shù)據(jù)的問題。
做核心系統(tǒng)的跨機(jī)房部署缔刹，不僅你的系統(tǒng)需要多地域部署球涛，你依賴的復(fù)雜的關(guān)聯(lián)系統(tǒng)都需要做多機(jī)房部署，并且都需要解決上述的路由問題和數(shù)據(jù)同步問題校镐。所以只是你的模塊跨地域部署難度是N亿扁，那將核心系統(tǒng)跨地域部署，難度是N*M鸟廓。
除了技術(shù)方面的難點(diǎn)从祝，還需要推動(dòng)和協(xié)調(diào)多個(gè)部門進(jìn)行部署、測試引谜、驗(yàn)證牍陌，并且會(huì)增加運(yùn)維的復(fù)雜度。要協(xié)調(diào)多個(gè)部門做這樣一個(gè)費(fèi)力不討好的事情员咽，一定要有一個(gè)非常明確/大的業(yè)務(wù)收益毒涧。
