作者：人月神話，新浪博客同名

簡介：多年SOA規劃建設，私有云PaaS平臺架構涉及經驗，長期從事一線項目實踐

今天談下多數據中心和異地容災備份方面的內容。在前面一篇文章里面我詳細談到過一個軟件業務系統的高可用性設計，其中既包括了IT基礎設施的高可用，也包括了業務軟件系統設計方面的高可用性設計。

對于高可用，我想再簡單總結下，核心為三個方面的內容：

• 高可靠：冗余性設計，無任何單點故障
• 高性能：能夠滿足大數據量或海量并發訪問下響應需求
• 高擴展：能夠動態水平彈性擴展

對于三者之間的關系，我前面整理過下面一個圖來進一步說明：

上圖可以看到高可靠，高性能和高擴展性三者之間的關系。

對于高可靠性來來說，傳統的HA架構，冗余設計都可以滿足高可靠性要求，但是并不代表系統具備了高性能和可擴展性能力。反過來說，當系統具備了高擴展性的時候，一般我們在設計擴展性的時候都會考慮到同時兼顧冗余和高可靠，比如我們常說的集群技術。

對于高性能和高擴展性兩點來說，高擴展性是高性能的必要條件，但是并不是充分條件。一個業務系統的高性能不是簡單的具備擴展能力就可以，而是需要業務系統本身軟件架構設計，代碼編寫各方面都滿足高性能設計要求。

對于高可靠和高性能，兩者反而表現出來一種相互制約的關系，即在高性能支撐的狀態下，往往是對系統的高可靠性形成嚴峻挑戰，也正是這個原因我們會看到類似限流熔斷，SLA服務降級等各種措施來控制異常狀態下的大并發訪問和調用。

容災備份概述

前面談高可靠性可以看到，我們更多的還是談的在一個數據中心里面的冗余和集群設計，以確保整個IT基礎設施架構沒有任何的單點故障。但是如果整個數據中心都出現問題，那么我們的應用自然會受到影響處于不可用狀態，同時我們的數據存儲也存在丟失的問題。

這也是我們談容災備份，很多大的集團企業建設自己的兩地三中心的一個原因。

什么是容災備份？

對于容災，簡單來說就是當數據中心發生各種未知災難的時候，能夠確保數據不丟失或少丟失，同時IT業務系統能夠不間斷運行或快速切換恢復。

這里面實際上強調了兩個重點， 即：

• 數據本身不丟失或少丟失
• 應用本身不間斷或少間斷

整個容災設計就是圍繞這兩個關鍵目標來實現。

而對于容災備份則是通過在異地建立和維護一個備份存儲系統，利用地理上的分離來保證系統和數據對災難性事件的抵御能力。

根據容災系統對災難的抵抗程度，可分為 數據容災和應用容災 。

• 數據容災是指建立一個異地的數據系統
• 應用容災比數據容災層次更高，即在異地建立一套完整的、與本地系統相當的備份系統

當前可以看到，我們更多的已經不再是間斷的數據層面的容災備份，而是需要具備保持業務連續性的應用級容災能力。

簡單來說，就是我們需要設計要整體應用所涉及到的IT基礎設施，數據庫，應用中間件和應用部署包全部在2個數據中心進行部署。部署完成的架構需要確保即使某一個數據中心完全癱瘓，也不應該影響到業務系統的正常運行和連續性。

對于容災等級的定義可以參考下圖：

從圖中可以看到，如果要實現業務系統本身的異地雙活和不間斷運行，那么就必須達到第七級的異地同步應用容災的標準。即是：

在異地建立一個與生產系統完全相同的備用系統，他們之間采用同步的方式進行數據復制。當生產中心發生災難時，備用系統接替其工作。該級別的容災，在發生災難時，可以基本保證數據零丟失和業務的連續性。

也正因為如此，我們看到，多數據中心之間的數據庫同步復制能力將是構建一個異地同步容災備份設計的關鍵內容。

數據庫同步復制技術

前面已經談到，要實現應用級的容災備份，一個關鍵就是通過數據庫的實時同步和復制，在A地出現機房故障和問題的時候可以平滑快速的遷移到B地。雖然這種遠程數據復制和同步存在一定的延遲，但是基本已經可以滿足業務連續性的需求。

談到數據庫的實時復制，一般會談到一個重要產品，即Oracle公司的GoldenGate，該軟件是一種基于日志的結構化數據復制軟件，它通過解析源數據庫在線日志或歸檔日志獲得數據的增刪改變化，再將這些變化應用到目標數據庫，實現源數據庫與目標數據庫同步、雙活。

GoldenGate可以在異構的IT基礎結構（包括幾乎所有常用操作系統平臺和數據庫平臺）之間實現大量數據亞秒一級的實時復制。

GoldenGate是一種基于軟件的數據復制方式，它從數據庫的日志解析數據的變化（數據量只有日志的四分之一左右）。該將數據變化轉化為自己的格式，直接通過TCP/IP網絡傳輸，無需依賴于數據庫自身的傳遞方式，而且可以通過高達9:1的壓縮率對數據進行壓縮，可以大大降低帶寬需求。在目標端，GoldenGate TDM可以通過交易重組，分批加載等技術手段大大加快數據投遞的速度和效率，降低目標系統的資源占用，可以在亞秒級實現大量數據的復制。

GoldenGate的工作原理可以用下圖描述：

在任何實時數據同步和復制中，需要考慮如下幾個關鍵問題：

• 事務一致性：在復制目標端需要按照源端相同的事務環境進行，確保目標上數據一致性。
• 檢查點機制：在抽取和裝載時都需要記錄檢查點，確保網絡故障下仍然能夠完整復制。
• 可靠數據傳輸：需要保證數據傳輸的完整性，請求和應答，同時提供數據加密壓縮。

對于數據實時同步和復制工具，其核心是需要基于日志來實現，這一方面是可以實現準實時的數據同步，一方面是基于日志實現不會要求數據庫本身在設計和實現中帶來任何額外的約束。我們也看到有些基于數據庫表設計增加觸發器或存儲過程來實現的數據庫復制，這些本身都是損耗了性能和增加了復雜度。

對于數據庫的實時同步和復制，阿里巴巴專門有一個開源項目，即otter來實現分布式數據庫的同步復制，其核心思想仍然是通過獲取數據庫的增量數據日志，來進行準實時的同步復制。因此otter本身又依賴于另外一個開源項目即canal，該項目重點則是獲取增量數據庫同步日志信息。

當前otter的重點是實現mysql間的數據庫同步復制，其實這個在前面我一些文檔里面談到基于mysql數據庫的dual-master架構的時候已經談到過，基本即利用的類似技術來實現兩個mysql數據庫間的雙向同步數據庫復制。

要注意這個雙向本身指既可以A->B，也可以從B->A，在某個時間節點本身是單向的。

對于otter的功能和支持的數據庫比GoldenGate要少得多，除了支持mysql數據庫間的實時數據同步和復制外，還支持mysql->oracle的單向數據同步和復制。但是不支持oracle->mysql的數據同步和復制。但是otter本身提供了一個很好的開源框架，我們可以基于該框架擴展對其它數據庫的支持。

在擴展的時候有一個重點，即數據庫本身是否提供了增量數據日志，對于mysql數據庫容易實現其主要原因還是mysql數據庫提供了相當方便的binlog日志功能，這些log日志本身就很方便的轉換為朝目標端執行的sql語句。

而對于常見的數據庫，在網上搜索下，可以看到一些做法。

對于oracle，重點是監控oracle的redo log，即在線重做日志和歸檔日志。對于一些商用產品可以直接監控到redo log，僅僅依賴于該文件而不耗費其它資源。而如果我們來實現，則常用的方法還是基于oracle logminer來對redo log進行解析。雖然性能上稍微有差異，但是基本可以達到準實時的數據庫解析和同步。

對于Sql Server數據庫的日志分析，首先可以看到網上有一個專門的商業工具，即log explorer，這個工具可以用來做sql server數據庫的日志解析和分析。其中對于事務，檢查點等都有詳細的記錄。其次可以使用fn_dblog解析Sql Server的數據庫日志，網上有專門的方法在這里不展開，現在還沒有具體測試過，但是整個方法思路是沒有問題的。

而對于sql server 之間的數據庫同步和復制，則sql server本身就提供有方便的基于快照或基于事務的數據庫同步復制工具，只需要經過簡單的配置即可以實現。正因為這個原因，我們也看到，對于sql server數據庫本身在日志解析和分析方面開放出來的能力本身是相當較弱的。

隨著國家對自主研發數據庫和中間件技術的大力支持，當前還沒一個能夠實現國產數據庫如人大金倉，達夢數據庫同國外的oracle ,sql server數據庫間的數據實時同步和復制工具。對于這類工具是可以基于開源otter產品的思路來進行定制開發和實現的，但是前提還是各個數據庫廠家需要開放相應的日志采集和處理能力。

基于GoldenGate實現數據庫同步復制

GoldenGate TDM（交易數據管理）軟件是一種基于日志的結構化數據復制軟件，它通過解析源數據庫在線日志或歸檔日志獲得數據的增刪改變化，再將這些變化應用到目標數據庫，實現源數據庫與目標數據庫同步、雙活。

GoldenGate TDM 軟件可以在異構的IT基礎結構（包括幾乎所有常用操作系統平臺和數據庫平臺）之間實現大量數據亞秒一級的實時復制，其復制過程簡圖如下：

GoldenGate TDM的數據復制過程如下：

利用捕捉進程(Capture Process)在源系統端讀取Online Redo Log或Archive Log，然后進行解析，只提取其中數據的變化如增、刪、改操作，并將相關信息轉換為GoldenGate TDM自定義的中間格式存放在隊列文件中。再利用傳送進程將隊列文件通過TCP/IP傳送到目標系統。捕捉進程在每次讀完log中的數據變化并在數據傳送到目標系統后，會寫檢查點，記錄當前完成捕捉的log位置，檢查點的存在可以使捕捉進程在終止并恢復后可從檢查點位置繼續復制；

目標系統接受數據變化并緩存到GoldenGate TDM隊列當中，隊列為一系列臨時存儲數據變化的文件，等待投遞進程讀取數據；

GoldenGate TDM投遞進程從隊列中讀取數據變化并創建對應的SQL語句，通過數據庫的本地接口執行，提交到數據庫成功后更新自己的檢查點，記錄已經完成復制的位置，數據的復制過程最終完成。

由此可見，GoldenGate TDM是一種基于軟件的數據復制方式，它從數據庫的日志解析數據的變化（數據量只有日志的四分之一左右）。GoldenGate TDM將數據變化轉化為自己的格式，直接通過TCP/IP網絡傳輸，無需依賴于數據庫自身的傳遞方式，而且可以通過高達9:1的壓縮率對數據進行壓縮，可以大大降低帶寬需求。在目標端，GoldenGate TDM可以通過交易重組，分批加載等技術手段大大加快數據投遞的速度和效率，降低目標系統的資源占用，可以在亞秒級實現大量數據的復制，并且目標端數據庫是活動的

GoldenGate TDM提供了靈活的應用方案，基于其先進、靈活的技術架構可以根據用戶需求組成各種拓撲結構，如圖所示：

GoldenGate TDM 可以提供可靠的數據復制，主要體現在下面三點：

保證事務一致性

GoldenGate TDM 在災備數據庫應用復制數據庫交易的順序與在生產中心數據庫上的順序相同，并且按照相同的事務環境提交，確保在目標系統上數據的完整性和讀一致性，為實時查詢和事務處理創造了條件。

檢查點機制保障數據無丟失

GoldenGate TDM的抽取和復制進程使用檢查點機制記錄完成復制的位置。對于抽取進程，其檢查點記錄當前已經抽取日志的位置和寫隊列文件的位置；對于投遞進程，其檢查點記錄當前讀取隊列文件的位置。檢查點機制可以保證在系統、網絡或GoldenGate TDM進程故障重啟后數據無丟失。

可靠的數據傳輸機制

GoldenGate TDM 用應答機制傳輸交易數據，只有在得到確認消息后才認為數據傳輸完成，否則將自動重新傳輸數據，從而保證了抽取出的所有數據都能發送到備份端。數據傳輸過程中支持128位加密和數據壓縮功能。

Oracle 公司的GoldenGate產品，可以在異構的IT基礎結構之間實現大量數據的秒一級的數據捕捉、轉換和投遞。GoldenGate可以支持幾乎所有常用操作系統如和數據庫平臺：

操作系統支持：MS NT, 2000, XP, Linux, Sun Solaris, HP-UX, IBM AIX, HP NonStop, TRU64, IBM z/OS，OS/390 數據庫支持： Oracle, DB2, MS SQL Server, MySQL, Enscribe, SQL/MP, SQL/MX, Sybase, Teradata, 其他ODBC 兼容數據庫

GoldenGate的應用場景-容災和應急備份

其中一主一備，快速恢復和切換，最小化數據損失，重新同步主備兩端數據。主庫數據變化能夠實時的同步到備庫，用途主要是在非計劃性停機時候保持業務的連續性。

GoldenGate的應用場景-減少計劃內停機

主要是保障業務零或近似零停機，在滾動升級中降低業務中斷帶來的損失。主要用途是保障系統/應用/數據庫在升級，移植和維護期間業務的可用性。

GoldenGate的應用場景-雙業務中心

主要是實現負載均衡（需要考慮全局多點的負載均衡，既提高性能，又避免業務中心的整體單點故障），提供系統整體性能。保障連續可用，快遞的容災接管，實現沖突的監測和處理。

業務系統數據庫雙活和主備設計

首先我們還是回顧下業務系統容災備份設計的目標究竟是什么？

簡單來講就是要避免在單個數據中心出現無預知災難的時候，整個數據不丟失，整個應用仍然能夠正常持續運行。而對于持續不間斷運行，我們仍然可以分為兩個層面。

• 完全不間斷，自動實現切換，對業務無感知
• 短暫間斷，需要人工手工切換負載均衡或IP地址完成

對于生產運營類的企業IT系統需要做到完全不間斷，而對于內部管理類的信息系統往往做到短暫間斷也可以接受。比如我們常說的電信運營商的BSS域系統，那么就需要做到完全不間斷自動切換，而對于MSS域圍繞ERP管理系統等，能在30分鐘內完成切換調整就可以滿足需求。

對于一個雙業務中心的設計，可以看到里面有兩個重點，一個就是數據庫本身的雙活設計，還有一個就是應用服務器集群本身的雙活設計。

數據庫雙活或主備設計

圖片來源網絡

對于數據庫本身的技術種類，對雙活讀寫的支持，數據延遲的大小，可靠性等可以參考上圖進一步了解。在考慮雙活數據庫設計的時候可以重點參考。

對于雙業務中心和異地雙活設計，前面我很多文章都已經談到過，實際上最難的就是數據庫如何保證雙活，大部分的異地容災方案數據庫本身都是單活的，一個作為備份庫。

對于數據庫雙活和主備設計，實際上在數據庫層面分為三個層面。

1. 數據庫單活：一個做為備份庫，平時不工作，在出現問題再動態切換
2. 數據庫寫單活，讀雙活：只有主庫可以寫，但是兩個數據中心數據可以同時讀
3. 數據庫雙活：即表格里面談到的Oracle ASM Extended RAC方案，這個沒怎么接觸過

對于應用服務器的Cluster集群，實際要做到雙活就比較簡單，由于不存在數據持久化的問題，因此只需要搭配上層的全局負載均衡往往就容易實現上層應用服務器集群的雙活配置。

方式1：通過GoldenGate來實現數據庫單活設計

對于GoldenGate既支持數據單向復制，也支持數據庫雙向同步復制。

我們可以通過數據庫單向復制來實現數據庫的主備模式雙活，即一個作為Master主節點數據庫，一個作為Standby的備庫。如下：

當主庫出現無法預知的災難故障的時候，我們可以將訪問切換到備庫節點上，在主庫節點恢復后備庫節點重新返回備庫模式，前端訪問用戶也重新連回到主庫節點。

也就是說在主庫恢復后，實際上還有一個過程即：

備庫上所做出的修改和更新需要實時同步更新回主庫。

因此雖然說這種模式是數據庫單向復制，實際上是指在某一個時點只允許一個方向的數據流。而不是說數據只能夠從主節點朝備節點同步。

方式2：通過GoldenGate來實現數據庫雙活設計

對于數據庫雙活設計即可以采用GoldenGate數據庫雙向同步復制來實現。實際上我們并不建議這種方式，主要是以下幾個方面的考慮。

即在數據雙向復制的情況下對應用系統本身的設計會有額外的要求，比如全局序列號的起始值的規劃，如何防止數據循環復制，如果網絡存在延遲，如何確保一個大的業務操作實時的數據一致性要求等。這些往往都是雙活數據庫本身存在的問題。

其次，在數據庫雙活設計下，應用集群和數據庫間往往存在兩種方式如下：

對于方式1即應用集群只固定訪問同數據中心的數據庫，對于方式2即應用集群全部訪問上層兩個數據庫暴露的VIP地址，通過VIP來確定訪問兩個數據庫。

對于方式1我們看到，實際上在數據庫中心A的數據庫宕機后，由于應用集群可能沒有宕機，那么全局負載均衡仍然會分發路由請求給應用集群A，這個時候實際仍然出現訪問中斷的情況。

而對于方式2采用了數據庫VIP后，雖然解決了上面的問題，但是很容易出現應用集群A要跨域訪問到數據庫中心B的數據庫服務的情況。

也就是在采用浮動VIP時候，希望是要做到應用集群A優先訪問數據庫A，只有當數據庫A出現故障的時候才路由訪問數據庫B。

方式3：不采用GoldenGate的思路

如果不采用GoldenGate，那么我們就需要手工去處理以保證兩個數據庫間的數據同步復制。在我們實施ESB服務總線項目的時候，由于數據庫實例本身無狀態和一致性要求，因此我們完全可以采用晚上定時進行數據庫增量腳本同步的方式來同步數據。

其次，對于修改元數據的相關操作，則需要應用程序同時在兩個數據中心的數據庫同時進行操作，這個同時操作也可以通過應用自動實現，也可以人工同時操作，畢竟對元數據配置修改往往本身就是低頻操作。

全局負載均衡和智能DNS路由

當我們談雙活數據中心的時候，前面更多談的數據庫的部署和同步方案，既然是雙活，那么APP Server應用服務器就必須要做到能夠同時工作。而對于應用服務器集群我們考慮的時候要注意，實際上在我們配置的時候，數據中心A和數據中心B兩個集群都是操作數據中心A的數據庫，否則就會出現數據庫雙向同步復制問題。

要做到應用集群雙活，在前面文章方案已經談到，必須在數據庫中心A和B上面還有一個全局的負載均衡設備進行全局負載均衡，同時全局負載均衡設備本身還需要HA配置確保無單點故障。

對于最終用戶的訪問，我們企業DNS域名進行訪問。

同時在兩個數據中心配置智能DNS設備，本身進行HA架構冗余設計，如下。

智能DNS設備實際上要完成的事情很簡單，就是用戶通過域名訪問，智能DNS能夠返回具體某個數據中心的上層負載均衡IP地址信息。

我們以單活架構來進行說明如下：

• 用戶通過域名訪問，將請求發送給智能DNS解析設備
• 智能DNS在主數據中心正常情況下返回主數據中心的負載均衡IP地址
• 在獲取到IP地址后，應用再發起對主數據中心的實際業務訪問

如果主數據中心本身出現災難宕機。

那么這個時候請問到DNS的時候則返回數據中心B的負載均衡IP地址信息。這個時候備庫數據庫自動變化為主庫承擔應用的讀寫任務。

應用集群本身的Admin設置和應用部署

對于應用服務器集群，往往會有一個Admin集群管理節點，通過Admin可以實現對應用集群內所有節點的狀態監控，應用的部署，負載均衡等相關操作。

即使我們采用了類似F5等負載均衡設備，往往集群仍然需要設置管理節點以方便集群監控和應用程序的部署。

那么在啟用雙數據中心后可以看到，對于Admin節點建議仍然是在兩個數據中心各自一套，即應用程序的更新和部署仍然在兩個數據中心各自手工部署來完成。特別是在主備模式下，這種手工方式處理基本沒有任何影響。

但是如果在雙活架構模式下，如果手工完成往往就存在一定的延遲性的問題。

這個實際又有兩種解決方案和思路。

• 其一是通過一個Admin來管理兩個數據庫的所有集群節點
• 其二是通過灰度發布策略等方法來控制部署時間上的延后

對于第一種方式實際我們不建議，其本身增加了了兩個數據中心集群的耦合度，同時本身管理的復雜度，集群本身的狀態一致性保證復雜度都會增加。最好的方式仍然是通過灰度發布等策略控制來解決該問題。

---

歡迎關注@人月聊IT 分享SOA，微服務，DevOps平臺規劃和建設。

總結

以上是生活随笔為你收集整理的谈谈双活业务中心和异地容灾备份设计谈谈双活业务中心和异地容灾备份设计的关系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。