政企OA文件存儲的新方法

劉天成，凌書平，羅 平

（1.湛江幼兒師范?？茖W(xué)校信息與科學(xué)系，湛江 524084；2.中國移動通信集團(tuán)廣東有限公司湛江分公司，湛江 524043）

0 引言

現(xiàn)有政企OA系統(tǒng)普遍采用傳統(tǒng)FTP文件存儲方式。該方式存在存儲容量受限、文件冗余存放、文件缺乏跨單位和跨系統(tǒng)共享能力等缺點，不適應(yīng)在龐大規(guī)模的系統(tǒng)群使用。政企OA公文交換量快速上升，平臺存儲量快速增長，造成平臺存儲資源緊缺。政企OA系統(tǒng)里很多數(shù)據(jù)都是重復(fù)保存的，如果將重復(fù)數(shù)據(jù)所占用的空間節(jié)約下來，相同文件只保留一份，或只保留一份備份，則可節(jié)約大量存儲空間。因此，在存儲資源緊缺的情況下平臺存儲改造勢在必行。

為解決小文件過多所造成的系統(tǒng)元數(shù)據(jù)過大的問題，文獻(xiàn)［1］基于容器技術(shù)，提出了存儲海量中小型文件分布式存儲系統(tǒng)，該系統(tǒng)適用于超算環(huán)境下的各種渲染任務(wù)，但沒提出針對多種存儲兼容和控制冗余存儲的解決方案。為解決云存儲中數(shù)據(jù)存儲冗余的問題，文獻(xiàn)［2］提出了一種將完全備份與糾刪碼結(jié)合的策略，該策略能較好地節(jié)省存儲空間并實現(xiàn)負(fù)載均衡。但文獻(xiàn)沒提出高并發(fā)和備份策略的具體實施代碼方案。

為解決前述問題，本文對現(xiàn)有政企OA系統(tǒng)的應(yīng)用系統(tǒng)、數(shù)據(jù)庫系統(tǒng)和存儲系統(tǒng)進(jìn)行了優(yōu)化，使得政企OA系統(tǒng)占用的存儲資源大大減小。

1 整體技術(shù)方案

目前政企OA產(chǎn)品體系主要是以單服務(wù)模式開發(fā)的，每家單位都有獨立的應(yīng)用服務(wù)層、數(shù)據(jù)庫層和文件存儲層。各家單位系統(tǒng)是獨立部署、相互隔離的。為控制文件存儲的冗余，技術(shù)方案需將這三層原本分離的結(jié)構(gòu)統(tǒng)一起來，采取集中化模式加以優(yōu)化，并基于此提出了地址轉(zhuǎn)換兼容方案，方案結(jié)構(gòu)如圖1所示。

圖1 結(jié)構(gòu)優(yōu)化方案

系統(tǒng)共分三層，每個層的優(yōu)化方案如下：

（1）應(yīng)用層。為兼容原有FTP訪問，采用雙地址存儲方法，在保留原有FTP存儲地址的基礎(chǔ)上，增加了云存儲地址。當(dāng)存在云存儲地址時，優(yōu)先使用云存儲地址訪問，否則采用舊的FTP地址訪問。

（2）數(shù)據(jù)庫層。政企OA的數(shù)據(jù)庫在原來基礎(chǔ)上增加一列字段，用于存儲新的地址。

（3）文件存儲層。將舊文件遷移到云存儲中。新文件統(tǒng)一采用新云存儲方式。云存儲支持冗余控制。

2 實施辦法

2.1 應(yīng)用系統(tǒng)優(yōu)化

新舊文件系統(tǒng)兼容可采用指定兼容和自動兼容模式。指定兼容是指用系統(tǒng)的配置文件指定文件訪問采用何種模式。由于系統(tǒng)已有大量歷史數(shù)據(jù)，短期全部遷移不現(xiàn)實，不能采用指定單一訪問模式。因此方案采用自動兼容模式，自動判斷是否存在云存儲地址。如有云存儲地址，則優(yōu)先采用云存儲文件下載。自動兼容模式能有效提升系統(tǒng)的魯棒性。具體實施如下：

（1）搭建FastDFS云存儲文件服務(wù)中心

目前已有的較為成熟的商用開源云存儲技術(shù)主要有HDFS，MongoDB，F(xiàn)astDFS，HBase等。在OA產(chǎn)品云平臺上引入和部署FastDFS集群，能夠使存儲實現(xiàn)橫向擴(kuò)展，克服原來單臺FTP服務(wù)器的服務(wù)瓶頸，并能提供良好的擴(kuò)展能力，容災(zāi)能力，彈性存儲能力。在整個集群中，Tracker服務(wù)器承擔(dān)文件訪問負(fù)載均衡管理，而Storage服務(wù)器負(fù)責(zé)文件數(shù)據(jù)存儲管理。為了實現(xiàn)文件系統(tǒng)的容災(zāi)能力，Tracker集群和Storage集群分別使用省市兩個不同的云平臺主機(jī)和存儲，確保某個云平臺故障時，文件系統(tǒng)的高可用性。集群配置如下：

1）Tracker集群。政企OA等900多個應(yīng)用服務(wù)通過訪問FASTDFS的Tracker集群，獲取存儲的文件管理信息。Tracker集群部署了六臺應(yīng)用服務(wù)器，能確保訪問的穩(wěn)定性和吞吐量。

2）Storage集群。Storage集群由多組卷組成，每組卷內(nèi)部署兩臺相同的服務(wù)主機(jī)。兩臺服務(wù)主機(jī)互為備份，取代了原有的NBU備份方式。同時，卷內(nèi)兩臺主機(jī)同時對外提供服務(wù)，備份資源也沒有浪費，吞吐量為原有的兩倍。

（2）增加應(yīng)用系統(tǒng)參數(shù)配置，支持應(yīng)用系統(tǒng)三種存儲模式

由于OA系統(tǒng)有成千家應(yīng)用單位，約12 TB的數(shù)據(jù)需要從FTP文件系統(tǒng)遷移到云存儲系統(tǒng)，同時需修改數(shù)據(jù)庫的存儲地址。目前政企OA使用的集群為本地UAP，文件遷移無法在短期內(nèi)實現(xiàn)，需要一段較長的時間遷移。因此就要保證在過渡期間系統(tǒng)能夠自動切換使用合適的下載方式。

為了支持系統(tǒng)的自動切換，OA系統(tǒng)設(shè)置了三種存儲模式，分別為FTP，Route和DFS。這三種模式限定系統(tǒng)的訪問方式，當(dāng)系統(tǒng)處于Route模式下時，能夠自動切換為優(yōu)先從云存儲下載；如無法下載，則從FTP下載。

1）FTP模式。文件數(shù)據(jù)僅從FTP服務(wù)器上傳下載，適用于還未進(jìn)行文件遷移的單位。

2）Route模式。文件數(shù)據(jù)優(yōu)先從云存儲集群下載，如無法下載，則從FTP服務(wù)器下載。文件數(shù)據(jù)同時上傳到云存儲服務(wù)器和FTP服務(wù)器。適用于處于文件遷移過渡期間的單位。

3）DFS模式。文件數(shù)據(jù)從云存儲集群下載。文件僅上傳到云存儲服務(wù)器，不再上傳到FTP服務(wù)器。

4）測試結(jié)果。系統(tǒng)通過壓力測試腳本，在150個線程連接云存儲系統(tǒng)的情況下，150個線程均能正常無出錯下載文件。在互聯(lián)網(wǎng)環(huán)境下測試超大附件下載，下載均速達(dá)到2MB/s，表明系統(tǒng)性能達(dá)到要求。系統(tǒng)調(diào)整應(yīng)用系統(tǒng)代碼，支持三種模式：FTP、Route和DFS。三種模式下，系統(tǒng)均正常運行。在Route模式下，當(dāng)DFS沒有文件，F(xiàn)TP有文件，或DFS有文件，而FTP沒有文件時，均能正常從云存儲下載文件。

文件系統(tǒng)支持批量文件下載，原有的方式為應(yīng)用系統(tǒng)文件下載，這種方式下客戶日常的文件導(dǎo)出數(shù)量較大，容易產(chǎn)生系統(tǒng)卡死問題。為解決該問題，系統(tǒng)使用延后下載模式，選擇在系統(tǒng)空閑時實現(xiàn)文件下載。具體通過以下方式實現(xiàn)：

（1）開發(fā)延后批量下載模式

批量下載公文數(shù)量較多時，由于存儲系統(tǒng)讀寫速度以及帶寬的限制，容易造成服務(wù)器運行緩慢，影響其他用戶正常使用的問題。為了實現(xiàn)高速的批量下載，同時不影響忙時其他用戶的使用，采用延后至閑時批量下載模式。在該模式下用戶首先向應(yīng)用服務(wù)器提出批量下載文件請求，此時應(yīng)用服務(wù)器并沒有向云存儲系統(tǒng)提出批量下載文件請求，而是先設(shè)定定時，并通知用戶定時任務(wù)已設(shè)定。定時時間到后應(yīng)用服務(wù)器再向云存儲系統(tǒng)請求下載文件，應(yīng)用服務(wù)器接收到文件后再通知用戶下載。

（2）開發(fā)批量下載腳本

在原有FTP存儲的方式下，按照對應(yīng)單位的文件夾，以及文件夾下對應(yīng)的日期實現(xiàn)批量文件導(dǎo)出功能。但改為云存儲模式以后，不同單位、不同時間的文件混放在一起，無法通過復(fù)制文件夾的方式批量拷貝導(dǎo)出。為了解決批量文件導(dǎo)出的問題，在前端增加了生成批量導(dǎo)出文件列表功能。當(dāng)用戶選擇區(qū)間批量下載時，應(yīng)用系統(tǒng)搜索符合條件的所有文件名稱、類型、所屬單位、附件列表等資料，系統(tǒng)直接生成計劃任務(wù)，調(diào)用批量下載腳本批量導(dǎo)出文件。批量下載腳本執(zhí)行時間設(shè)定為系統(tǒng)閑時8：00pm—8：00am，采用排隊方式執(zhí)行，避免因資源相互競爭而導(dǎo)致死鎖問題。

在OA系統(tǒng)前端分別對10個不同單位的100份文件進(jìn)行導(dǎo)出測試。系統(tǒng)生成10個計劃任務(wù)，在8：00pm開始順序執(zhí)行。從統(tǒng)計結(jié)果來看，系統(tǒng)批量導(dǎo)出時間平均為463 s，最短180 s，最長670 s。

2.2 數(shù)據(jù)庫系統(tǒng)優(yōu)化

云文件存儲地址可采用“新表關(guān)聯(lián)”和“增加列”兩種方式，通過對兩種查找云文件存儲地址的方案進(jìn)行性能對比，可知“增加列”方式在編輯多條地址時速度較快。為提高數(shù)據(jù)庫并發(fā)性能，本文采用了“增加列”的方式來優(yōu)化數(shù)據(jù)庫系統(tǒng)。

為從FTP的存儲平滑地切換到云文檔的存儲，在文件記錄中同時記錄云存儲的地址。當(dāng)文件的兩個地址都存在時，優(yōu)先選擇FastDFS；當(dāng)僅有FTP地址時，維持原有訪問方式，用于兼容原有的FTP訪問方式，確保數(shù)據(jù)在遷移過程中無縫銜接。

除在數(shù)據(jù)庫表中增加云存儲的地址以外，對文件訪問模塊包進(jìn)行替換升級，支持多種訪問模式，自動切換使用。新增一個FileUtil的訪問類封裝文件的上傳下載，該類調(diào)用到封裝FTP訪問的類和封裝云盤訪問的類。然后再根據(jù)地址的情況進(jìn)行訪問控制，如FastDFS地址為空，則訪問FTP上的文件；如果FastDFS地址非空，則優(yōu)先訪問FastDFS列的地址。

由于云存儲存放地址邏輯與FTP不相同，需要將文件從FTP遷移到云存儲上。此外，各單位的文件數(shù)量差異較大，文件遷移時間不同。為保證客戶對數(shù)據(jù)的正常使用，設(shè)定在每天00:00am—7:00am時段進(jìn)行數(shù)據(jù)遷移。每天早上對遷移的單位進(jìn)行統(tǒng)計，并對無法遷移的文件進(jìn)行處理，之后再重新上傳。所有文件全部遷移成功后，修改文件訪問模式為DFS模式，文件的上傳和下載均采用云存儲模式。

經(jīng)實際遷移測試，從遷移一個月的數(shù)據(jù)來看，平均每小時文件遷移量達(dá)到2.3萬份。

2.3 文件存儲系統(tǒng)優(yōu)化

文件存儲可考慮選擇FastDFS，HDFS，MongoDB，MogileFS這幾種模式，除FastDFS適合小文件存儲外，其余模式均適合于文件較大且需要進(jìn)行分塊的情況。安裝系統(tǒng)環(huán)境，測試了FastDFS和HDFS兩種存儲模式對文件的操作所用時間，對比情況見表1。

表1 FastDFS與HDFS存儲模式的性能對比

對比可知，執(zhí)行速度上FastDFS占優(yōu)，因此可選擇作為存儲方案。

文件備份模式可采用NBU備份模式，確保文件系統(tǒng)故障時能及時恢復(fù)。但這種模式備份文件會占用較大空間，且備份不及時。鑒于FastDFS可以使用多副本模式，在備份的同時提供并發(fā)服務(wù)。因此，本文選擇使用多副本模式的方案來實現(xiàn)存儲系統(tǒng)的優(yōu)化。

（1）增加FastDFS并發(fā)存儲的Storage節(jié)點

對于文件系統(tǒng)來說，備份容災(zāi)是必不可少的功能。為了實現(xiàn)備份的同時能夠?qū)ν馓峁┪募?wù)，云存儲集群采用兩組Storage，每組Storage保持兩臺Storage服務(wù)器作為互備份，從而達(dá)到容災(zāi)目的，同時能夠?qū)ν馓峁┓?wù)。兩組Storage采用不同的group_name，同時接入Tracker集群，并且同組Storage保持磁盤容量一致。

（2）調(diào)整節(jié)點同步策略，縮短延遲時間

為保證備份的及時性和有效性，避免出現(xiàn)單點故障時文件丟失，可將同組Storage的兩個節(jié)點分別使用物理上隔離的存儲節(jié)點和虛機(jī)節(jié)點，確保當(dāng)物理服務(wù)器單點故障時系統(tǒng)可用。同時，調(diào)整了系統(tǒng)同步參數(shù)，設(shè)置文件傳輸后，立即進(jìn)行同步。

云存儲集群的參數(shù)調(diào)整以后，兩組Storage可同時對外服務(wù)，服務(wù)能力得到了雙倍擴(kuò)展。經(jīng)忙時相同文件生成時間進(jìn)行對比，平均文件同步時長為2 s。

為解決文件重復(fù)存儲的問題，存儲中冗余文件僅保留一份，采用FastDFS的DHT功能控制冗余問題。

FastDFS本身不具備對重復(fù)上傳的單位文件去重的功能，但FastDHT作為一個高性能的分布式哈希系統(tǒng)卻可以實現(xiàn)去重，它是基于鍵值對存儲的，需要以BerkeleyDB作為數(shù)據(jù)存儲的媒介，同時還需要依賴于libfastcommon。

處理方法：配置安裝FastDHT服務(wù)器和BerkeleyDB，使用BerkeleyDB存放文件的md5值，通過md5值來判斷文件是否重復(fù)。兩組服務(wù)器設(shè)定使用DHT進(jìn)行文件校驗，并使用對應(yīng)的DHT服務(wù)。配置使用DHT服務(wù)以后，每個Storage只存放一個文件，對重復(fù)的文件采用軟鏈接的方式進(jìn)行存儲。使用BerkleyDB記錄文件特征，相同的文件只保存一個副本。其余文件建立軟鏈接指向這個副本，軟鏈接類似Windows操作系統(tǒng)中的快捷方式。經(jīng)過測試，每個相同文件即使使用不同文件名、修改時間，仍可以保持單副本保存。

經(jīng)文件上傳測試，相同文件只保留一個文件，其余文件變成軟鏈接指向。軟鏈接文件大小不到65byte。相同文件均變?yōu)檐涙溄游募⒅赶蛲粚嶓w文件。通過分布式文件系統(tǒng)對小文件讀寫、刪除等操作的對比可知，使用FastDFS模式能達(dá)到較好的冗余控制效果。

3 應(yīng)用效果分析

以上優(yōu)化措施實施以后，政企OA系統(tǒng)的文件存儲空間的消耗速度明顯變慢。同時，客戶使用OA系統(tǒng)打開文件正文和下載附件、編輯保存正文和上傳附件的速度體驗較之前有較大提升。遷移完畢后，通過分析可知云存儲系統(tǒng)的文件系統(tǒng)壓縮率總體達(dá)到53.21%。完成措施后實現(xiàn)的社會效益如下：

3.1 盤活存儲資源

原有的11.6 T存儲空間被遷移到FastDFS存儲模式運行后，通過后臺數(shù)據(jù)計算得出文件重復(fù)率達(dá)80%，遷移完成后僅使用2.3 T存儲，可盤活9.3 T存儲。同時NBU備份也節(jié)約相同存儲，總共可節(jié)約存儲空間18.6 T；同時，采用FastDFS服務(wù)以后，由于文件訪問吞吐量較之前提升一倍，可盤活低端存儲4 T空間；綜上所述，總共可盤活22.6 T存儲資源，可節(jié)省幾十萬元投資成本。

3.2 降低人力管理成本

云化存儲采用集群方式和部署集中監(jiān)控平臺，存儲系統(tǒng)故障率較FTP方式大大下降，巡檢、監(jiān)控和故障處理成本下降。FTP服務(wù)器出現(xiàn)資源不足，需要新建FTP服務(wù)器并做數(shù)據(jù)遷移，而采用FastDFS以后，只需增加新卷存儲即可實現(xiàn)擴(kuò)容，不需部署實施NBU備份策略設(shè)置及日常維護(hù)。單位發(fā)文后，若要調(diào)整文件內(nèi)容，以往需要運維人員到FTP服務(wù)器后臺操作處理。更改為云化存儲后，只需在前臺提供文件查詢召回、替換功能，發(fā)文后處理方式由運維人員轉(zhuǎn)交給客戶維護(hù)人員即可實現(xiàn)。實現(xiàn)新方案后可大幅降低人力成本。

4 結(jié)語

隨著政企業(yè)務(wù)的不斷增加，政企文件所占存儲資源必將越來越龐大，為解決政企文件存儲冗余等問題，節(jié)省存儲資源，必須對原有的存儲系統(tǒng)進(jìn)行優(yōu)化。

本文以雙地址存儲為基礎(chǔ)，對政企OA文件存儲系統(tǒng)進(jìn)行了優(yōu)化，優(yōu)化后的系統(tǒng)兼容性強(qiáng)，能通過定時文件遷移使FTP存儲順利過渡到云存儲，此外采用FastDFS的DHT功能較好地控制了存儲冗余，使系統(tǒng)文件壓縮率大大提高，有利于提高存儲資源的利用率，節(jié)省企業(yè)成本。