數據庫同城雙活方案探討

前一段時間有應用要進行雙活改造，聊到數據庫的對稱雙活架構，看了下同業在應用雙活尤其是數據庫雙活設計的時候，沒有一個最佳的實施方案。本文簡單介紹下應用層和數據庫層的同城雙活設計方案，對比了不同方案的優缺點，以在實際選擇時候作爲參考。

1、應用層同城雙活架構

同城雙活架構是指在同一個城市或地理區域內，構建兩個或多個數據中心，也就是常說的 Region 的概念，這些在同一個 Region 內的數據中心同時對外提供服務，實現資源的充分利用和業務流量的負載均衡。同城雙活架構有以下特性：

• 高可用性：由於有兩個或多個數據中心同時運行，當一個數據中心出現故障或維護時，另一個數據中心可以迅速接管服務，確保業務的連續性和穩定性。這種架構顯著提高了系統的容錯能力和可用性。

• 負載均衡：同城雙活架構可以實現流量的動態分配和負載均衡，根據各個數據中心的負載情況，智能地將用戶請求分發到不同的數據中心，從而優化資源利用，提高系統的整體性能和響應速度。

• 容災備份：同城雙活架構相互之間具備容災備份的功能。當一個數據中心出現故障時，另一個數據中心可以迅速接管業務，確保數據的完整性和業務的不間斷運行。

在雙活架構的實現上，由於應用多數是無狀態的，通過 DNS 和負載均衡在接入層實現流量動態分發，應用層按照豎井式架構部署，如下圖所示。生產站點和同城站點在部署資源上完全對等，並具備同時接管承載兩個站點流量的能力，當生產站點或者同城站點的應用出現異常時，將流量快速切換到一個站點，提升了業務的可用性。

上述高可用架構中，雖然在應用層實現了同城雙活，但是同城中心的應用是要寫回生產的數據庫主節點，依賴數據庫層的數據同步保證同城站點的數據一致性。當生產站點數據庫出現異常或者站點級別異常時，通過自動或者手動的方式切換到同城站點，但是這個切換過程其實是有損的，故障期間業務會出現全局性的不可用。那麼想進一步提高業務的可用性，降低站點級故障的業務影響，實現數據庫層的同城雙活架構，將如何實現？

2、數據庫層同城雙活實現

2.1 常用的數據複製技術

在探討數據庫層的雙活架構實現之前，先來看下在同城架構中常用的數據複製技術有哪些。數據複製是指將一組數據從一個數據源拷貝到一個或多個數據源的技術，在同城雙活架構中有明確的 RPO 和 RTO 要求，因此數據複製的性能和時效性是技術選擇的重要考量。常用的數據複製技術包括幾種：

• 基於應用的數據複製：通過應用程序與主備中心的數據庫進行同步或異步的寫操作，以保證主備中心數據的一致性。這種方式技術實現複雜，與應用軟件業務邏輯直接關聯，實現和維護難度較高，並且會提高系統的風險與數據丟失的風險，在實際場景中很少使用到。

• 基於數據庫的數據複製：利用數據庫自身的數據庫日誌基於邏輯複製或物理複製的方式，將數據同步或異步的方式複製到備節點，實現主備數據的一致性。基於數據庫層的複製技術依賴於各數據庫產品自身的能力，能夠實現記錄級和事務級的數據一致性，技術方案成熟穩定並且網絡佔用帶寬小，是主流的數據複製方案。

• 基於主機的數據複製：由安裝在主機上的卷管理軟件或是文件系統來實現，在實際的應用場景中，以基於卷管理軟件的數據複製技術居多，這種方式通常與主機平臺相關，對軟件的要求較高。通過主機數據管理軟件實現數據的遠程複製，當主數據中心的數據遭到破壞時，可以隨時從備份中心恢復應用或從備份中心恢復數據。一般用於備份容災環境的數據同步或恢復，實際應用案例也不多。

• 基於存儲設備的數據複製：利用存儲陣列自身的盤陣對盤陣的數據塊複製技術實現對生產數據的遠程拷貝，分爲同步方式和異步方式，同步方式可以保證後備磁盤陣列中的數據與生產系統數據同步，實現 RPO 爲零。該複製技術依賴於存儲設備的功能，要求是同構的存儲系統，並且對帶寬的要求較高。

• 基於存儲虛擬化的數據複製：與基於存儲設備的複製技術類似，不同之處是由存儲虛擬化控制器在存儲網絡層面實現，不要求底層存儲陣列同構。

2.2 數據庫同城雙寫的難點

在數據庫主備節點的高可用部署架構中，如果要實現數據庫雙寫，涉及到將數據同時寫入多個數據庫實例，在技術實現上存在諸多難點。

1）數據一致性問題

• 在主備庫同步過程中，由於網絡延遲、硬件故障等可能存在主備數據不一致的情況，當主庫成功寫入數據但是從庫沒有及時同步，從庫訪問到這部分數據就存在一致性偏差。

• 當兩個數據庫實例同時寫入相同的數據時，則會發生數據衝突，類似 MySQL 的雙主架構中就缺少這種衝突檢測機制。

• 當一個主節點更新數據後，另一個主節點可能還沒有同步到最新的數據，讀取時可能會出現不一致的結果。

2）性能問題

• 在同步複製中，主庫需要等待從庫的數據確認寫入後才能成功返回，需要保證強一致性，增加了寫操作的延遲；

• 雙寫情況下需要維護多個數據庫實例的同步狀態，增加了系統的資源開銷。

• 爲解決數據不一致問題或者主鍵衝突時，引入分佈式鎖、樂觀鎖和唯一鍵約束等機制，會帶來額外的性能開銷

2.3 類 RAC 集羣架構

RAC（Real Application Clusters）架構允許在多個物理服務器節點上部署相同的數據庫實例，這些實例共享相同的數據庫文件和存儲資源，底層使用分佈式鎖管理器（DLM）等機制來控制多個節點對共享資源的併發訪問，確保數據的一致性和完整性，避免數據衝突和丟失。與傳統的主備模式不同，RAC 是一種並行模式，每個節點都可以對數據庫進行讀寫操作，當一個實例出現問題時，請求會自動轉發到另外一個實例。

以達夢共享集羣架構爲例，在同一個站點內實現 RAC 共享存儲架構，實現存算分離，計算實例有多個可以併發讀寫，數據文件、控制文件在集羣系統中只有一份，這些文件保存在共享存儲上。另外在共享存儲上使用 DMASM 文件系統管理共享存儲設備，並通過配置 DMASM 鏡像提供多副本技術。當出現磁盤損壞或數據丟失時，系統無需人工干預即可利用其他鏡像副本繼續提供數據庫服務，同時又可以自動或手動通過使用其他鏡像副本進行數據恢復。

RAC 架構實現了同一站點級別同時寫操作，那麼能否延伸到同城雙中心的 RAC 部署實現呢？

該技術方案在實現上尚存在諸多技術難點：

• 首先存儲層藉助存儲虛擬化產品實現雙數據中心組成的存儲集羣，依賴雙中心網絡的二層打通，成本上需要網絡波分設備、存儲交換機等；

• 仲裁的一致性問題，數據庫 RAC 集羣和存儲集羣的一致性判斷，數據庫集羣依賴集羣管理組件來判斷、存儲依賴依賴站點之間網絡的連通性，如果出現不一致，整個集羣會 crash；

• 鏈路穩定狀態不可控：雙中心鏈路的主幹網延遲因素和線路穩定性，在讀寫熱點相對突出的業務上會出現數據庫讀寫性能影響比如 IO 阻塞，同時鏈路的不穩定會導致存儲鏈路頻繁切換，甚至會導致集羣仲裁的頻繁發生。

從技術架構實現上來看，基於 RAC + 共享存儲的數據庫雙活方案，技術實現難度很大，業內也少有成功實施的案例。

2.4 原生分佈式數據庫實現

原生的分佈式數據庫具備數據自動分片的功能，以 OceanBase 數據庫爲例，它將大表劃分爲多個較小的分片（Tablet），這些分片自動分佈到多個節點上，每個節點處理數據的一部分。另外每個分片有多個副本，並分佈在不同的節點上，副本之間通過 Paxos 一致性算法實現數據一致性。當生產和同城部署在同一個數據庫集羣中，通過配置分片的策略，在雙中心都會有主節點分佈，也就是實現了生產和同城同時寫的操作。

基於原生分佈式數據庫的實現生產和同城雙中心雙活架構，當生產或同城中心故障時，自動將主副本切換到其它節點，保證了可用性。不過這種架構下不可避免的存在跨中心的寫業務操作，存在以下問題：

• 當跨中心的讀寫業務大時，會對跨中心的網絡帶寬帶來壓力，進行會影響交易性能

• 跨中心網絡時延和鏈路抖動的影響，影響分佈式事務的性能以及分佈式組件之間的鏈路檢測的穩定性和有效性。

2.5 單元化部署架構

單元化部署是將應用服務和數據按照某種規則進行分片，使得某個單元提供面向部分數據分片的完整服務能力。每個單元都是一個獨立的實體，包含完整的服務和數據副本，可以獨立運行和擴展。單元化可以實現系統的水平擴展，提高系統整體處理能力，提高系統的容錯性和可用性。單元化架構要求系統具備數據分區能力，數據分區承載了各個單元的業務流量比例，數據分區就是將全局數據按照某個維度水平劃分開來，每個分區的數據互不重疊、每個節點有自己的應用系統和數據庫。比如業務服務單元包含多個客戶的業務數據以及爲此類客戶提供服務支持的應用實例。

單元化與分佈式數據庫能夠有機結合，不同的單元存儲在不同的數據庫節點，每個數據庫節點根據業務大小還可以進行數據分片分爲不同的數據庫實例，單元和單元之間實現物理上的隔離和數據上的邏輯隔離。單元化架構在實現過程中有以下難點：

• 單元化的拆分：設計合理的單元拆分方式，比如按照地域、客戶號進行單元劃分，單元和數據庫的分片規則也需要確認；

• 單元擴展：隨着業務規模的增長，需要擴展單元，涉及到分佈式數據庫的橫向擴展；

• 單元化架構高可用：單個單元故障不會造成全局影響提高系統整體可用性，結合分佈式數據庫的高可用特性，設置合理的副本數，保證 RPO 和 RTO 的要求，甚至實現數據庫層站點級別的雙活架構；

• 跨單元數據同步彙總：對於跨單元數據的彙總，支持部分批量加工的綜合分析，需要從不同單元進行數據抽取彙總和加工。

基於單元化的部署架構實現數據庫層的同城雙活，也是業務比較普遍的做法，在架構實現上將部分單元的數據庫主節點部署在同城單元，在網關層進行單元的路由分發，實現哪些業務訪問生產單元、哪些業務訪問同城單元。

2.6 總結

本文討論了同城雙活的實現架構以及如何實現數據庫層同城雙活，對於對同一份數據同時寫操作在集羣的機制上本身比較複雜，雖然 RAC 架構能夠實現本站點的部署，但是在同城架構下 RAC 集羣要依賴底層的數據庫網絡和存儲網絡，架構中的不穩定因素太多，而且 RAC 集羣的性能相比單集羣的架構反而會有下降。原生的分佈式數據庫架構也支持生產同城雙寫，但是存在跨中心的寫操作以及集羣間跨站點的網絡影響，對業務的性能會有影響。而基於單元化的數據庫雙活方案，結合應用的單元化設計，自上而下實現單元的物理和邏輯上的隔離性，並且生產和同城同時承載數據庫寫業務，在一定程度上實現數據庫層的雙活部署，也是業務在雙活改造過程中推薦的部署方案。

參考資料：

1. https://cloud.tencent.com/developer/article/1645727

2. https://zhuanlan.zhihu.com/p/703395844

3. 基於 Oracle RAC 實現雙活方案的分析，twt 社區

4. 分佈式數據庫單元業務應用研究報告，北京金融科技產業聯盟

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/idxRFTlkU3WHwn8YrPpZuQ