大數(shù)據(jù)時(shí)代檔案信息資源共享平臺(tái)數(shù)據(jù)處理的優(yōu)化

金秀鳳

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

參考文獻(xiàn)：

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

[2]卞咸杰.大數(shù)據(jù)時(shí)代檔案信息資源共享平臺(tái)性能優(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ù)時(shí)代檔案信息資源共享平臺(tái)前端框架的構(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]高玉平.海量圖書(shū)檢索信息的快速查詢(xún)系統(tǒng)優(yōu)化設(shè)計(jì)研究[J].現(xiàn)代電子技術(shù)，2017，40（6）：5-9.

[9]卞咸杰.基于WCF技術(shù)的跨平臺(tái)檔案信息資源共享平臺(tái)建設(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é)生處 來(lái)稿日期：2018-08-20）