虢國飛：餓了麼異地雙活資料庫實戰

【IT168 專稿】本文根據虢國飛老師在2018年5月12日【第九屆中國資料庫技術大會】現場演講內容整理而成。

講師簡介： 虢國飛，餓了麼 DBA負責人。從事資料庫行業10+年，專注於MySQL、PgSQL、MSSQL等資料庫領域的管理、研究和平臺的研發等工作，目前負責餓了麼資料庫團隊的管理和資料庫維護方面的工作。

摘要： 異地多活(雙活)技術一直是行業內一個比較大的技術挑戰，當中要突破諸多的技術難點，很多公司都做過類似的嘗試，但是往往止步於災備階段難以向前;餓了麼雙活專案透過前期豐富的調研，真正啟動改造實施只有短短三個月就完成了上線，並且一次性上線成功，當中也遇到了不少的問題踩過很多坑，尤其是在資料庫這一塊的問題會比較多，因為在多活設計中大家最擔心的點是怎麼保證資料在多個機房實時同步、如何才能保障資料不被寫壞和怎麼兜底保障資料的一致性，這些點對資料庫方面的挑戰很大(極容易出現重大事故)，所以本次分享會對這些難點做一個全面介紹，內容包括餓了麼多活中資料庫的架構、改造、難點、收益與展望等，重點會介紹資料庫為多活所做的改造、多活過程中和上線後DBA所面臨的挑戰和我們是怎麼克服這些困難的，期望能為大家揭開多活技術的在資料庫這層面紗，為大家進行類似技術方面的改造提供參考。

分享大綱：

1、多活難點&設計原則

2、多活架構&切換

3、資料庫改造&挑戰

4、收益&展望

正文：

1、多活難點&設計原則

從多活落地後回過頭來看，多活的難點還是有很多的。

首先，同城Or異地的問題。如果是做同城多活，和異地比成本投入會少很多，起碼光纖距離和頻寬費用就會少很多。另外，異地多活實現起來會更復雜，涉及跨網路的延時，需要有更周密的方案，而同城訪問一般不需要做太多的改造，相當於是同機房的呼叫。異地多活的劣勢是改造大、成本高，但是與同城相比，存在天然優勢，最直觀直觀來看我們的擴容就不會受地域的限制，而同城機房就不能解決這個問題。

異地多活除了成本高外，異常情況下的資料處理方案，如資料出現錯亂，衝突，環路，或者一致性問題等，都需要重點考慮。

總的來看，異地多活的難點其實主要有三個，第一，如何做好分流和控制;第二，如何解決跨機房延時帶來的問題(訪問&資料);第三， 如何解決資料安全性。

基於上述這些問題，我們抽取了一些設計原則：

1)、業務內聚。跨機房自然會存在延時，但我們希望一筆交易能在同一個機房完成，減少跨機房的呼叫; 即一個訂單的生命週期在一個機房中完成，這樣可以避免跨機房延遲帶來的影響。

2)、可用性優先。絕大部分網際網路公司都是基於這個原則(base)，優先保證系統可用，對餓了麼來講就是先讓使用者可以下單吃飯，容忍暫時資料不一致，事後修復。

3)、保證正確性。在確保可用的情況下，需要對資料做保護以避免錯誤。

4)、業務可感。業務團隊修改邏輯，能夠識別出業務單元的邊界，只處理本單元的資料，打造強大的業務狀態機，在出現異常時能發現和糾正錯誤。

除此外，還有設計分割槽原則。我們在雲端部署了一個智慧DNS,並且是在多個雲端，根據使用者所在的POI位置，來完成使用者的分流。相當於是對機房的一個對映，把全國分成很多區，機房和分割槽是一對多的關係，如果使用者從某個位置進來，就會對應到某個邏輯分割槽，分割槽最終會路由到對應的物理機房，完成基於使用者位置的分流。

2、多活架構&切換

那麼，多活的實際架構是怎樣的呢?

我們會在雲端部署智慧DNS，完成使用者的分流，使用者透過DNS進來就決定它的流量會落到哪個機房，他的整筆交易基本上是在同一個機房來完成的。所以，使用者的使用不會受到跨機房的影響。另外，我們在底層也有相應兜底的架構應對方案，防止因前段路由異常情況下造成資料的錯亂。

這是我們在做資料同步時很重要的一個元件，叫做DRC。主要任務是在底層完成兩個機房之間的資料同步。設計原則是在每個機房部署相應的通道，一端接受的是資料變更，然後把變更同步到另一端機房，完成資料雙向同步。

在DB這端，我們看到最前面的架構圖有兩個。一個是ShardingZone，另外一個是GlobalZone。ShardingZone的主要特點是，適用於業務能按區域維度進行切分的應用，實現真正的多活， 而且讀寫都在本地機房進行;這個架構正常情況下，只需要本地機房的資料，對其他機房資料無依賴，所以跨機房資料延時是無影響的，我們設計時只需要考慮避免資料同步衝突(DRC衝突處理、自增值DB控制)。GlobalZone架構適用於特殊場景，比如需要對資料有強一致性的要求或者沒有分割槽標籤，它的寫是在同一個機房，但讀是在本地機房完成，這樣在讀的時候會有資料延時，所以我們要按照業務分，有些業務能接受一定程度的延時，他才會選用這種資料完全一致的架構。

具體DB的切換動作是怎麼操作的呢?

其實絕大部分情況DB都是不需要做切換動作的，因為只有GlobalZone的寫入需要變動的時候才是需要DB切換的，其他情況的流量調整和切換隻需要GZS控制前端做路由調整就行(DB不需要跟著切)。DB在切換的時候，會有鎖、等待動作，是為了保障資料完成同步。當然，等待也有時間限制，如果超時也會強切。

看下大概過程，比如我們把1機房的DB訪問切換到2機房，會先發出一個BLOCK的操作，把1機房的DB寫入先鎖住，等後面的資料同步和驗證操作完成後，GZS會控制其他元件把1機房的訪問流量改到到機房2，DAL會完成DB寫入的機房間切換。

3、資料庫改造&挑戰

在做多機房最先要做的就是要全量同步資料，包括測試環境、生產環境資料全量同步等問題。第二DRC為了解決資料衝突問題，需要增加毫秒級別的時間戳，但是我們在資料庫設計階段，並不會有這樣的欄位，所以要做很多更新。第三做多活後很多自增列也會調整，防止溢位。第四多活有不同的架構型別，所以不同型別的DB需要遷移，將同型別的DB拆分到對應的架構裡，不同型別的拆開。還有原生複製改成DRC複製、賬號網段調整、各個叢集引數一致性調整、按叢集型別調整HA配置等等動作。總的來說，首先要做資料搬移，然後適配多活的體系改造，還有個各種資料庫的配置也需要調整。做完多活以後，例項、叢集、Proxy、HA、資料量、DDL、機器故障等幾乎都是翻倍狀態。

為了應對資料庫改造問題，DBA做了哪些基礎工作呢?

首先，要有檢測資料是不是一致性的最終方案。當然，我們在前端、後端有一些相應的保護。比如在路由這層，會有幾個路由來判斷訂單是不是正確地進入了對應的機房，DAL這層也會判斷這筆交易是不是符合路由規則，不正確的話會直接拒絕。但是還是會出現一些問題，比如：軟體上的BUG，或者是沒考慮到的問題和設計之外的異常場景，會導致資料穿透到底層，造成多個機房資料不一致，所以我們要做兜底的最終資料是否一致的校驗。我們開發了DCP資料校驗平臺，能完成分鐘級別的資料校驗， DCP不只完成全量、增量、延時校驗、手動校驗，還有資料結構、多維校驗，還要考慮各種延遲、併發、校驗時長等情況;最重要的是要有一套比較方便的修復資料的方式或者配套工具，因為你找到不一致資料後，工具如果不能直觀告訴你怎麼去修復，又會是一個大問題，而且資料還會一直在變，可能會造成其他的影響。

其次，會涉及到資料的遷移、會有大表拆小表這種動作。所以我們研發了D-Bus這套工具，它可以完成DB&Table遷移 、增量和實時同步(包括暫停、斷點續傳)、單表和Sharding表資料互轉、資料校驗等工作。

第三，在系統切換的時候，HA如何與其他系統完成對接，這也是一個重要問題。我們做了一套自動化系統，叫做EMHA 。在HA切換的時候，可以和其他元件完成互動，進行配置、切換、聯動(DAL、DRC)。

第四，DDL翻倍的問題。比如100G的一個表，我們如果透過DRC把變更資料傳遞到另外一個機房，而且是在跨地域網路的情況下，網路可能會爆掉。所以，在DRC這層實際上是不方便來做DDL操作的傳遞的，DRC要把這個動作濾掉。我們DDL操作型別比較多，有原生能支援Online的DDL直接分發，還有PT的工具，還有自己研發的mm-ost的工具等。

多活場景下DDL具體要考慮什麼問題呢?首先是控制，DDL的時候空間&延時&鎖&定時&低峰期&風險&預估時長等要得到有效的控制;另外，我們的型別比較複雜，包括：非多活 、ShardingZone、GlobalZone、多推、 Sharding(分開分表)等業務，要控制好DDL的同步，同時要保障所有的表都達到一致的狀態;還有多機房的問題，我們透過Mm-ost，保證多機房一致性問題，同時保證跨機房延時在3-5s之間。

之前DDL很大一部分工作是由DBA來做(研發提供單DBA負責處理)，現在已經不需要DBA做太多的事情了，由研發自助釋出，自助釋出的比例超過90%以上，極少數情況下才需要DBA來干預，還有一部分是系統自動執行(不要研發，也不需要DBA來做)。

4、收益&展望

很多人可能會有疑問，多活花費這麼大的成本，是否值得?

首先，看下多活的收益。第一，打破了單機房(地域)容量瓶頸，當主機房不能再放機器，而且系統容量已經到上線時，你可以把流量引流到其他機房，讓多個機房能承載容量。第二，你的故障不受單機房(地域)故障影響，在做多活之前，其實我們有主力機房核心交換機出現故障的情況，當時沒有多活的只能廠商來解決，核心的交換機當機了三個小時，影響非常大，但是我們卻束手無策，而且我們的業務特點有兩個尖峰，尤其在中午尖峰的時候掛了，損失會很大。第三，動態調整各機房流量，如果有機房資源緊張，可做動態調配，或者哪個地方訪問不均衡，也可以做動態調整。第四，Online維護(透過GZS、DAL、DRC、D-Bus、DCP這些元件的配合)，有多活之後如果你想做哪些升級，可以先把流量切到一個機房，在沒有流量的機房完成各種動作，都沒問題，所以我們現在主要業務基本沒有停機維護之說。

針對企業未來發展，我們也有一些相應的計劃。首先是，想做多個機房 。現在很多企業都在計劃上雲，我們也希望在雲上做一個多活的Zone，去分擔一部分流量，而且雲上還可以動態調整資源。其次是，Data-Sharding，現在做的還是全量資料，上層流量訪問是分流量的，底層我們也在考慮對資料分流。其三是， 自動動態擴縮容，這也是我們想上雲的原因，考慮在業務高峰的時候多新增一些資源，低峰的時候釋放掉這些資源，合理控制成本。其四是，多機房強一致，我們也在做相應方案調研，希望對一致性要求高的部分也能做到多活。