文/趙強 王文崢

引言

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

1.CMS系統(tǒng)介紹

1.1 應用簡介

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

1.2 相關技術

1.2.1 MyISAM數(shù)據(jù)庫引擎

Mysql數(shù)據(jù)庫隨著功能的日益完善和可靠性的不斷提高，已經(jīng)成為互聯(lián)網(wǎng)平臺上應用最廣泛的開源關系數(shù)據(jù)庫軟件。

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

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

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

1.2.3 ElasticSearch

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

2.傳統(tǒng)的備份方案的不足

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

3.CMS高可用系統(tǒng)的設計與實現(xiàn)

3.1 系統(tǒng)高可用的業(yè)務指標

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

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

3.2 采用冗余、備份技術進行數(shù)據(jù)容災

冗余技術是利用系統(tǒng)的并聯(lián)模型來提高系統(tǒng)可用性的非常有效的手段,CMS系統(tǒng)的高可用結(jié)構(gòu)也是基于冗余的思路設計實現(xiàn)，希望能夠?qū)崿F(xiàn)兩個層級的冗余，第一層級為主機系統(tǒng)的冗余，第二層級為數(shù)據(jù)中心的冗余。

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

CMS系統(tǒng)的業(yè)務數(shù)據(jù)包括了應用程序、產(chǎn)生的業(yè)務數(shù)據(jù)文件（html頁面、圖片、視頻文件等）和數(shù)據(jù)庫。

3.2.1 冗余的部署結(jié)構(gòu)

圖1

如圖1所示，CMS系統(tǒng)部署在兩個數(shù)據(jù)中心，實現(xiàn)了數(shù)據(jù)中心級別的冗余。網(wǎng)絡層面，主機到交換機，交換機到上層出口設備均使用了冗余線路連接。

主數(shù)據(jù)中心，部署了兩套CMS系統(tǒng)用于實現(xiàn)主機級別的冗余。

兩套Web系統(tǒng)部署在獨立的物理主機中，連接各自的數(shù)據(jù)庫，兩套系統(tǒng)均可以獨立工作，之間沒有任何業(yè)務的依賴和關聯(lián)，確保了當一套系統(tǒng)出現(xiàn)故障時，可以迅速的切換至備用系統(tǒng)

3.2.2 Binlog備份同步方案

數(shù)據(jù)的備份，同步使用操作系統(tǒng)的計劃任務程序?qū)崿F(xiàn)，根據(jù)配置好的計劃任務配合rsync命令來實現(xiàn)各種同步策略。

詳細同步策略說明如下：

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

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

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

3.2.3 數(shù)據(jù)庫內(nèi)容恢復

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

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

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

（3）根據(jù)應急切換流程將系統(tǒng)切換至備用系統(tǒng)中。

（4）在備用系統(tǒng)中驗證業(yè)務有效性

（5）備用系統(tǒng)上線提供服務

（6）業(yè)務系統(tǒng)恢復使用后，進行主節(jié)點系統(tǒng)的修復工作

修復完成后驗證主節(jié)點業(yè)務及數(shù)據(jù)情況

3.2.4 系統(tǒng)切換方法

在前面介紹的整體應急響應流程中，最關鍵的環(huán)節(jié)就是系統(tǒng)切換環(huán)節(jié)。備份策略的制定，都是為了在故障發(fā)生時能夠有效的進行系統(tǒng)切換。

（1）Web系統(tǒng)的切換

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

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

（2）數(shù)據(jù)的切換及校驗

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

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

3.3 數(shù)據(jù)恢復

數(shù)據(jù)恢復分為兩個步驟，數(shù)據(jù)庫全庫恢復及增量添加。

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

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

3.4 數(shù)據(jù)自動校驗與回填

ElasticSearch數(shù)據(jù)庫集群，在網(wǎng)站的發(fā)布系統(tǒng)體系中，可承擔多重作用：

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

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

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

發(fā)布系統(tǒng)生成內(nèi)容數(shù)據(jù)時，一邊將內(nèi)容寫到mysql數(shù)據(jù)庫，同時也將關鍵的內(nèi)容數(shù)據(jù)寫入到ES集群中，ES集群采用冗余結(jié)構(gòu)部署，具有較高的可用性，單機故障不影響集群的健康使用。

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

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

備份方案的可行性需要真實的演練驗證，針對本系統(tǒng)，分別模擬CMS系統(tǒng)主節(jié)點單機故障和數(shù)據(jù)中心網(wǎng)絡故障。

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

（2）演練效果

表1

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