IT 基礎設施改造的這把火，終於從網際網路行業燒到了餐飲行業。

過去十餘年，網際網路行業透過 IT 基礎設施的革新，實現了從單一資料庫到多活資料庫架構的跨越，顯著提升了業務的高可用性和容災能力。如今，餐飲行業也沿著這一路徑，開始向多活資料庫架構遷移。

從表面上看，餐飲作為最傳統且極度下沉的行業，似乎和相對複雜的多活資料庫架構關聯不大。但實際上，隨著餐飲企業數字化轉型加速，從顧客點單到會員管理，從食材採購到營銷推廣，沉澱的資料資源早已達到海量規模。根據國家資訊中心釋出的《中國餐飲業數字化發展報告（2024）》，餐飲業透過智慧農業、數字採購、冷鏈運輸等多環節的資料採集，形成了龐大的資料資源。報告強調，資料要素是推動餐飲業數字化發展的關鍵動力之一，具有“乘數效應”，能夠有效促進資料要素自由流動，推動餐飲行業朝著智慧化方向發展。

而多活資料庫架構正是應對這一趨勢的重要支撐。透過在不同資料中心部署多個數據庫節點，能夠確保即使任何一個數據中心故障，業務依舊可用。這種架構能夠提升系統的高可用性和容災能力，為餐飲企業的數字化轉型提供了堅實的技術基礎。

對於還沒有采用多活資料庫架構的餐飲企業而言，麥當勞中國的遷移實踐提供了一個值得借鑑的範本——這個在國內坐擁 6000 餘家門店的全球餐飲領先品牌，正透過 BCP（業務連續性計劃）專案加速推動 IT 基礎設施革新。其中，資料庫作為確保業務連續性最關鍵的環節之一，從單一資料庫架構遷移到多活資料庫架構，自然成為了重中之重。

對於金融這類天然對高可用性有較高要求的行業而言，多活資料庫架構早就成了必選項。但在擁有上千年曆史的餐飲行業中，多活架構的應用實踐並不普遍，餐飲企業更多會基於成本、技術複雜度、資料一致性等考量，選擇採用單一資料庫架構，即所有資料集中儲存在一個數據庫例項中。

當企業的業務體量和複雜度都相對較低時，單一資料庫架構不失為一個性價比極高的選擇。但當業務體量和複雜度陡增，單一資料庫架構的侷限性愈發明顯。比如，當業務體量增長到一定程度時，單一資料庫的讀寫壓力也會隨之增大，容易出現效能瓶頸，進而影響系統響應速度。最致命的是，單一資料庫架構等同於“把雞蛋都放在一個籃子裡”，一旦出現人為操作錯誤、電力系統故障、物理災害等風險導致資料庫宕機，整個業務系統也會跟著全面停擺。

“目前在餐飲行業中，多活架構的應用尚不普遍，企業更多是在數字化轉型的推動下開始逐步考慮做多活。此外，多活架構在餐飲行業推廣面臨的挑戰也比較多，包括技術要求較高、成本投入大以及資料一致性等問題。”儘管如此，麥當勞中國 IT 團隊指出，隨著數字化轉型的深入，多活架構正逐漸成為餐飲行業的一個確定趨勢，特別是對於大型餐飲企業來說，構建多活的高可用架構已經成了保障業務持續穩定執行的必然選擇。

麥當勞中國正是基於業務穩定性與連續性的考量，對資料庫進行了 3AZ 改造，即在三個可用區（Availability Zone，簡稱 AZ）部署資料庫。

從理論上講，像麥當勞中國這樣的餐飲巨頭，過去採用單一資料庫架構並非最佳實踐。但在麥當勞中國進行本地數字化轉型的初期，為了簡化系統複雜度，單一資料庫架構自然成為一個過渡性的階段性狀態。此外，麥當勞中國當時還面臨另外一個現實挑戰：一個執行超過 10 年的資料中心也需要遷移到新的中臺方案中。在完成整體遷移之前，系統需要暫時依賴單一資料庫架構來維持正常執行。

2019 年，麥當勞中國開始正式推進數字化轉型程序。隨著企業 IT 服務不斷增加，來自 APP、小程式的流量和訂單佔比越來越高。在用餐高峰時段，一旦 APP 或小程式出現故障導致服務中斷，將會對業務產生較大影響。基於業務連續性的考量，2022 年，麥當勞中國啟動了 BCP 專案，這也是麥當勞中國構建 IT 基礎架構時非常重要的核心內容。而在 BCP 專案中，最核心的就是保障使用者資料和業務資料的完整性——即便在機房級別故障的情況下，核心業務仍能正常執行。

麥當勞中國率先組建了一個由測試、研發和運維人員組成的 BCP 專案團隊，而資料庫正是整個專案最關鍵的一環。團隊採用了 TiDB 分散式資料庫，並投入了近一年的時間，對 TiDB 的 BCP 方案進行了全面而深入的調研，最終成功完成了 TiDB 的 3AZ 改造，將原有的單中心架構升級為三中心架構。

據麥當勞中國 IT 團隊介紹，本次改造的範圍包括麥當勞點餐主流程中的所有核心繫統，如會員、積分、訂單和卡券等。

透過監控資料發現，改造後的資料庫平均響應時間比單中心架構下減少了約 20%，系統性能提升了 30%-50%。此外，改造完成後，資料庫叢集的容災能力大幅提升，業務恢復時間明顯縮短。 在過去的單中心架構下，如果發生機房級別的故障，業務將完全不可用；而在三中心架構下，即使任何一個機房發生故障，資料庫可能在 10 分鐘內就完成了業務恢復，整個業務系統在半小時內即可恢復正常服務，極大地提升了業務連續性。

在多中心改造過程中，資料庫的 CAP（一致性、可用性、分割槽容錯性）是重中之重。 為確保找到更適合自身業務場景的技術方案，麥當勞中國的專案團隊從 2022 年 5 月開始對 TiDB 的 BCP 方案進行調研，期間開展了多輪的測試和 POC(Proof of Concept，概念驗證) 實踐，並根據結果持續最佳化和調整方案。

在調研初期，團隊重點考察了四種架構方案：

三中心單叢集方案：TiDB 使用 Raft 協議作為共識機制，與三資料中心架構相容性極佳。叢集跨三個資料中心部署，每個中心都可對外提供讀寫服務。即使任一中心故障，系統仍能正常執行，且資料一致性不受影響。

“偽”三中心單叢集方案：這是三中心單叢集方案的變種，第三個中心僅作為仲裁節點，不對外提供服務。實踐中，前兩個中心通常為 IDC 節點，第三個中心可以是低配置的雲節點，從而降低網路成本和複雜性。

雙中心單叢集方案：TiDB 叢集部署在兩個資料中心，比三中心更經濟。由於 Raft 依賴多數派共識，副本以 2:1 比例分佈，主中心兩份，副中心一份，外加一份無投票權副本。副本間透過 Raft 保證一致性和高可用。該方案有三種同步狀態：同步複製（sync）、非同步複製（async）和恢復同步（sync-recover）。

傳統雙中心互為主從方案：在雙向複製容災方案中，兩個地理位置分散的 TiDB 叢集互為資料的備份，仿照 MySQL 的雙向主從複製。當一方故障時，另一方無縫接管，保障高可用性。

在調研過程中，團隊發現雙中心單叢集方案由於 TiDB 生產版本（V4.x）的限制存在一些缺陷，因此首先排除了這一方案，重點對另外三個技術方案做對比和測試。

其中，雙中心互為主從方案是 TiDB、MySQL 或其他關係型資料庫做 BCP 和高可用架構設計時普遍採用的常規方案。在這種架構下，兩個資料中心互為主從關係，一個作為主中心處理主要業務流量，另一個作為從中心進行資料備份和容災準備。但這種方案的侷限性在於，當網路延遲較高或複製鏈路出現問題時，可能存在資料延遲和一致性問題。且該方案需要對業務程式碼進行改造，保證資料不會在兩個中心重複執行。因此，該方案 更適用於那些對資料一致性要求較低的場景，如社交媒體或電商等。

三中心單叢集作為最主流的技術方案，通常採用三中心五副本架構，適合對資料一致性要求極高、效能影響敏感的場景，如銀行交易系統等。但該方案對網路延遲和頻寬的要求極高，成本也比較高。此外，考慮到麥當勞中國當時只有兩個 IDC 資料中心，其他資源主要依賴於公有云服務，而 IDC 和公有云之間的專線質量相對不夠穩定，這種限制促使團隊選擇了一種更靈活、更適應實際條件的架構方案——“偽”三中心單叢集方案。

“偽三中心單叢集是我們自己取的名字，並不是一個通用叫法。我們調研發現，這一方案更契合麥當勞中國的需求，可以透過兩個 IDC 對外提供業務，另外一個雲上的 IDC 只承接資料，不對外提供服務，從而降低了 IDC 與雲之間的網路專線不穩定對效能的影響。”

據麥當勞中國 IT 團隊介紹，在評估不同技術方案時，團隊重點關注了兩個關鍵指標：RPO（恢復點目標）和 RTO（恢復時間目標）。“我們要求 RPO 為 0，資料必須保證完全一致；RTO 為 10 分鐘，發生故障後，系統必須在 10 分鐘內完全恢復所有業務。”對比其他企業來看，麥當勞中國對 RPO 和 RTO 兩個指標的要求都相對較高，其中 RPO 為 0 的要求更是與金融行業一致。

除了 RPO 和 RTO，團隊在評估技術方案時還重點關注了網路質量、成本和運維複雜度等關鍵因素。

其中，網路延遲和頻寬能夠直接影響方案的可行性，因此網路質量成為團隊首要考量的因素。調研發現，如果網路延遲超過 3 毫秒，雙中心互為主從方案可能是更合適的選擇；而如果延遲低於 3 毫秒，“偽”三中心單叢集方案則更具優勢。

成本也是團隊關注的重點，具體包括硬體、軟體以及資料丟失後可能帶來的損失等。從成本角度來看，相比需要雙倍伺服器配置的互為主從方案，“偽”三中心單叢集方案僅需 1.5 倍的伺服器數量，即可將效能提升 30%-50%。此外，“偽”三中心單叢集方案的運維複雜度相對較低，特別是在故障恢復時無需人為干預，配置也較為簡單。

確定好“偽”三中心單叢集方案後，下一步就是完善實施方案，這也是實現整個遷移過程更絲滑的基礎。其中，最重要的就是制定遷移策略。

最初，專案團隊考慮採用基於主從複製技術的主從災備切換方案進行資料庫架構變更。該方案將主叢集的資料非同步即時複製到從叢集。遷移時，需停止主叢集寫入，等待資料同步完成並驗證一致性，然後將應用連線切換至從叢集。然而，停止寫入、資料同步和一致性比對過程預計至少需要 10 分鐘的停機時間，考慮到麥當勞 24 小時營業的特殊性，團隊決定尋找一種不影響業務的實施方式。

經過與 TiDB 原廠、研發和測試團隊的深入討論，在縝密的分析和論證之後，團隊最終選定了原地擴縮容方案（線上將叢集從單中心部署變更為單叢集三中心部署）作為本次多中心改造的核心策略。而對於資料量龐大的會員系統，團隊採用主從叢集切流方案。該方案透過搭建一套 3AZ 架構，將資料單向同步，可以將切換時間控制在 5 分鐘以內。

在正式上線前，團隊先針對每套叢集在測試環境中開展了多輪原地升級演練和故障演練。在演練過程中，團隊發現並解決了 30 個性能相關問題和 8 個故障演練相關問題，並逐一攻克了技術難點和疑點，確保了方案的可靠性。

值得一提的是，第一套試點叢集的測試周期長達 80 天，透過經驗積累和持續最佳化，後續叢集的準備時間縮短至約 1 個月。整個準備階段的系統性和嚴謹性，為生產環境的平穩上線提供了有力保障。

在生產環境的實施階段，團隊選擇凌晨 0:00-04:00 這一業務低峰時段進行變更操作，最大限度地降低了遷移過程對業務的影響，實現使用者無感知的平滑升級。為了確保上線過程萬無一失，團隊制定了詳細的回滾方案，確保每個步驟都可以快速回滾，以便在出現問題時能夠快速恢復，避免影響業務。

具體來說，團隊將整個遷移過程劃分為三個階段逐步推進：

第一階段： 在第 2 箇中心部署 TiDB 例項，並將其加入原叢集。藉助 TiDB 的線上彈性擴容能力，系統自動以 Region 為單位逐一遷移資料副本。整個過程採用“小步快跑”的方式，人為控制遷移速度，並設定資料中心 2 的節點暫不承擔業務流量，將遷移對業務的影響降到最低。

第二階段： 當所有資料副本在資料中心 2 中生成後，原叢集的部分節點退出，資料中心 2 開始承擔業務負載。此時，如果遇到問題，團隊可以快速回退至單中心執行，確保業務連續性。

第三階段： 在確認資料中心 2 穩定執行後，團隊重複類似第一階段的操作，將資料中心 3 的節點以擴容的形式加入叢集，TiDB 自動以 Region 為單位逐一遷移資料副本。整個過程同樣採用“小步快跑”的方式，人為控制遷移速度，並設定資料中心 3 的節點暫不承擔業務流量。

“實施改造階段的技術複雜度最高，因為涉及到真實的生產環境，同時也是技術方案確定後需要進一步打磨的環境，所以當時遇到的問題也比較多。”在第二套叢集的實施過程中，團隊曾遇到過一個重大挑戰：在擴縮容操作後的凌晨 4 點，叢集的響應時間出現異常升高。團隊迅速組織緊急會議，包括研發、測試、DBA 和 TiDB 原廠工程師共同排查問題。由於此前團隊已經制定了詳細的回滾方案，在接近業務早高峰時，團隊決定如果問題還是無法得到解決，將執行快速回滾。最終，團隊在業務早高峰前成功定位到問題根源在於一個引數需要調整，並在生產環境中緊急修改。5 分鐘後，叢集的響應時間恢復到正常水平。

除了提前制定詳細的回滾方案，團隊還準備了一個兜底方案：搭建了一套與原單中心架構相同的叢集。如果在三中心變更過程中出現問題，無法回滾到最初的單中心狀態，可以透過這套備用叢集進行緊急切換，確保業務不受影響。此外，在整個升級過程中，麥當勞中國專案團隊和 TiDB 原廠的技術工程師始終保持線上，從開始變更操作到早高峰結束，全程監控業務執行情況，保障整個實施改造過程能夠順利進行。

對於這樣一個大型跨團隊協作專案來說，團隊間的緊密配合與高效協同是確保專案順利推進的核心因素之一。

據介紹，整個專案共涉及研發、測試、DBA、產品、業務、運維等多個團隊，由效能測試團隊的成員擔任專案經理，透過內部自研 Ninja 工具進行任務排程和釋出管理，確保專案能夠高效執行。

在跨團隊協作過程中，最大的挑戰來自於溝通成本。不同團隊的工作模式和技術能力存在差異，導致大家在規劃時間和實施方案時，需要花費大量精力協調各方需求。為此，專案團隊建立了定期的溝通機制，包括週會、月會以及關鍵問題討論會，確保所有相關資訊能夠及時同步到各個業務方和跨團隊部門。

在研發、測試和 DBA 等跨團隊成員的緊密協作下，透過前期調研、測試演練和實施改造三個關鍵階段的縝密執行，麥當勞中國圓滿完成了 TiDB 多中心改造，不僅提升了系統的可靠性和容錯能力，為業務連續性保障奠定了堅實的基礎，也為未來的系統設計和改造提供了可複用的方法論。

在完成多中心架構遷移後，麥當勞中國對多活架構的未來最佳化方向也有了更清晰的規劃。“我們現在實現的是同城雙活，未來的目標是朝著多地多活架構演進，不僅侷限於現有的下單鏈路，還將擴充套件到更多的業務場景，例如 ToB 鏈路的多活支援。”

對於其他考慮從單一資料庫架構遷移到多活資料庫架構的企業，麥當勞中國也分享了以下幾點建議和經驗：