點擊有驚喜
我今天分享是餓了麼在資料庫和多活資料庫這塊的實戰經曆,供大家參考。
主要分享以下五點:
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這種架構會天然面臨一些剛剛講的資料延遲的問題,所以這塊我們的定義是一些寫入量不大,訪問量大,對資料延時是不那麼敏感的業務就可以放到這裡面來。 三、資料庫改造
點擊有驚喜