金秀鳳

摘 要：隨著大數(shù)據(jù)時(shí)代檔案信息資源的不斷增加以及用戶的不斷積累，對(duì)于檔案信息資源共享平臺(tái)的數(shù)據(jù)處理提出了新的要求，即平臺(tái)需要滿足高并發(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)通過系統(tǒng)的接口開發(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)的檔案信息資源及用戶都出現(xiàn)了急速增長(zhǎng)，在平臺(tái)的使用頻度與日俱增的形勢(shì)下，如何對(duì)海量的檔案信息資源數(shù)據(jù)進(jìn)行高效的管理成為當(dāng)前檔案信息化研究的熱點(diǎn)[2]。要讓檔案信息資源共享平臺(tái)快速響應(yīng)用戶請(qǐng)求并承受不斷增加的負(fù)荷量，傳統(tǒng)的技術(shù)方案已很難適應(yīng)現(xiàn)行的高頻度檔案信息服務(wù)請(qǐng)求?，F(xiàn)有的技術(shù)擬采用Redis緩存技術(shù)能較好地解決檔案信息資源共享平臺(tái)數(shù)據(jù)處理性能問題[3]。

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

檔案信息資源共享平臺(tái)的構(gòu)建需要根據(jù)平臺(tái)自身的特點(diǎn)，即平臺(tái)建成后同時(shí)滿足包括PC、手機(jī)及平板等設(shè)備以及不同分辨率瀏覽器的使用[4]。因此，其數(shù)據(jù)處理的優(yōu)化非常重要，在平臺(tái)自身的實(shí)踐應(yīng)用方面，要有助于優(yōu)化檔案管理流程。檔案信息資源共享平臺(tái)的建設(shè)作為檔案信息化的一部分，已被各級(jí)檔案部門重視起來，物聯(lián)網(wǎng)、云計(jì)算技術(shù)以及大數(shù)據(jù)技術(shù)的成熟，已為平臺(tái)建設(shè)提供了技術(shù)保障，建成后的平臺(tái)將為檔案信息資源統(tǒng)一管理、檔案管理工作順利開展、檔案部門對(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)用戶，平臺(tái)在普及推廣之后特別在移動(dòng)互聯(lián)網(wǎng)普及的今天，用戶利用檔案平臺(tái)的場(chǎng)景也會(huì)越來越多。面對(duì)檔案信息的大數(shù)據(jù)量請(qǐng)求，平臺(tái)前期的數(shù)據(jù)處理性能指標(biāo)至少要達(dá)到每秒一萬次以上的請(qǐng)求吞吐量。在高可靠性方面，平臺(tái)需要滿足用戶并發(fā)，在平臺(tái)的新功能投入使用、檔案檢索開放等關(guān)鍵時(shí)間點(diǎn)，會(huì)有眾多用戶同時(shí)操作同一個(gè)功能，這就造成了一定的并發(fā)請(qǐng)求，在平臺(tái)前期的并發(fā)性能指標(biāo)上需要滿足一百以上的并發(fā)數(shù)據(jù)處理請(qǐng)求。在高穩(wěn)定性方面，平臺(tái)持續(xù)穩(wěn)定工作是檔案信息資源共享平臺(tái)用戶所需的最基本的要求，平臺(tái)數(shù)據(jù)處理穩(wěn)定性方面需要小于萬分之一的出錯(cuò)率。

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

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

2.1 檔案信息資源共享平臺(tái)緩存部署。檔案信息服務(wù)平臺(tái)在建設(shè)初期，由于檔案信息化程度不高，自身的用戶也有限，主要面向內(nèi)部用戶，因此對(duì)平臺(tái)的性能要求不高。正常情況下應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和文件服務(wù)器等所有的資源都在一臺(tái)服務(wù)器上。隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，平臺(tái)面向的用戶逐步由內(nèi)部用戶轉(zhuǎn)向外部用戶，用戶的增加導(dǎo)致訪問檔案信息服務(wù)平臺(tái)速度越來越慢，平臺(tái)存儲(chǔ)的檔案信息資源變得越來越豐富，此時(shí)會(huì)將應(yīng)用和數(shù)據(jù)分離，應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器和文件服務(wù)器獨(dú)立部署，平臺(tái)的業(yè)務(wù)邏輯由專門的應(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，用戶對(duì)檔案信息服務(wù)的要求越來越高，外部的用戶量也有了量的突破，檔案信息服務(wù)平臺(tái)的性能問題直接影響平臺(tái)對(duì)外服務(wù)的質(zhì)量，此時(shí)緩存技術(shù)應(yīng)運(yùn)而生，緩存是分布式系統(tǒng)中的重要組件，主要解決高并發(fā)，大數(shù)據(jù)場(chǎng)景下，熱點(diǎn)數(shù)據(jù)訪問的性能問題。對(duì)于檔案信息資源共享平臺(tái)采用部署緩存的方式來解決平臺(tái)的數(shù)據(jù)處理問題，初期可以將緩存部署在應(yīng)用服務(wù)器上，該方式與應(yīng)用服務(wù)共享資源，訪問速度會(huì)很快，但是缺點(diǎn)顯而易見，會(huì)出現(xiàn)和應(yīng)用程序爭(zhēng)用內(nèi)存的情況，未來考慮采用遠(yuǎn)程分布式環(huán)境技術(shù)來解決平臺(tái)的數(shù)據(jù)處理問題。檔案信息資源共享平臺(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ù)庫負(fù)載，但在緩存占用內(nèi)存分配上采用預(yù)分配的內(nèi)存池方式，帶來一定程度上的內(nèi)存浪費(fèi)，對(duì)于復(fù)雜的數(shù)據(jù)類型以及持久化方面也不能夠支持。Redis是一個(gè)開源的使用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ù)存儲(chǔ)采用現(xiàn)場(chǎng)申請(qǐng)內(nèi)存的方式進(jìn)行，會(huì)周期性地把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件，Redis支持主從同步，數(shù)據(jù)可以從主服務(wù)器向任意數(shù)量的從服務(wù)器上同步，Redis除了緩存之外，還提供了額外的聚合計(jì)算功能。

因此，在Memcached、Redis兩種緩存技術(shù)中，Redis更適合作為平臺(tái)性能提升的緩存技術(shù)，主要原因如下：第一，Redis支持更豐富的Key-Value數(shù)據(jù)類型，檔案信息資源共享平臺(tái)需要緩存的檔案信息類型比較豐富，簡(jiǎ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ǔ)在硬盤上，這樣就能做到持久化，該特性對(duì)平臺(tái)非常重要，用戶對(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)上，最大限度使用用戶瀏覽器緩存，對(duì)于常用的資源訪問采用CDN技術(shù)；后端實(shí)現(xiàn)上，一方面數(shù)據(jù)庫中采用存儲(chǔ)過程，數(shù)據(jù)庫設(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ù)頁面、用戶管理頁面，其中對(duì)于檢索頁面的使用最為頻繁，該功能直接面向用戶，這樣就可以有針對(duì)性地對(duì)該功能數(shù)據(jù)處理進(jìn)行優(yōu)化，優(yōu)化的方式將CSS、JavaScript進(jìn)行壓縮存儲(chǔ)以及功能頁面中的圖片進(jìn)行合并，這樣用戶一次請(qǐng)求就可以完成CSS、JavaScript以及頁面樣式圖片的獲取。對(duì)檔案信息資源共享平臺(tái)而言，像CSS、JS以及圖標(biāo)這些靜態(tài)資源文件更新的頻率都比較低，可以考慮將這些文件進(jìn)行緩存在瀏覽器中，下次相同的頁面在有資源請(qǐng)求時(shí)就可以直接讀取瀏覽器緩存，這樣就可以大大提升平臺(tái)的訪問效率。平臺(tái)在前端技術(shù)使用了適應(yīng)普通PC與移動(dòng)設(shè)備的JS、CSS技術(shù)，相應(yīng)的資源文件訪問可以采用CDN技術(shù)[7]，瀏覽器請(qǐng)求大文件資源時(shí)，將從CDN直接返回給用戶設(shè)備，由于資源訪問的路徑采用最短路徑，這樣平臺(tái)的訪問速度將大大加快，同時(shí)減輕了檔案信息資源共享平臺(tái)的服務(wù)器負(fù)載壓力。前端數(shù)據(jù)處理優(yōu)化方式匯總?cè)鐖D2所示：

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

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

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

3.4 檔案信息資源共享平臺(tái)數(shù)據(jù)處理緩存技術(shù)優(yōu)化效果分析。準(zhǔn)備1000萬條檔案信息數(shù)據(jù)，檔案信息數(shù)據(jù)中包含基本數(shù)據(jù)類型，如字符類型、時(shí)間類型、GUID類型，文檔信息單獨(dú)存儲(chǔ)，與專門存放文檔信息的表關(guān)聯(lián)，檔案信息日志數(shù)據(jù)中同樣包含1000條，用戶信息準(zhǔn)備100萬條，平臺(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，硬盤為固態(tài)硬盤，測(cè)試結(jié)果如圖5所示：

通過測(cè)試結(jié)果不難發(fā)現(xiàn)，隨著檔案信息批量請(qǐng)求數(shù)量的增加，平臺(tái)每秒鐘可以支持的請(qǐng)求數(shù)也越來越高，同時(shí)Redis緩存技術(shù)對(duì)于并發(fā)連接的支持也很好，隨著檔案信息檢索功能使用率與使用用戶的不斷增加，采用該技術(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]。通過對(duì)檔案信息資源共享平臺(tái)的數(shù)據(jù)處理優(yōu)化進(jìn)行研究，最終通過用戶使用的瀏覽器層面、CDN等相關(guān)前端技術(shù)，后端數(shù)據(jù)庫檢索充分利用存儲(chǔ)過程、索引等技術(shù)，并在后端數(shù)據(jù)訪問優(yōu)化采用了Redis緩存技術(shù)，從而實(shí)現(xiàn)了檔案信息資源共享平臺(tái)的數(shù)據(jù)高效訪問。本課題后期仍有地方值得改進(jìn)與探討，比如使用緩存技術(shù)可以顯著提升系統(tǒng)的性能，但對(duì)于平臺(tái)數(shù)據(jù)的實(shí)時(shí)性產(chǎn)生一定的影響，檔案信息在緩存期間，原始數(shù)據(jù)庫被修改了，這時(shí)終端用戶讀取到的信息實(shí)際上還是數(shù)據(jù)被修改前檔案信息，這就需要對(duì)檔案信息需要緩存的信息做出評(píng)估，進(jìn)而確定緩存設(shè)置的過期時(shí)間問題，另外采用Redis緩存技術(shù)還需要考慮數(shù)據(jù)命中率問題，如何提升檔案信息訪問在Redis中命中的幾率也將成為未來研究的方向[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à)值及其開發(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]高玉平.海量圖書檢索信息的快速查詢系統(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é)生處 來稿日期：2018-08-20）