金秀鳳

摘 要：隨著大數(shù)據(jù)時代檔案信息資源的不斷增加以及用戶的不斷積累，對于檔案信息資源共享平臺的數(shù)據(jù)處理提出了新的要求，即平臺需要滿足高并發(fā)數(shù)據(jù)請求服務(wù)，同時提供的檔案信息資源共享平臺服務(wù)能夠穩(wěn)定運(yùn)行。文章在介紹檔案信息資源共享平臺數(shù)據(jù)處理性能需求的基礎(chǔ)上，比較目前常用的前后端解決檔案信息資源共享平臺數(shù)據(jù)處理性能優(yōu)化的辦法，提出采用Redis緩存技術(shù)解決檔案信息資源共享平臺數(shù)據(jù)處理，詳細(xì)地論證了檔案信息資源共享平臺數(shù)據(jù)處理優(yōu)化的實(shí)現(xiàn)及效果分析。

關(guān)鍵詞：大數(shù)據(jù)；檔案信息資源；共享平臺；數(shù)據(jù)處理優(yōu)化；Redis緩存技術(shù)

Abstract：With the continuous increasing of archives information resources and the accumulation of users in the era of large data， new requirements have been put forward for the data processing of archives information resources sharing platform. The platform needs to satisfy the high concurrent data request service， and the archives information resources sharing platform service can run stably.Based on the data processing performance requirements of the file information resource sharing platform， this paper compares the commonly used methods for optimizing the data processing performance of the file information resource sharing platform. It proposes to use Redis cache technology to solve the data processing of the file information resource sharing platform. It demonstrates the realization and effect analysis of data processing optimization of archive information resource sharing platform.

Keyword：Big Data；Archive information resource；Sharing Platform；Data processing optimization；Redis caching technology

大數(shù)據(jù)時代是建立在互聯(lián)網(wǎng)、物聯(lián)網(wǎng)等現(xiàn)代網(wǎng)絡(luò)渠道廣泛收集大量數(shù)據(jù)資源基礎(chǔ)上的數(shù)據(jù)存儲、價值提煉、智能處理和展示的信息時代[1]，大數(shù)據(jù)時代檔案信息資源共享平臺通過系統(tǒng)的接口開發(fā)技術(shù)將物聯(lián)網(wǎng)、云計(jì)算技術(shù)融合其中，使平臺對外服務(wù)具有感知與處置檔案信息能力，并為外部提供檔案信息服務(wù)的一種新模式。隨著大數(shù)據(jù)技術(shù)與移動互聯(lián)網(wǎng)技術(shù)的不斷完善，檔案信息資源數(shù)據(jù)規(guī)模不斷擴(kuò)大，檔案信息資源共享平臺的檔案信息資源及用戶都出現(xiàn)了急速增長，在平臺的使用頻度與日俱增的形勢下，如何對海量的檔案信息資源數(shù)據(jù)進(jìn)行高效的管理成為當(dāng)前檔案信息化研究的熱點(diǎn)[2]。要讓檔案信息資源共享平臺快速響應(yīng)用戶請求并承受不斷增加的負(fù)荷量，傳統(tǒng)的技術(shù)方案已很難適應(yīng)現(xiàn)行的高頻度檔案信息服務(wù)請求。現(xiàn)有的技術(shù)擬采用Redis緩存技術(shù)能較好地解決檔案信息資源共享平臺數(shù)據(jù)處理性能問題[3]。

1 檔案信息資源共享平臺數(shù)據(jù)處理性能需求

檔案信息資源共享平臺的構(gòu)建需要根據(jù)平臺自身的特點(diǎn)，即平臺建成后同時滿足包括PC、手機(jī)及平板等設(shè)備以及不同分辨率瀏覽器的使用[4]。因此，其數(shù)據(jù)處理的優(yōu)化非常重要，在平臺自身的實(shí)踐應(yīng)用方面，要有助于優(yōu)化檔案管理流程。檔案信息資源共享平臺的建設(shè)作為檔案信息化的一部分，已被各級檔案部門重視起來，物聯(lián)網(wǎng)、云計(jì)算技術(shù)以及大數(shù)據(jù)技術(shù)的成熟，已為平臺建設(shè)提供了技術(shù)保障，建成后的平臺將為檔案信息資源統(tǒng)一管理、檔案管理工作順利開展、檔案部門對外服務(wù)提供體系框架；同時，檔案信息資源能夠?qū)崿F(xiàn)高效互聯(lián)，檔案信息資源共享平臺與其他業(yè)務(wù)協(xié)調(diào)發(fā)展與集成，平臺性能優(yōu)化實(shí)踐將指導(dǎo)檔案信息化業(yè)務(wù)流程優(yōu)化、檔案信息資源高效管理和檔案信息服務(wù)實(shí)現(xiàn)多元化；此外，有助于優(yōu)化檔案信息資源共享平臺的建設(shè)，提高檔案信息資源共享平臺建設(shè)質(zhì)量。

檔案信息資源共享平臺數(shù)據(jù)處理性能需求方面主要包括高性能、高可靠性及高穩(wěn)定性方面[5]。在高性能方面，要支持檔案信息的大數(shù)據(jù)量請求。檔案信息資源共享平臺面向的是互聯(lián)網(wǎng)用戶，平臺在普及推廣之后特別在移動互聯(lián)網(wǎng)普及的今天，用戶利用檔案平臺的場景也會越來越多。面對檔案信息的大數(shù)據(jù)量請求，平臺前期的數(shù)據(jù)處理性能指標(biāo)至少要達(dá)到每秒一萬次以上的請求吞吐量。在高可靠性方面，平臺需要滿足用戶并發(fā)，在平臺的新功能投入使用、檔案檢索開放等關(guān)鍵時間點(diǎn)，會有眾多用戶同時操作同一個功能，這就造成了一定的并發(fā)請求，在平臺前期的并發(fā)性能指標(biāo)上需要滿足一百以上的并發(fā)數(shù)據(jù)處理請求。在高穩(wěn)定性方面，平臺持續(xù)穩(wěn)定工作是檔案信息資源共享平臺用戶所需的最基本的要求，平臺數(shù)據(jù)處理穩(wěn)定性方面需要小于萬分之一的出錯率。

2 檔案信息資源共享平臺數(shù)據(jù)處理優(yōu)化技術(shù)選擇

大數(shù)據(jù)時代檔案信息資源共享平臺數(shù)據(jù)處理優(yōu)化主要從以下幾個方面考慮：第一是對面向用戶的前端頁面進(jìn)行優(yōu)化，該部分的優(yōu)化需要考慮平臺現(xiàn)有的資源利用，最終達(dá)到使平臺的功能頁面加載得更快、對用戶的檔案信息檢索操作響應(yīng)得更及時，并能提供更為友好的用戶體驗(yàn)；第二是對存儲檔案信息的數(shù)據(jù)進(jìn)行優(yōu)化，隨著檔案信息資源共享平臺用戶的增加及平臺本身的信息量增加，僅僅對前端頁面與數(shù)據(jù)庫優(yōu)化不能滿足平臺未來的性能要求，需從緩存技術(shù)入手，研究該技術(shù)在檔案信息資源共享平臺中的部署。

2.1 檔案信息資源共享平臺緩存部署。檔案信息服務(wù)平臺在建設(shè)初期，由于檔案信息化程度不高，自身的用戶也有限，主要面向內(nèi)部用戶，因此對平臺的性能要求不高。正常情況下應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和文件服務(wù)器等所有的資源都在一臺服務(wù)器上。隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，平臺面向的用戶逐步由內(nèi)部用戶轉(zhuǎn)向外部用戶，用戶的增加導(dǎo)致訪問檔案信息服務(wù)平臺速度越來越慢，平臺存儲的檔案信息資源變得越來越豐富，此時會將應(yīng)用和數(shù)據(jù)分離，應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和文件服務(wù)器獨(dú)立部署，平臺的業(yè)務(wù)邏輯由專門的應(yīng)用服務(wù)器負(fù)責(zé)，此時檔案信息服務(wù)平臺的處理能力得到了很大的提升。隨著移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)技術(shù)的興起，檔案信息服務(wù)平臺的應(yīng)用范圍已不局限于傳統(tǒng)的PC，用戶對檔案信息服務(wù)的要求越來越高，外部的用戶量也有了量的突破，檔案信息服務(wù)平臺的性能問題直接影響平臺對外服務(wù)的質(zhì)量，此時緩存技術(shù)應(yīng)運(yùn)而生，緩存是分布式系統(tǒng)中的重要組件，主要解決高并發(fā)，大數(shù)據(jù)場景下，熱點(diǎn)數(shù)據(jù)訪問的性能問題。對于檔案信息資源共享平臺采用部署緩存的方式來解決平臺的數(shù)據(jù)處理問題，初期可以將緩存部署在應(yīng)用服務(wù)器上，該方式與應(yīng)用服務(wù)共享資源，訪問速度會很快，但是缺點(diǎn)顯而易見，會出現(xiàn)和應(yīng)用程序爭用內(nèi)存的情況，未來考慮采用遠(yuǎn)程分布式環(huán)境技術(shù)來解決平臺的數(shù)據(jù)處理問題。檔案信息資源共享平臺緩存應(yīng)用部署如圖1所示：

2.2 檔案信息資源共享平臺緩存技術(shù)選擇。檔案信息資源共享平臺為了適應(yīng)大數(shù)據(jù)應(yīng)用，需要采用分布式緩存技術(shù)，需要將緩存部署在獨(dú)立的服務(wù)器上，目前主流的分布式緩存有Memcached和Redis。Memcached 是一個高性能的分布式內(nèi)存對象緩存系統(tǒng)，用于動態(tài)Web應(yīng)用以減輕數(shù)據(jù)庫負(fù)載，但在緩存占用內(nèi)存分配上采用預(yù)分配的內(nèi)存池方式，帶來一定程度上的內(nèi)存浪費(fèi)，對于復(fù)雜的數(shù)據(jù)類型以及持久化方面也不能夠支持。Redis是一個開源的使用ANSI C語言編寫、支持網(wǎng)絡(luò)、可基于內(nèi)存亦可持久化的日志型、Key-Value數(shù)據(jù)庫（支持列表、集合、哈希等眾多數(shù)據(jù)結(jié)構(gòu)）[6]，并提供多種語言的API。Redis只支持單線程讀寫復(fù)用網(wǎng)絡(luò)模型，數(shù)據(jù)存儲采用現(xiàn)場申請內(nèi)存的方式進(jìn)行，會周期性地把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，Redis支持主從同步，數(shù)據(jù)可以從主服務(wù)器向任意數(shù)量的從服務(wù)器上同步，Redis除了緩存之外，還提供了額外的聚合計(jì)算功能。

因此，在Memcached、Redis兩種緩存技術(shù)中，Redis更適合作為平臺性能提升的緩存技術(shù)，主要原因如下：第一，Redis支持更豐富的Key-Value數(shù)據(jù)類型，檔案信息資源共享平臺需要緩存的檔案信息類型比較豐富，簡單字符串不能滿足平臺數(shù)據(jù)緩存需求；第二，在數(shù)據(jù)存儲上，Memcached全部存儲在內(nèi)存上，服務(wù)重新啟動會丟失緩存信息，做不到數(shù)據(jù)持久化，而Redis會將部分?jǐn)?shù)據(jù)存儲在硬盤上，這樣就能做到持久化，該特性對平臺非常重要，用戶對平臺的操作不會因?yàn)槔舛l(fā)生信息丟失；第三，檔案信息從傳統(tǒng)的文字信息向圖片、文件等多媒體信息轉(zhuǎn)變，這對緩存存儲信息的大小有一定的要求，Redis的Value存儲最大可以達(dá)到1GB，而Memcached的Value存儲最大只有1MB。

3 檔案信息資源共享平臺數(shù)據(jù)處理優(yōu)化實(shí)現(xiàn)及效果分析

在技術(shù)選型確定之后，實(shí)現(xiàn)檔案信息資源共享平臺數(shù)據(jù)處理優(yōu)化，要從以下幾個方面實(shí)現(xiàn)平臺的數(shù)據(jù)處理優(yōu)化：硬件設(shè)備上，采用高速緩存技術(shù)；前端實(shí)現(xiàn)上，最大限度使用用戶瀏覽器緩存，對于常用的資源訪問采用CDN技術(shù)；后端實(shí)現(xiàn)上，一方面數(shù)據(jù)庫中采用存儲過程，數(shù)據(jù)庫設(shè)計(jì)采用適當(dāng)?shù)娜哂嘟Y(jié)構(gòu)設(shè)計(jì)以便于檔案信息統(tǒng)計(jì)，另一方面采用Redis緩存技術(shù)以確保檔案信息資源共享平臺的高并發(fā)請求。

3.1 前端數(shù)據(jù)處理優(yōu)化。檔案信息資源共享平臺的面向用戶的前端主要包括檔案信息檢索頁面、檔案信息管理維護(hù)頁面、用戶管理頁面，其中對于檢索頁面的使用最為頻繁，該功能直接面向用戶，這樣就可以有針對性地對該功能數(shù)據(jù)處理進(jìn)行優(yōu)化，優(yōu)化的方式將CSS、JavaScript進(jìn)行壓縮存儲以及功能頁面中的圖片進(jìn)行合并，這樣用戶一次請求就可以完成CSS、JavaScript以及頁面樣式圖片的獲取。對檔案信息資源共享平臺而言，像CSS、JS以及圖標(biāo)這些靜態(tài)資源文件更新的頻率都比較低，可以考慮將這些文件進(jìn)行緩存在瀏覽器中，下次相同的頁面在有資源請求時就可以直接讀取瀏覽器緩存，這樣就可以大大提升平臺的訪問效率。平臺在前端技術(shù)使用了適應(yīng)普通PC與移動設(shè)備的JS、CSS技術(shù)，相應(yīng)的資源文件訪問可以采用CDN技術(shù)[7]，瀏覽器請求大文件資源時，將從CDN直接返回給用戶設(shè)備，由于資源訪問的路徑采用最短路徑，這樣平臺的訪問速度將大大加快，同時減輕了檔案信息資源共享平臺的服務(wù)器負(fù)載壓力。前端數(shù)據(jù)處理優(yōu)化方式匯總?cè)鐖D2所示：

3.2 后臺數(shù)據(jù)庫數(shù)據(jù)處理優(yōu)化。檔案信息資源共享平臺對外服務(wù)使用最為頻繁的是檔案檢索功能，在前端優(yōu)化后需要對其中的涉及到的后端數(shù)據(jù)庫檢索模塊進(jìn)行優(yōu)化。優(yōu)化點(diǎn)主要采用以下方式：首先是減少檔案檢索功能中數(shù)據(jù)來回訪問的數(shù)據(jù)量，盡量將檔案檢索的前置條件設(shè)置詳細(xì)并一次性提交到后臺進(jìn)行數(shù)據(jù)檢索，數(shù)據(jù)庫檢索成功后將用戶需要的結(jié)果返回給用戶，通過該方式可以極大提升系統(tǒng)檢索的性能，最大限度減少數(shù)據(jù)訪問量，同時因?yàn)榉祷氐臄?shù)據(jù)更加精準(zhǔn)，網(wǎng)絡(luò)的壓力也會大大減輕。其次是采用存儲過程技術(shù)，如果在檔案檢索過程中涉及到復(fù)雜的數(shù)據(jù)提取過程，將過程數(shù)據(jù)處理邏輯封裝到存儲過程里面，這樣就能避免通過網(wǎng)絡(luò)來回進(jìn)行數(shù)據(jù)交互，檔案數(shù)據(jù)通過存儲過程處理后統(tǒng)一返回用戶請求信息，由于存儲過程采用參數(shù)的方式傳入檢索請求信息，在提升檢索性能的同時還可以避免平臺SQL依賴注入漏洞。最后是充分利用索引技術(shù)，在檔案信息最頻繁使用的檢索點(diǎn)使用的相關(guān)列上創(chuàng)建索引，可以極大地提升檢索性能[8]，因?yàn)榧铀饕谔嵘龣z索性能的同時會降低平臺檔案信息的修改、新增與刪除功能的性能，這里可以采用將檔案信息檢索所需要的主體信息放在歷史表中，這樣可以滿足由于信息變動帶來的其他功能的性能問題。具體的后臺數(shù)據(jù)庫數(shù)據(jù)處理優(yōu)化如圖3所示：

3.3 Redis緩存技術(shù)數(shù)據(jù)處理優(yōu)化實(shí)現(xiàn)。檔案信息資源共享平臺面向用戶的信息如果都從數(shù)據(jù)庫中讀取，平臺使用量在達(dá)到一定的用戶量級之后，就存在極大的性能的問題，為了緩解數(shù)據(jù)庫的壓力，可以將不經(jīng)常變化并且訪問頻繁的用戶請求檔案信息放入Redis緩存，這樣在檔案信息檢索請求發(fā)起后，首先判斷Redis緩存中是否存在用戶請求的檔案信息，如果存在就直接從Redis緩存中讀取檔案信息，這種情況下會大幅提升平臺檢索性能；如果Redis緩存中不存在用戶請求的檔案信息，將從數(shù)據(jù)庫中讀取檔案信息相關(guān)數(shù)據(jù)，同時需要將讀取到的檔案信息寫入Redis緩存，這樣在下次用戶再發(fā)起同樣的請求系統(tǒng)就直接讀取Redis緩存而不需要訪問數(shù)據(jù)庫。具體的檔案信息資源共享平臺Redis緩存請求實(shí)現(xiàn)流程如圖4所示：

Redis緩存請求實(shí)現(xiàn)流程Redis緩存可以在客戶端使用，為了使該技術(shù)能夠在檔案信息資源共享平臺項(xiàng)目中運(yùn)用，需要在解決方案中加入Redis操作DLL，DLL文件同樣可以從GitHub平臺下載，DLL文件添加至引用后，需要將配置Redis操作參數(shù)寫入配置文件，在配置中需要注意Redis的端口信息為Redis服務(wù)中顯示的端口，默認(rèn)端口號為6739，配置相關(guān)信息完成后需要寫一個通用Redis緩存管理器來實(shí)現(xiàn)獲取Redis客戶端實(shí)例，添加檔案信息實(shí)體集合到緩存中，添加字符文本類型檔案信息，獲取字符文本類型檔案信息，根據(jù)鍵名獲取檔案信息列表，獲取所有檔案信息，獲取指定條件類型檔案信息列表，刪除指定鍵緩存信息，清空緩存信息。在之后的實(shí)踐中有需要使用緩存的地方直接調(diào)用通用Redis緩存管理器即可。

3.4 檔案信息資源共享平臺數(shù)據(jù)處理緩存技術(shù)優(yōu)化效果分析。準(zhǔn)備1000萬條檔案信息數(shù)據(jù)，檔案信息數(shù)據(jù)中包含基本數(shù)據(jù)類型，如字符類型、時間類型、GUID類型，文檔信息單獨(dú)存儲，與專門存放文檔信息的表關(guān)聯(lián)，檔案信息日志數(shù)據(jù)中同樣包含1000條，用戶信息準(zhǔn)備100萬條，平臺操作請求采用10的N次方進(jìn)行遞增加壓，請求的數(shù)據(jù)條數(shù)同樣采用10的N次方進(jìn)行遞增加壓，測試設(shè)備操作系統(tǒng)為Win10，CPU型號為英特爾酷睿i5-7200U，內(nèi)存容量為8GB，硬盤為固態(tài)硬盤，測試結(jié)果如圖5所示：

通過測試結(jié)果不難發(fā)現(xiàn)，隨著檔案信息批量請求數(shù)量的增加，平臺每秒鐘可以支持的請求數(shù)也越來越高，同時Redis緩存技術(shù)對于并發(fā)連接的支持也很好，隨著檔案信息檢索功能使用率與使用用戶的不斷增加，采用該技術(shù)后可以有效提升平臺的數(shù)據(jù)處理效率。

總之，檔案信息資源共享平臺不僅目前要適應(yīng)檔案服務(wù)綜合管理平臺、Web平臺和移動平臺，還要可擴(kuò)展到移動平臺大體系[9]。通過對檔案信息資源共享平臺的數(shù)據(jù)處理優(yōu)化進(jìn)行研究，最終通過用戶使用的瀏覽器層面、CDN等相關(guān)前端技術(shù)，后端數(shù)據(jù)庫檢索充分利用存儲過程、索引等技術(shù)，并在后端數(shù)據(jù)訪問優(yōu)化采用了Redis緩存技術(shù)，從而實(shí)現(xiàn)了檔案信息資源共享平臺的數(shù)據(jù)高效訪問。本課題后期仍有地方值得改進(jìn)與探討，比如使用緩存技術(shù)可以顯著提升系統(tǒng)的性能，但對于平臺數(shù)據(jù)的實(shí)時性產(chǎn)生一定的影響，檔案信息在緩存期間，原始數(shù)據(jù)庫被修改了，這時終端用戶讀取到的信息實(shí)際上還是數(shù)據(jù)被修改前檔案信息，這就需要對檔案信息需要緩存的信息做出評估，進(jìn)而確定緩存設(shè)置的過期時間問題，另外采用Redis緩存技術(shù)還需要考慮數(shù)據(jù)命中率問題，如何提升檔案信息訪問在Redis中命中的幾率也將成為未來研究的方向[10]。

*本文系2016年度教育部人文社會科學(xué)研究規(guī)劃基金項(xiàng)目《大數(shù)據(jù)時代檔案信息資源共享平臺構(gòu)建的研究》（項(xiàng)目編號：16YJA870001）資助。

參考文獻(xiàn)：

[1]曹筠慧，管先海，孫洋洋.基于大數(shù)據(jù)時代的檔案價值及其開發(fā)利用探究[J].檔案管理，2017 （1）：27-29.

[2]卞咸杰.大數(shù)據(jù)時代檔案信息資源共享平臺性能優(yōu)化的研究[J].檔案管理，2016（6）：17-20.

[3]曾超宇，李金香. Redis在高速緩存系統(tǒng)中的應(yīng)用[J].微型機(jī)與應(yīng)用，2013，32（12）：11-13.

[4]卞咸杰.大數(shù)據(jù)時代檔案信息資源共享平臺前端框架的構(gòu)建[J].檔案與建設(shè).2017（10）：11-15.

[5]閆中威，孫大嵬.B/S模式在線考試系統(tǒng)性能優(yōu)化及實(shí)現(xiàn)[J].計(jì)算機(jī)系統(tǒng)應(yīng)用，2016，25（10）：81-85.

[6]Robert Escriva， Bernard Wong， and Emin Gün Sirer. HyperDex： A Distributed， Searchable Key-Value Store[J].Acm Sigcomm Computer Communication Review.2012，42（4）：25-36.

[7]Hadrien Hours. A study of the impact of DNS resolvers on CDN performance using a causal approach[J].Computer Networks.2016， 109：200-210.

[8]高玉平.海量圖書檢索信息的快速查詢系統(tǒng)優(yōu)化設(shè)計(jì)研究[J].現(xiàn)代電子技術(shù)，2017，40（6）：5-9.

[9]卞咸杰.基于WCF技術(shù)的跨平臺檔案信息資源共享平臺建設(shè)的研究[J].檔案管理，2016（4）：37-41.

[10]Prerna Rai. Google PageRank Algorithm： Markov Chain Model and Hidden Markov Model[J].International Journal of Computer Applications.2016，138（9）：9-13.

（作者單位：鹽城工學(xué)院學(xué)生處 來稿日期：2018-08-20）