關于大型數據庫雙活難點問題研究

上官斌

摘要：為保障7×24持續運行，越來越多的大型政企單位的核心業務，大都逐步開始推進系統雙活建設。其中最重要，也是最難的，是如何實現大型數據庫雙活。包括仲裁一致性、性能同步、異常切換決策都是確保雙活建設成功，達到建設目標需要重點研究取舍的關鍵性難點。通過在實際生產中主持千萬用戶級電信系統雙活建設實踐，成功實現了連續3年業務零中斷，演練RPO≈0，RTO<10分鐘。現總結了其中數據庫雙活建設的一些實踐性經驗，供從業者參考。

關鍵詞：數據庫;雙活;一致性;同步;切換

中圖分類號：TP311? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2022）08-0023-03

1 雙活系統建設難點

包括金融、電信、政府等大型政企單位的核心業務用戶級通常達到數百萬級乃至千萬級、億級，業務數據量巨大，大型關系型數據庫技術得到越來越廣泛的應用。

過去我們關注數據庫的數據量大小，如今我們更加關注的，其實是從技術架構和用戶影響的角度去思考。從技術架構角度，大型數據庫系統一般采用雙機或多機集群復雜技術體系;從用戶影響角度，大型數據庫系統一般承載數百萬乃至千萬用戶級以上用戶數據，一旦數據庫故障或宕機，將可能直接影響千萬級用戶的業務體驗，甚至業務中斷。

為保障7×24不斷網，不斷電持續運行，核心業務大都逐步開始進行系統雙活，兩地三中心，甚至多地多中心的系統建設。在雙活系統建設中，基本都會遵循網絡雙活、應用雙活、數據雙活三個層次的架構設計原則。其中最重要，也是最難的，是如何實現大型數據庫雙活。尤其是如何解決大型數據庫集群之間的仲裁一致性、如何保障數據庫同步性能、節點異常情況下的切換決策問題。更是一個需要平衡的難點。

2 數據庫雙活實現

為了提升實時性業務服務性能，業務模塊可引入Dcache等分布式緩存數據庫，提升讀寫、億級用戶業務快速處理能力。而由于業務訂購關系數據主要存儲在Oracle/MySQL等數據庫，而業務鑒權和處理主要依賴Dcache。因此根據異地業務的雙活容災，雙站之間的Dcache也需要保持數據的一致性。Dcache 與數據庫之間需要維護數據的一致性。

兩個中心（IDC1和IDC2）會融合成一套異地雙活部署的網關，業務通過GSLB全局負載均衡，因此需在兩個中心部署業務檢測和切換系統。每個站點部署一套監控服務器監控所有接口機，處理機與數據庫的工作狀態。

當數據庫發生異常的時候，由監控服務器通知所有的接口機和處理機進行數據庫切換和業務恢復。當監控服務器監控到某個模塊的業務成功率低，可以根據預定策略對該模塊進行重啟或者下線處理。

3 數據庫雙寫

IDC1和IDC2機房的基于Oracle RAC和Dcache分布式高性能方案保證數據的高可靠性，移植性，同時兼顧高并發，高訪問等特點。與此同時業務需要通過配置數據雙向寫入IDC1和IDC2的數據庫中，保證兩個站點的數據一致。為保障雙活數據庫性能，直連鏈路時延需要控制在5ms之內，考慮到傳輸設備和傳輸距離的影響，同時兼顧異址容災安全，一般要求兩個雙活IDC的距離保持在30km到100km之間，實際工程中，通常通過大帶寬（GB以上）裸光纖鏈路直連兩個IDC。

IDC1機房作為主數據庫;IDC2機房作為備份數據庫。

通過域名方式訪問業務系統配置臺，對配置數據進行配置操作。不論接入的是運行在IDC1或者IDC2機房的業務系統配置臺。配置的數據都會雙向同時寫入IDC1機房和IDC2機房的數據庫，實現了兩個機房的數據一致。

新增配置雙寫流程：

（1）正常流程

① 業務系統配置臺新增數據;

② 在IDC1數據庫中寫入新數據;

③ IDC1數據庫返回成功響應

④ 在IDC2數據庫中寫入新數據;

⑤ IDC2數據庫返回成功響應

（2）異常流程1

① 業務系統配置臺新增數據;

② 在IDC1數據庫中寫入新數據;

③ IDC1數據庫返回成功響應;

④ 新增數據成功;

⑤ 在IDC2數據庫中寫入新數據;

⑥ IDC2數據庫返回失敗響應;

⑦ 告警并生成SQL文件，需要管理員檢查并IDC2數據庫，運行正常后手工執行SQL文件。

（3）異常流程2

① 業務系統配置臺新增數據;

② 在IDC1數據庫中寫入新數據;

③ IDC1數據庫返回失敗響應;

④ 新增數據失敗;

⑤ 不在IDC2數據庫中寫入新數據。

業務雙寫即業務系統對數據的增刪改操作，同時寫入IDC1和IDC2的數據庫。

4 數據一致性難點破解

4.1數據一致性等級

數據的一致性有幾個等級，弱一致性 < 最終一致性 < 強一致性。強一致性是關系數據庫的基本特征，而NoSQL產品一般都只實現到最終一致性，否則也沒有余地去實現其他優勢特性。最終一致性的意思是，數據的多個復本間有可能不是實時一致的，但是經過有限的時間或步驟，最終是能夠達到一致的。

在分布式系統中常見的復本策略有這么幾種：主備策略、主從策略、Quorum策略。相對于傳統的主備、主從策略而言，Quorum方式更加靈活，可以對多節點讀寫兼顧平衡控制。

Quorum N/R/W中，N是一份數據總共存入幾個節點（在Dcache中，特定的Key存入哪些節點是相對固定的，后面會詳細講）;R是讀取數據時，在N個節點中有多少讀取成功則認為讀取成功;W是寫數據時，在N個節點中有多少寫成功則認為寫入成功。F5CDA0EE-B226-4D1F-9AD6-B0F99FF02FD8

一般來說，在R+W>N時，認為是數據一致性程度較高的，不會出現寫了新數據卻讀到舊數據的情況。比如最典型的場景是N/R/W=3/2/2，有兩個重要意義：

①數據成功寫在一部分節點上后，后面讀數據時不可能只選擇跟之前完全不同的另一部分節點，至少會有R+W-N個節點是重合的，這就保證了讀取到的R個數據中，至少有一個是之前剛寫過的新數據;

②因為在3/2/2模型中，R

4.2內存數據庫一致性

在Dcache中，一致性強度是可根據Quorum策略靈活配置的：

當N=W=R時，是實現了強一致性，但是可用性方面很差，單點故障即影響業務應用的訪問。

最常用的還是R+W>N的模式，典型配置是N/R/W=3/2/2，兼顧可用性和數據一致性，雖然多個復本間的數據不可能每個瞬時都一致，但是最終多個復本間是一致的，而且每次業務應用對數據的讀取都建立在R個復本的比較之上，而這個模式中R個復本里至少會有一個最新的，最終返回給業務應用的也是正確的數據。可以認為，在同時最多只有單點故障發生的情況下，其一致性效果是逼近強一致性的。

Key/Value是一種新型的數據存取方式，確實能解決一部分問題，但不能解決所有問題，要避免出現對Dcache盲目使用的情況，有些流程中確實不適合使用Key/Value方式，這些問題如果規劃階段沒有發現的話，在性能測試階段可能會暴露出來。

上線以前務必要按實際的業務邏輯和實際的數據規模，在實際的硬件條件下進行性能測試。強烈建議在現網上線前預留充足的時間，直接在現網設備上進行性能測試，及時識別和排除潛在的各種干擾。

而且要覆蓋盡可能全面的業務邏輯，如果流程A和流程B存在某種關系，流程間的協作也都要覆蓋到。數據規模方面，測試時一定要達到實際的數據規模和離散程度，因為Dcache是有緩沖的，數據量很少時，所有請求在內存中即可命中，數據規模大時，可能會訪問到磁盤，所以性能表現跟數據規模是有關系的。

為了適應Dcache，原來業務處理機有關白名單鑒權的所有訪問內存庫的業務流程都需要移植和改造。同時為了提升訪問的性能，業務處理機需要維護多個Dcache客戶端線程進行讀/寫。

另外為了滿足容災的性能，需要提供Dcache的同步工具，是實現業務雙寫。以及冷備站點的Oracle數據同步到Dcache。

4.3數據庫集群一致性

為了數據的安全，基于Oracle RAC方案的高可靠性，因此數據庫采用Oracle RAC，同時由業務雙寫保證兩個站點的數據一致。

通信層管理節點之間的通信。它的職責是配置，互聯群集中節點信息，在群集管理器中使用由心跳機制產生的信息，由通信層負責傳輸，確保信息的正確到達。還有一些群集監視進程不斷驗證系統的不同領域運行狀況。例如，心跳監測不斷驗證的心跳機制的運作是否良好。

每個站點部署一套監控服務器監控所有接口機，處理機與數據庫的工作狀態。當數據庫發生異常的時候，由監控服務器通知所有的接口機和處理機進行數據庫切換和業務恢復。

5 數據庫切換

兩個IDC會融合成一套異地部署的雙活業務系統，平時IDC1機房的業務系統和IDC2機房的業務系統都和部署在IDC1機房的主站數據庫（包括Oracle和Dcache）連接，所以需在IDC1和IDC2機房同時部署監控服務器，監測數據庫狀態。監控服務器中部署檢測和切換系統，其部署方式如圖所示。

監控服務器同時連接業務系統的接口機和處理機。業務系統的接口機和處理機部署駐留程序，通過駐留程序檢測數據庫訪問成功率。

接口機、處理機數據庫訪問成功率：

（1）業務系統各個接口機、處理機節點定期上報數據庫訪問成功率數據給監控服務器的檢測系統，上報間隔要求可配置，默認為30S。

（2）監控服務器的切換系統根據檢測結果和判定規則，向告警網元發送故障告警。

（3）切換服務器決定是否切換。

檢測項結果定義：

節點數據庫訪問成功率：各個處理機節點的數據庫訪問成功率（X個節點）。

探測系統最終上報的關于數據庫探測結果內容如下：

[檢測結果項 來源 說明 備注 節點數據庫訪問成功率 各處理機節點 各個處理機節點的數據庫訪問成功率 根據實際情況，每次包含N個節點數據 ]

切換類型邏輯判定分自動切換和人工參與的半自動切換兩類。

（1）半自動切換場景

建議數據庫的各類異常，都要求人工參與判定，因為各類判定參數，只能做切換依據。

當然用戶也可以設置為自動切換。

（2）自動切換條件設置

數據庫自動切換判定規則：

監控檢測結果展示到可視化狀態管理界面，用戶可以查看。

如果選擇的人工切換，則顯示一鍵切換按鈕。否則顯示自動切換，用戶不可操作，只能查看狀態和日志。

當滿足數據庫切換條件時，監控服務器通知各個接口機及處理機節點進行數據庫訪問切換。

當主用數據庫恢復之后，需要將數據庫訪問進行回切。

數據庫切換流程為：

l 檢查數據庫恢復狀態

l 執行數據同步

l 通知各個接口機及處理機節點進行數據庫訪問切換

6 結束語

雙活系統架構設計應遵循必要的基本原則。應充分考慮網絡雙活、應用雙活、數據雙活三個層次，才能充分規避由于單出口網絡故障、應用服務器故障、數據庫錯誤造成的業務影響。其中難點和重點在數據庫雙活的設計和實現，在建成后的應急演練中，應充分模擬數據庫各種接口增刪改查操作，各層級故障現象的發生，以及數據庫整體切換演練。不斷優化工程中可能考慮不周的情況進行優化，最終實現系統長時間可靠的0中斷運行， RPO≈0，RTO≈0。以上是筆者在實踐基礎上的一些總結，對電信級兩地三中心系統建設中特別是大型數據庫雙活架構設計及實施工作的有效開展，具有積極的借鑒意義。

參考文獻：

[1] 梁凝，單曉強，孫疊.數據庫同步技術的研究[J].工業控制計算機，2017，30（7）：118-119，122.

[2] Futurewei Technologies Inc. Patent Issued for Decentralized Distributed Database Consistency[J].Information Technology Newsweekly，（USPTO 10，503，725）

[3] 朱紅.基于MySQL集群實現的高性能數據庫架構設計[D].上海：上海交通大學，2014.

【通聯編輯：王力】F5CDA0EE-B226-4D1F-9AD6-B0F99FF02FD8