建站
咨詢
售后
建站咨詢
新聞中心
前情提要：
專注于為中小企業(yè)提供網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)焦作免費做網(wǎng)站提供優(yōu)質(zhì)的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了成百上千企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。
《當年，我們是怎么平滑上云的?》一文中提到了上云的背景，將所有的系統(tǒng)，從一個機房，遷移到另一個機房。
如上圖：
- 遷移之前，系統(tǒng)部署在機房A(M6)內(nèi)，是單機房架構(gòu)。
- 遷移之后，系統(tǒng)部署在機房B(阿里云)內(nèi)，換了一個機房。
《當年，我們是怎么平滑上云的?》有三結(jié)論：
- 單機房架構(gòu)的核心是“全連接”;
- 機房遷移方案的設(shè)計目標是：平滑遷移，不停服務;可以分批遷移;隨時可以回滾;
- 想要平滑的實施機房遷移，臨時性的多機房架構(gòu)不可避免;
【4】核心問題四，臨時性多機房架構(gòu)如何實施?
如前文所述，如果將單機房“全連接”架構(gòu)復制到多機房，會有大量跨機房調(diào)用，極大增加請求時延，是業(yè)務無法接受的，要想降低這個時延，必須實施“同機房連接”。
多機房多活架構(gòu)，什么是理想狀態(tài)下的“同機房連接”?
如上圖所示，多機房多活架構(gòu)，最理想狀態(tài)下，除了異步數(shù)據(jù)同步跨機房通訊，其他所有通訊均為“同機房連接”：
- web連業(yè)務服務;
- 業(yè)務服務連基礎(chǔ)服務;
- 服務連數(shù)據(jù)庫，主庫寫，從庫讀，讀寫分離;
上述架構(gòu)，每個機房是一套獨立的系統(tǒng)，僅僅通過異步數(shù)據(jù)同步獲取全量數(shù)據(jù)，當發(fā)生機房故障時，將流量切到另一個機房，就能冗余“機房級”故障，實現(xiàn)高可用。
上述多機房架構(gòu)存在什么問題?
“異步數(shù)據(jù)同步”存在延時(例如：1min)，這個延時的存在，會使得兩個機房的數(shù)據(jù)不一致，從而導致嚴重的業(yè)務問題。
舉個例子，某一個時刻，用戶X有余額100元，兩個機房都存儲有該余額的精準數(shù)據(jù)，接下來：
- 余額100，X在北京(就近訪問機房A)消費了80元，余額僅剩20元，該數(shù)據(jù)在1分鐘后會同步到機房B;
- 余額100，X的夫人在廣州(就近訪問機房B)用X的賬號消費了70元，余額剩余30元，該數(shù)據(jù)在1分鐘后也會同步到機房A;
從而導致：
- 超額消費(100余額，卻買了150的東西);
- 余額異常(余額是20，還是30?);
上述架構(gòu)適合于什么業(yè)務場景?
任何脫離業(yè)務的架構(gòu)設(shè)計都是耍流氓。
當每個機房都有很多全局業(yè)務數(shù)據(jù)的訪問場景時，上述多機房架構(gòu)并不適用，會存在大量數(shù)據(jù)不一致。但當每個機房都訪問局部業(yè)務數(shù)據(jù)時，上述多機房架構(gòu)仍然是可行的。
典型的業(yè)務：滴滴，快狗打車。
這些業(yè)務具備數(shù)據(jù)聚集效應：
- 下單用戶在同一個城市;
- 接單司機在同一個城市;
- 交易訂單在同一個城市;
這類業(yè)務非常適合上述多機房多活架構(gòu)，多個機房之間即使存在1分鐘延時的“異步數(shù)據(jù)同步”，對業(yè)務也不會造成太大的影響。
多機房多活架構(gòu)，做不到理想狀態(tài)下的“同機房連接”，有沒有折中方案?
如果完全避免跨機房調(diào)用的理想狀態(tài)做不到，就盡量做到“最小化”跨機房調(diào)用。
如上圖所示，在非必須的情況下，優(yōu)先連接同機房的站點與服務：
- 站點層只連接同機房的業(yè)務服務層;
- 業(yè)務服務層只連接同機房的基礎(chǔ)服務層;
- 服務層只連接同機房的“讀”庫;
- 對于寫庫，沒辦法，只有跨機房讀“寫”庫了;
該方案沒有完全避免跨機房調(diào)用，但它做到了“最小化”跨機房調(diào)用，只有寫請求是跨機房的。
但互聯(lián)網(wǎng)的業(yè)務，絕大部分是讀多寫少的業(yè)務：
- 百度的搜索100%是讀業(yè)務;
- 京東淘寶電商99%的瀏覽搜索是讀業(yè)務，只有下單支付是寫業(yè)務;
- 58同城99%帖子的列表詳情查看是讀業(yè)務，只有發(fā)布帖子是寫業(yè)務;
寫業(yè)務比例相對少，只有很少請求會跨機房調(diào)用。
該多機房多活架構(gòu)，并沒有做到100%的“同機房連接”，通常稱作偽多機房多活架構(gòu)。
偽多機房多活架構(gòu)，有“主機房”和“從機房”的差別。
多機房多活架構(gòu)的初衷是容機房故障，該架構(gòu)當出現(xiàn)機房故障時，可以把入口處流量切到另一個機房：
- 如果掛掉的是，不包含主庫的從機房，遷移流量后能直接容錯;
- 如果掛掉的是，包含主庫的主機房，只遷移流量，系統(tǒng)整體99%的讀請求可以容錯，但1%的寫請求會受到影響，此時需要將從庫變?yōu)橹鲙?，才能完全容錯。這個過程需要DBA介入，不需要所有業(yè)務線上游修改。
畫外音：除非，站點和服務使用內(nèi)網(wǎng)IP，而不是內(nèi)網(wǎng)域名連接數(shù)據(jù)庫。架構(gòu)師之路已經(jīng)強調(diào)過很多次，不要使用內(nèi)網(wǎng)IP，一定要使用內(nèi)網(wǎng)域名。
偽多機房多活架構(gòu)，是一個實踐性，落地性很強的架構(gòu)，它對原有架構(gòu)體系的沖擊非常小，和單機房架構(gòu)相比，僅僅是：
- 跨機房主從同步數(shù)據(jù)，會多10毫秒延時;畫外音：主從同步數(shù)據(jù)，本來就會有延時。
- 跨機房寫，會多10毫秒延時;
小結(jié)：
- 理想多機房多活架構(gòu)，是純粹的“同機房連接”，僅有異步數(shù)據(jù)同步會跨機房;
- 理想多機房多活架構(gòu)，會有較嚴重數(shù)據(jù)一致性問題，僅適用于具備數(shù)據(jù)聚集效應的業(yè)務場景，例如：滴滴，快狗打車;
- 偽多機房多活架構(gòu)，思路是“最小化跨機房連接”，機房區(qū)分主次，落地性強，對原有架構(gòu)沖擊較小，強烈推薦;
臨時性多機房多活架構(gòu)，是機房遷移過程中的一個過渡狀態(tài)，機房遷移步驟又該如何?且聽明天分解。
思路比結(jié)論重要。
【本文為專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
網(wǎng)站名稱：多機房多活架構(gòu)，究竟怎么玩？
瀏覽路徑：http://www.5511xx.com/article/cdehdhg.html
