餓了麼異地雙活資料庫實戰_資料庫

來源:互聯網
上載者:User

點擊有驚喜


我今天分享是餓了麼在資料庫和多活資料庫這塊的實戰經曆,供大家參考。

主要分享以下五點:

1、多活當中的痛點

2、多活的架構

3、資料庫改造

4、DBA 挑戰

5、收益與展望 一、多活當中的痛點

我們先來看一下多活的第一個痛點:要考慮做多活到底是同城的多活還是異地的多活,跨地區網路延時是現階段很難突破的點,因為餓了麼面臨的是異地的多活,所以我們需要基於延時這個前提來考慮方案。


從北京到上海中間有30毫秒的延遲,這個會帶來什麼問題。我們接下來會講。


上圖是同城和異地多活不同的點,複雜性和可拓展性對架構的影響方面會有很大的不同。

我們挑幾個點講一下:

1、如果只是做同城多活的話,像30毫秒的延時不需要考慮,因為同城的延時通常只有幾毫秒,跟同機房差不大。

2、如果是異地30毫秒的延時就需要重點考慮了,因為如果是反覆調用的應用,放大的時間就不只是30毫秒了,可能是300毫秒、500毫秒,對很多應用來說是不可接受的。

在可擴充性方面如果做的是異地多活的話,你的可擴充性理論上來說沒有太多的邊界。我們做同城多活只能在上海機房裡面選,如果是異地多活,可能是全國甚至是全球都可以選。


還有一個比較難的問題,就是怎麼保證資料的安全。多活資料可能面臨多個寫入點,可能會錯亂、會衝突、迴圈複製、資料環路等問題,這種情況下怎麼保障一致性。如果這些沒有考慮好之前,你是不能上多活方案的,多點寫入的風險對資料的考驗是很大的。

綜合考慮下來我們選擇了異地多活,所以這些問題我們都需要克服,也意味著會面臨很多的改造。


如何解決跨機房延時對業務的影響,包括各種抖動甚至是斷網的問題。怎樣有效區分我們訪問的流量,最大限度地保障使用者的訪問落在正確的機房,這個都是需要解決的痛點。

我們採取了一些措施:

1、盡量把業務做成類聚的,讓一個使用者的訪問落在同一個地方。

2、不是所有的業務都有多活特性的,還可以有全域使用的業務(比方使用者資料),所以需要做業務類型劃分。


在服務劃分這一層怎麼定義業務調用的邊界,還有我們基於什麼對流量和使用者做劃分的呢,目前根據我們的業務特點使用的是地理柵欄(POI),使用者、商戶、騎手當前所在的地理位置是我們入口流量劃分的依據。
再看看路由控制這一塊,除了入口流量這一層做了機房的劃分,還在內部使用了虛擬Shardingkey,ShardingKey會把全國流量分成多個部分,並且與POI標籤綁定,這樣就可以把邏輯ShardingKey和物理位置對應起來,切換的時候訪問就可以隨ShardingKey分流到不同的機房。APIRouter就是為了完成這個工作的,它會根據配置的規則把Shardingkey對應的流量分到對應的機房。
髒寫預防方面,為防止資料衝突,我們也需要業務配合做一些多活規則的改造,這些規則對業務還是有一些侵入性的。另外SOA-Route就是內部跨業務調用的訪問路由。還有一個DAL,就是資料庫的代理層。
業務訪問在我們多層的路由控制下,理論上應該能正確路由到合適的機房,如果超越規則或者沒有按規則改造的意外流量真正穿透到DAL這一層的時候我們是強制拒絕的,因為底層認為這個訪問是屬於異常的調用,流量走錯了機房,這時候就會拒絕。所以我們寧願讓他失敗也不能讓控制之外的資料進來,這樣才能保障規則和資料的可控性。
資料一致性方面我們有一個重要的DRC資料同步組件,資料庫這塊有一些自增的控制,DBA還研發了一個資料一致性校正的工具(後面會介紹)。
二、多活的架構


粗略過了多活的一些痛點和我們的應對方案後,我們現在來看一下整個多活的架構。這個上面是我們從入口流量、分流量控制、資料多機房同步,包括各個重要組件的架構等。還有裡面有globol zone這一項,它是我們剛剛講的需要全域依賴的業務會把它放在globol zone裡面。


DRC這是做多活時相當重要的組件,主要解決資料在多個機房當中的同步複製。我們從北京機房寫入的資料,會同步到上海的機房。上海的機房寫入的資料也會通過DRC這個組件同步到北京的機房。大家可以看它其實包含三塊服務,Replicator、Applier和Manager,一個收集變更資料、一個將變更資料寫入到另一個機房,另外一個是做管理控制。


DB架構這塊我們有兩類(準確講還有一類是多推的,比較少),第一類是ShardingZone,不管是資料寫入還是訪問都是本機房提供,出問題的時候也只是流量的切換,並不涉及到底層的變動,這個是真正多活的架構。

還有一種是剛剛講的,有些沒有辦法做業務分區的,是globolZone的架構,寫是集中在一個機房,讀在本地機房完成。大家可能會想到globalzone這種架構會天然面臨一些剛剛講的資料延遲的問題,所以這塊我們的定義是一些寫入量不大,訪問量大,對資料延時是不那麼敏感的業務就可以放到這裡面來。 三、資料庫改造

點擊有驚喜


聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.