基于開源關系數據庫的CMS高可用容災設計

文/趙強 王文崢

引言

中新網CMS目前每日上線用戶數約280人，日發稿萬條。每日新增數據庫記錄10萬筆以上，高峰期數據庫查詢達到500 QPS。由于中新網實行7×24小時不間斷發稿，一方面系統必須具備容災能力，主節點發生故障時需要能夠切換到備用節點繼續提供服務，另一方面要充分考慮備份產生的流量對帶寬的占用，以免在業務高峰期時影響業務正常開展。

1.CMS系統介紹

1.1 應用簡介

CMS系統是一套B/S結構的Web應用系統，以Apache作為Web服務器,后端采用Mysql開源數據庫作為核心的內容存儲。編輯人員在發布系統中上傳圖文視頻等各類稿件素材，經過排版編輯，設定各類欄目及選項,通過發布系統組織成為帶有格式的新聞頁面，經過多級審核后，將新聞頁面通過分發服務器生成靜態頁面分發至各瀏覽服務器中提供用戶訪問。

1.2 相關技術

1.2.1 MyISAM數據庫引擎

Mysql數據庫隨著功能的日益完善和可靠性的不斷提高，已經成為互聯網平臺上應用最廣泛的開源關系數據庫軟件。

Mysql使用的存儲引擎之一 MyISAM，相比其它存儲引擎，具備以下優勢：文件結構相對獨立，數據文件可被壓縮，節省存儲空間；跨平臺可移植性比較好，在備份和恢復時可單獨針對某個表進行操作，方便實施以文件為基礎的備份策略；查詢速度較快；當然，這種引擎也存在一定不足，包括：不支持事務；數據庫寫入時為表鎖定，不支持行級鎖定。

由于中新網CMS系統要求較高的查詢速度，且針對寫入時表鎖定的情況進行了分表處理，并對數據庫查詢、寫入已經做了大量優化工作。為提高整體運行效率，提升可維護性、可管理型，我們選擇使用MyISAM引擎作為Mysql的存儲引擎。1.2.2 rsync

rsync全稱 remote sync,是一種高效的遠程數據同步工具，rsync使用“rsync算法”來使本地和遠程文件達到同步，這個算法只傳送兩個文件的不同部分，而不是每次都整份傳送，因此傳送效率很高，而且可以通過ssh方式傳輸文件，安全性較好。

1.2.3 ElasticSearch

ElasticSearch是一個基于Lucene的搜索服務器，它不僅僅是全文搜索引擎，同時也是優秀的分布式實時文件存儲，ES的集群部署方式可以擴展到上百臺服務器，處理PB級結構化或者非結構化數據。

2.傳統的備份方案的不足

由于業務數據及結構原因，中新網CMS不能簡單的使用Mysql的主從機制進行數據庫備份系統的同步，所以數據庫數據的同步依靠傳輸數據庫文件來實現，但同時帶來的問題是，龐大的數據庫表中，我們只插入或者修改一小部分記錄的數據，從數據庫文件的角度上看是這個表文件發生了變化，文件級同步則系統對這個很大的數據庫文件做整體的差異分析及同步，雖然rsync技術可以只同步文件差異部分的內容，但從實際效果看，rsync對于分析mysql自行組織的二進制文件的分析并不精準，往往對一個表的輕微修改會帶來很大的傳輸量。同步數據一方面大量占用了網絡的帶寬資源，另一方面由于傳輸時間比較長，加之Mysql實例并不能將實時的內容刷新至磁盤文件，所以造成了備用系統與主庫依然存在較大差異。采用這種備份方式，會導致業務中斷時間很長，在發稿密度極高且24小時要求不中斷的情況下，這種備份方式是無法滿足業務需求的。

3.CMS高可用系統的設計與實現

3.1 系統高可用的業務指標

通常信息系統高可用能力用2個指標來衡量，包括 RTO（Recovery Time Object） 和 RPO(Recovery Point Object).指標的定義為∶（1）RTO（恢復時間目標），指定故障發生后，從業務停頓到系統恢復可以支持業務運作時兩點之間的時間段。

（2）RPO（恢復點目標），是指一個過去的時間點，當災難或緊急事件發生時，數據可以恢復到的時間點。

3.2 采用冗余、備份技術進行數據容災

冗余技術是利用系統的并聯模型來提高系統可用性的非常有效的手段,CMS系統的高可用結構也是基于冗余的思路設計實現，希望能夠實現兩個層級的冗余，第一層級為主機系統的冗余，第二層級為數據中心的冗余。

在Web系統中使用冗余結構的關鍵點在于數據的同步，數據同步的能力決定了RPO（恢復點目標），良好的同步策略要求RPO時間盡量接近、等于故障發生時間，達到業務數據的最小差異或者零差異，同時也要做到不會因為頻繁的數據同步帶來大量的網絡傳輸，占用服務器及網絡帶寬資源，從而影響到了業務生產的使用。

CMS系統的業務數據包括了應用程序、產生的業務數據文件（html頁面、圖片、視頻文件等）和數據庫。

3.2.1 冗余的部署結構

圖1

如圖1所示，CMS系統部署在兩個數據中心，實現了數據中心級別的冗余。網絡層面，主機到交換機，交換機到上層出口設備均使用了冗余線路連接。

主數據中心，部署了兩套CMS系統用于實現主機級別的冗余。

兩套Web系統部署在獨立的物理主機中，連接各自的數據庫，兩套系統均可以獨立工作，之間沒有任何業務的依賴和關聯，確保了當一套系統出現故障時，可以迅速的切換至備用系統

3.2.2 Binlog備份同步方案

數據的備份，同步使用操作系統的計劃任務程序實現，根據配置好的計劃任務配合rsync命令來實現各種同步策略。

詳細同步策略說明如下：

應用程序的同步策略，由于應用程序開發改造版本迭代沒有時間規律，為即刻使新版本程序生效，且不希望使用低效的 crontab 定時機制，造成高頻度的資源消耗，我們采用了Linux的signal 信號機制實現了這個功能，即新版本上傳至指定目錄后，系統自動偵測到文件有改動后，馬上啟動同步腳本將新的程序文件同步到同網段和異網段的備份主機中，快捷而高效，對系統的資源消耗較小。

數據庫全備份，數據庫的全備份在系統重構環節是必不可少的，但是數據庫全備份會對生產系統造成較大的影響，由于數據保有量極大，備份過程會造成30分鐘以上的系統“偽癱瘓”，無法承載高負荷的系統運行。所以，我們嚴格控制全備份的頻率，每天僅在凌晨2點進行一次數據庫的全備份腳本操作。

數據庫binlog文件同步，binlog日志記錄著數據庫所有DDL和DML語句，因此包含了數據結構和內容的變化，將binlog進行備份的意義在于，通過恢復binlog不但能夠保證數據庫的內容最終一致性，重要的是可以記錄數據變化的過程，一旦出現數據丟失、誤操作等情況，可以根據冷備份和binlog將數據完全還原，且Binlog日志收集傳輸與數據庫全備份的更大區別是，不會使系統運行緩慢，對業務影響很小。根據業務情況，我們設定binglog增量文件同步周期為5分鐘。

3.2.3 數據庫內容恢復

應急處理方案是備份恢復的重中之重，只有備份計劃，如果應急處理方案不合理，將直接影響整體容災方案的效果，無法滿足業務連續性。CMS系統分別針對不同的故障制定了對應的應急處理方案。

（1）當系統主節點出現宕機或者服務不可用時，zabbix監控和應用監控可以及時發現故障并通過短信，微信，郵件的方式告知運維人員。

（2）運維人員確認故障嚴重程度，如果短時（15分鐘以內）可以在本機進行故障的修復，則進行故障的修復。如果判斷為嚴重的系統或者硬件故障，無法短時在本機進行修復則啟動應急切換流程。

（3）根據應急切換流程將系統切換至備用系統中。

（4）在備用系統中驗證業務有效性

（5）備用系統上線提供服務

（6）業務系統恢復使用后，進行主節點系統的修復工作

修復完成后驗證主節點業務及數據情況

3.2.4 系統切換方法

在前面介紹的整體應急響應流程中，最關鍵的環節就是系統切換環節。備份策略的制定，都是為了在故障發生時能夠有效的進行系統切換。

（1）Web系統的切換

故障發生在CMS系統所在主機上，該網段其它設備狀況良好，則將同網段的備份系統啟用。之前的備份策略提到，備份系統中，應用程序以及應用程序所產生的數據文件都是實時同步，所以備用系統的web服務是實時可用的，web系統的切換方法為對調主備服務器的IP地址，這樣做的好處在于，只在OSI模型中的第三層IP層做了修改，對于上層應用沒有任何變化，對于DNS解析以及其它相關聯系統的調用沒有任何變更的感知，無需其它系統做任何調整既可以使備用的web系統上線使用。

如遇到數據中心級故障（如出口網絡設備故障、運營商線路故障、電力中斷等），web系統需要切換到異地機房的備份web系統中，此時需要修改系統的域名解析，并啟用備份系統，由于是內部系統，并使用了內部的DNS服務器，因此DNS生效時間可較短，根據目前DNS服務器設定的TTL時間為600秒。

（2）數據的切換及校驗

前文備份策略中提到，備份系統中的數據庫文件采用周期同步策略進行冷備，同機房和異地備份機房同步周期均為1天，如果只采用冷備數據作為備用系統的數據源，從RPO（恢復點目標）的指標來看數據差異過大，就相同機房而言，業務數據理論上最大會出現24小時的數據滯后，這對于CMS系統而言是不能接受的。因此需要進一步進行差異數據的恢復。

這里分別從數據庫視角和業務視角進行恢復和驗證，首先數據庫恢復程序對mysql數據庫完成細粒度的恢復，保證數據庫的條目完整，之后數據驗證程序會根據ElasticSearch中的具體業務數據（稿件，專題）等對數據的恢復的效果及完整性進行自動校驗。

3.3 數據恢復

數據恢復分為兩個步驟，數據庫全庫恢復及增量添加。

全庫恢復每天進行一次，在每日凌晨2點進行數據庫備份后，將運行文件同步腳本至備份主機，并進行數據庫的裝載和修復工作，使之達到可用狀態。

增量添加的基本流程：主系統產生的Binlog日志與備份系統進行5分鐘一次的實時同步。當主系統發生故障后，備份系統會導入當天凌晨2點以后的多個binlog文件增量數據，將差異數據進行恢復至最近的狀態。根據binlog日志恢復，確定當前備份系統mysql數據的最后寫入時間點，然后使用mysql自帶的mysqlbinlog工具導出為sql文件，使用此sql文件導入mysql數據庫完成數據的恢復。

3.4 數據自動校驗與回填

ElasticSearch數據庫集群，在網站的發布系統體系中，可承擔多重作用：

作為全文檢索數據庫。由于ElasticSearch(簡稱ES）構建于著名的開源全文數據庫Lucene，承擔網站全文檢索是非常自然的功能需求。

作為動態內容的展示平臺。大型資訊類網站新聞展示頁、首頁等頁面多以文件靜態方式呈現，而類似列表頁、更多頁這樣的頁面更適合采用動態的展示方式來呈現，當用戶瀏覽欄目頁、內容更多頁時，可使用ES來進行動態展示。

作為數據自動校驗工具。由于ES庫中保留著編輯所發的任何一條稿件及其主要版本，利用其這一特性，可用于在系統故障遷移完成后，自動對遷移后的數據庫完整性進行校驗，防止稿件丟失，這個對比過程可通過預先編寫好的腳本完成。此處主要詳細敘述ES作為數據校驗工具時的業務流程。

發布系統生成內容數據時，一邊將內容寫到mysql數據庫，同時也將關鍵的內容數據寫入到ES集群中，ES集群采用冗余結構部署，具有較高的可用性，單機故障不影響集群的健康使用。

發布系統數據庫恢復完成后，啟用數據自動檢查程序，檢查程序會對故障時間點到當前的業務數據逐條進行檢查，驗證mysql數據庫是否包含此條目，不同于mysql校驗的是，這里不是按照mysql的數據結構進行檢驗，而是按照實際業務發生的數據進行檢驗，也就是會從ES中按時間順序查出每條文稿信息，在mysql相關表中進行檢索，如果發現mysql數據庫中缺少相關記錄，則將缺少的內容補充到Mysql數據庫的記錄中。

3.5 備份方案實際演練及評估

備份方案的可行性需要真實的演練驗證，針對本系統，分別模擬CMS系統主節點單機故障和數據中心網絡故障。

（1）演練方法，對于系統單機故障，采用關閉主機的方法；數據中心網絡故障的模擬則直接修改web系統的dns解析記錄。

（2）演練效果

表1

如表1，記錄了CMS容災方案在實際演練中的RPO和RTO時間，我們可以看出，遇到web系統的故障，CMS系統容災和傳統的容災方案因為都采用了文件實時同步方式，所以恢復時間上沒有差距，但如果發生數據庫系統的故障或者數據中心級別的故障，CMS系統的RPO時間短于傳統的容災方案。RPO時間則明顯短于傳統容災方案，對于數據可用性帶來本質的提升。也就是說，當前CMS系統的容災方案可以做到當遇到嚴重的系統故障時，可以在10分鐘內恢復系統使用，并且20分鐘內可以將數據恢復至系統故障前的5分鐘內。