本篇活動家為大家帶來從事10+年的技術大師分享餓了麼在數據庫和多活數據庫這塊的實戰經歷，供大家參考。找技術大會就上活動家。
虢國飛
虢國飛，餓了麼 DBA負責人
從事數據庫行業10+年，專注於MySQL、PgSQL、MSSQL等數據庫領域的管理、研究和平臺的研發等工作，目前負責餓了麼數據庫團隊的管理和數據庫維護方面的工作。
一、多活當中的難點
我們先來看一下多活的第一個難點：要考慮做多活到底是同城的多活還是異地的多活，跨地域網絡延時是現階段很難突破的點，因為餓了麼面臨的是異地的多活，所以我們需要基於延時這個前提來考慮方案。
1、如果只是做同城多活的話，像30毫秒的延時不需要考慮，因為同城的延時通常只有幾毫秒，跟同機房差不大。
2、如果是異地30毫秒的延時就需要重點考慮了，因為如果是反覆調用的應用，放大的時間就不只是30毫秒了，可能是300毫秒、500毫秒，對很多應用來說是不可接受的。
在可擴展性方面如果做的是異地多活的話，你的可擴展性理論上來說沒有太多的邊界。我們做同城多活只能在上海機房裡面選，如果是異地多活，可能是全國甚至是全球都可以選。
還有一個比較難的問題，就是怎麼保證數據的安全。多活數據可能面臨多個寫入點，可能會錯亂、會衝突、循環複製、數據環路等問題，這種情況下怎麼保障一致性。如果這些沒有考慮好之前，你是不能上多活方案的，多點寫入的風險對數據的考驗是很大的。
綜合考慮下來我們選擇了異地多活，所以這些問題我們都需要克服，也意味著會面臨很多的改造。
二、多活的架構
粗略過了多活的一些難點和我們的應對方案後，我們現在來看一下整個多活的架構。這個上面是我們從入口流量、分流控制、數據多機房同步，包括各個重要組件的架構等。還有裡面有globol zone這一項，它是我們剛剛講的需要全局依賴的業務會把它放在globol zone裡面。
DRC這是做多活時相當重要的組件，主要解決數據在多個機房當中的同步複製。我們從北京機房寫入的數據，會同步到上海的機房。上海的機房寫入的數據也會通過DRC這個組件同步到北京的機房。大家可以看它其實包含三塊服務，Replicator、Applier和Manager，一個收集變更數據、一個將變更數據寫入到另一個機房，另外一個是做管理控制。
DB架構這塊我們有兩類（準確講還有一類是多推的，比較少），第一類是ShardingZone，不管是數據寫入還是訪問都是本機房提供，出問題的時候也只是流量的切換，並不涉及到底層的變動，這個是真正多活的架構。
還有一種是剛剛講的，有些沒有辦法做業務分區的，是globolZone的架構，寫是集中在一個機房，讀在本地機房完成。大家可能會想到globalzone這種架構會天然面臨一些剛剛講的數據延遲的問題，所以這塊我們的定義是一些寫入量不大，訪問量大，對數據延時是不那麼敏感的業務就可以放到這裡面來。
三、數據庫改造
多活項目我們調研大概花的時間有半年左右，但真正做改造的時候時間是相當短的。從啟動這個項目到真正上線就用了三個月左右的時間。那時候時間是相當緊的，大家可以看一下我列舉大的為配合多活數據庫所做的改造項目。
四、DBA挑戰
五、收益與展望
還沒看夠或看懂？點擊右上角，關注活動家，及時獲取大會嘉賓演講乾貨及視頻！
精彩閱讀：
閱讀更多 活動家 的文章
