唐文軍，隆承志

（1.華南理工大學(xué)信息網(wǎng)絡(luò)工程研究中心，廣東廣州 510641；2.華南理工大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院，廣東 廣州 510006）

文件上傳是在線學(xué)習(xí)平臺(tái)中一個(gè)使用非常頻繁的功能，教師提交課件、學(xué)生交作業(yè)等，都需要用到文件上傳的功能。文件上傳功能大多采用單進(jìn)程模式實(shí)現(xiàn)，這種上傳方式實(shí)現(xiàn)起來比較簡單，但在實(shí)際應(yīng)用中存在幾個(gè)方面的問題[1-5]：1）在服務(wù)器和網(wǎng)絡(luò)帶寬資源不夠的情況下，會(huì)因?yàn)閮?nèi)存溢出或網(wǎng)絡(luò)阻塞導(dǎo)致上傳失??；2）在上傳較大的文件時(shí)會(huì)占用過多資源，導(dǎo)致瀏覽器甚至電腦沒有響應(yīng)，影響用戶體驗(yàn)；3）上傳失敗后，之前上傳的字節(jié)流將全部拋棄，必須全部重新上傳，極大地影響上傳效率。針對(duì)文件上傳的以上痛點(diǎn)問題，提出了一種基于分片的文件斷點(diǎn)續(xù)傳方法，對(duì)需上傳的文件按照一定的規(guī)則進(jìn)行分片，并結(jié)合多線程，提高上傳效率，同時(shí)采用斷點(diǎn)續(xù)傳的方式，解決上傳失敗后要全部重新上傳的問題。

1 常用的文件上傳方法

文件上傳的方式一般分為簡單文件上傳和文件斷點(diǎn)續(xù)傳兩種[6]。簡單文件上傳是指用戶通過客戶端（如瀏覽器）將文件傳輸?shù)椒?wù)器進(jìn)行保存，在傳輸過程中，服務(wù)器不保存文件上傳的狀態(tài)，如果傳輸過程中出現(xiàn)任何問題造成文件傳輸中止，文件需要重新傳輸。文件斷點(diǎn)續(xù)傳是指在使用文件斷點(diǎn)續(xù)傳服務(wù)時(shí)，服務(wù)端實(shí)時(shí)保存文件的上傳狀態(tài)，當(dāng)用戶主動(dòng)中止上傳或者其他原因?qū)е挛募蟼髦兄购笤俅紊蟼髟撐募r(shí)，系統(tǒng)無需從頭開始上傳，會(huì)從上一次上傳中止處開始傳輸數(shù)據(jù)。

簡單文件上傳的特點(diǎn)是流程簡單、容易實(shí)現(xiàn)，前后端只需很少的交互操作就能夠完成文件的傳輸和保存等工作。但簡單文件上傳的缺點(diǎn)也比較明顯，當(dāng)用戶上傳較大的文件，所需時(shí)間比較長時(shí)，上傳過程中出現(xiàn)任何問題，都可能導(dǎo)致上傳失敗，當(dāng)用戶重新上傳時(shí)，仍需要從文件頭部開始上傳，不僅會(huì)造成網(wǎng)絡(luò)帶寬的浪費(fèi)，且嚴(yán)重影響用戶體驗(yàn)[7]。

文件斷點(diǎn)續(xù)傳的基本原理就是在文件上傳過程中，定時(shí)或者實(shí)時(shí)保存文件的上傳狀態(tài)[8-9]。傳輸過程中保存文件上傳狀態(tài)有兩種方法：第一種是記錄文件已上傳的字節(jié)數(shù)，文件上傳被中止時(shí)，服務(wù)器端可以通過讀取臨時(shí)目錄中上傳文件的字節(jié)數(shù)來獲取上傳的進(jìn)度，當(dāng)用戶再次發(fā)起上傳時(shí)，服務(wù)器端可以從客戶端的請(qǐng)求中讀取文件名、文件長度和文件MD5 值等參數(shù)[10-11]，獲取文件的上傳進(jìn)度，并通知客戶端從服務(wù)端返回的字節(jié)處開始文件傳輸，直到文件傳輸完畢；第二種是將大文件按一定規(guī)則分片，逐個(gè)將文件分片傳輸?shù)椒?wù)端進(jìn)行保存，當(dāng)文件傳輸被中止時(shí)，服務(wù)端只損失正在上傳的分片，已上傳的分片不受影響，當(dāng)用戶再次上傳時(shí)，服務(wù)器端從客戶端請(qǐng)求中獲取上傳的文件信息，根據(jù)文件信息查詢?cè)撐募焉蟼鞯姆制涗洸⒎祷亟o客戶端，客戶端根據(jù)服務(wù)器端的信息解析分片記錄并上傳的未上傳的文件分片[12]。

通過對(duì)于基于字節(jié)數(shù)的斷點(diǎn)續(xù)傳算法和基于分片的斷點(diǎn)續(xù)傳算法的原理介紹可以發(fā)現(xiàn)基于字節(jié)數(shù)的斷點(diǎn)續(xù)傳算法的優(yōu)點(diǎn)在于原理簡單、便于實(shí)現(xiàn)，缺點(diǎn)是功能擴(kuò)展性差?；诜制臄帱c(diǎn)續(xù)傳算法在繼承了基于字節(jié)數(shù)的斷點(diǎn)續(xù)傳算法優(yōu)點(diǎn)的同時(shí)，還能根據(jù)實(shí)際應(yīng)用需求進(jìn)行功能擴(kuò)展，如為了發(fā)揮服務(wù)器多核CPU 的優(yōu)勢(shì)[13]，可以在基于分片上傳的基礎(chǔ)上采用多線程上傳模式，啟動(dòng)多個(gè)線程同時(shí)上傳多個(gè)分片。同時(shí)，基于分片的斷點(diǎn)續(xù)傳算法容錯(cuò)性較強(qiáng)[14]，當(dāng)用戶在首次上傳和二次上傳期間，對(duì)文件做過修改，使用基于字節(jié)數(shù)的斷點(diǎn)續(xù)傳算法方法，服務(wù)端無法判斷文件是否經(jīng)過修改，如果是對(duì)已上傳部分的內(nèi)容做的修改，那么文件是沒有意義的，用戶無法接受。如果使用基于分片的斷點(diǎn)續(xù)傳算法，在用戶修改過文件之后，二次上傳時(shí)，服務(wù)端可以檢測(cè)每個(gè)已上傳分片的MD5，如果發(fā)現(xiàn)兩次上傳的分片MD5 值不一致，則重傳該分片即可[15-16]，保證了文件傳輸?shù)恼_性和可靠性。

2 斷點(diǎn)續(xù)傳中的分片方法設(shè)計(jì)

基于分片的斷點(diǎn)續(xù)傳方法的關(guān)鍵問題是確定分片的大小。分片的大小對(duì)文件傳輸和存儲(chǔ)的的效率影響很大。文件分片過小會(huì)導(dǎo)致分片過多，增加上傳過程中的分片校驗(yàn)負(fù)擔(dān)和傳輸完成后分片重組的開銷；但如果分片過大，分片上傳的時(shí)間較長，且在上傳過程中出現(xiàn)任何問題造成該分片上傳不成功，則需要重傳該分片，失去了斷點(diǎn)續(xù)傳的優(yōu)勢(shì)。

分片的大小一般通過實(shí)驗(yàn)獲取，我校學(xué)習(xí)平臺(tái)的云存儲(chǔ)系統(tǒng)所用的Linux 系統(tǒng)磁盤采用ext4 格式，其磁盤塊（block）的大小是4 kB，通過對(duì)比測(cè)試，分片大小的設(shè)置為4 kB 的整數(shù)倍時(shí)，存儲(chǔ)效率相對(duì)較高，其主要原因是無論傳輸過程中的分片寫入，還是上傳完后的分片重組，每一次I/O 都是寫入和讀取磁盤中整數(shù)倍的Block 塊，能有效提高I/O 的性能，對(duì)學(xué)習(xí)平臺(tái)中2 000 余份學(xué)生作業(yè)和近200 份教師課件文件的大小和頻率進(jìn)行統(tǒng)計(jì)，如圖1 所示。

圖1 學(xué)習(xí)平臺(tái)上傳文件大小分布圖

在學(xué)習(xí)平臺(tái)中，10～100 MB 之間的文件占總上傳數(shù)的一半左右，所以選取的分片大小為4 MB，即每一個(gè)完整的分片都能夠?qū)憹MLinux 系統(tǒng)的1 024 個(gè)節(jié)點(diǎn)，在提升磁盤使用率和IO 性能的前提下，不會(huì)因?yàn)榉制^多造成分片合并時(shí)消耗過多資源，在具體實(shí)現(xiàn)時(shí)，為了提高性能，8 MB 以下的文件不做分片處理。

文件分片總數(shù)N的計(jì)算公式如下：

其中，fileSize 是文件大小，segmentSize 是預(yù)設(shè)的分片大小。分片上傳狀態(tài)用一個(gè)bit 數(shù)組保存，其中每一位的值代表該序號(hào)的片段的上傳狀態(tài)，0 表示未上傳，1 表示已上傳。如數(shù)組{0,1,1,0,0,1,0,1,1}表示正在上傳的文件分為9 個(gè)片段，其中第2、3、6、8、9 個(gè)片段已上傳到服務(wù)器，第1、4、5、7 個(gè)片段還未上傳成功。

服務(wù)器端負(fù)責(zé)更新并保存上傳狀態(tài)數(shù)組，直到文件傳輸完畢，客戶端按分片順序計(jì)算出分片的起止位置，并從文件中讀取這一段文件內(nèi)容上傳到服務(wù)器，如傳輸因故中止重新上傳時(shí)，從服務(wù)器獲取上傳狀態(tài)記錄，并解析出未上傳分片序號(hào)。每個(gè)文件分片的起止位置計(jì)算公式如下：

其中，Sx和Ex分別是第x個(gè)片段的起始和結(jié)束位置。

3 基于分片的斷點(diǎn)續(xù)傳方法的設(shè)計(jì)和實(shí)現(xiàn)

3.1 分片上傳前端實(shí)現(xiàn)

基于分片的斷點(diǎn)續(xù)傳方法前端實(shí)現(xiàn)使用百度WebFE(FEX)團(tuán)隊(duì)開發(fā)的一個(gè)基于HTML5 的開源JS項(xiàng)目WebUploader。WebUploader 封裝了文件分片、多線程并發(fā)、文件MD5 生成和校驗(yàn)、上傳進(jìn)度顯示等基礎(chǔ)功能，前端開發(fā)只需要在初始化WebUploader組件時(shí)將相關(guān)參數(shù)注入即可，基于分片的斷點(diǎn)續(xù)傳方法的前端關(guān)鍵代碼如圖2 所示。

圖2 前端實(shí)現(xiàn)關(guān)鍵代碼

create 方法負(fù)責(zé)使用傳入的參數(shù)初始化WebUploader 組件，傳入?yún)?shù)是JSON 格式文本，其中：

server：指定服務(wù)器端對(duì)應(yīng)處理文件上傳的接口；

chuncked：設(shè)置前端是否采用分片上傳方式；

chunckSize：設(shè)置文件分片大小，根據(jù)上一節(jié)的分析，文件分片大小設(shè)置為4 MB；

treads：設(shè)置文件上傳時(shí)同時(shí)啟動(dòng)的并發(fā)線程數(shù)，考慮到性能問題，該參數(shù)設(shè)置為3，即同時(shí)啟動(dòng)三個(gè)線程。

為實(shí)現(xiàn)文件秒傳功能，前端必須計(jì)算并上傳文件的MD5 值到服務(wù)器端，用戶在重復(fù)上傳文件時(shí)，服務(wù)器端會(huì)根據(jù)上傳的文件MD5 值進(jìn)行判斷，如果已上傳文件中存在同樣MD5 值，則表示該文件已經(jīng)上傳過，可以直接提示用戶上傳成功。通過測(cè)試發(fā)現(xiàn)，大文件的MD5 值計(jì)算非常消耗資源，為提高計(jì)算效率，在fileQueued 函數(shù)中，只將待上傳的文件名和文件尺寸組合hash，作為該文件的MD5 值。

3.2 分片上傳服務(wù)器端實(shí)現(xiàn)

服務(wù)器端接口采用Java SpringBoot 框架實(shí)現(xiàn)，Java 提供了專門處理文件分片隨機(jī)讀取的類，即RandomAccessFile（隨機(jī)訪問文件）類。該類是Java中功能最為豐富的文件訪問類，提供了眾多的文件訪問方法。RandomAccessFile 類支持對(duì)文件的隨機(jī)訪問方式，可以跳轉(zhuǎn)到文件的任意位置處讀寫數(shù)據(jù)。在訪問一個(gè)文件時(shí)，不必把文件從頭讀到尾，而是可以像訪問數(shù)據(jù)庫一樣隨意地訪問一個(gè)文件的某個(gè)部分。

基于分片的斷點(diǎn)續(xù)傳方法服務(wù)器端關(guān)鍵代碼如圖3 所示。

圖3 服務(wù)器端關(guān)鍵代碼

其中，checkFileMd5 方法用于檢驗(yàn)當(dāng)前請(qǐng)求上傳的文件在服務(wù)器上是否存在，并返回其狀態(tài)；uploadFile 方法負(fù)責(zé)將上傳的分片保存在臨時(shí)目錄；mergeFile 方法負(fù)責(zé)將文件分片合并。Controller層維持一個(gè)已上傳分片列表，記錄已經(jīng)上傳的分片信息，并依次循環(huán)調(diào)用這三個(gè)接口，直至文件上傳完成。

服務(wù)器端處理文件分片上傳的邏輯如下：

1）服務(wù)器端收到上傳請(qǐng)求后，獲取文件MD5值，調(diào)用接口checkFileMd5，查詢?cè)揗D5 是否已經(jīng)存在，如果存在，且文件傳輸狀態(tài)為已完成，則提示用戶文件已上傳，即實(shí)現(xiàn)了文件秒傳功能；

2）如果MD5 值存在，但文件傳輸狀態(tài)為未完成，則獲取已上傳分片列表，返回所有還沒上傳分塊的編號(hào)，前端進(jìn)行條件篩算出哪些沒上傳的分塊，然后進(jìn)行上傳，即實(shí)現(xiàn)斷點(diǎn)續(xù)傳功能；

3）如果MD5 值不存在，表示該文件是第一次上傳，則創(chuàng)建臨時(shí)目錄存放分片信息，每一次接收到分片時(shí)，判斷當(dāng)前分片所屬的文件的所有分片是否已經(jīng)傳輸完畢，如果已傳輸完成，則開始合并文件并轉(zhuǎn)移完整文件到目的目錄，并刪除臨時(shí)目錄，通知用戶文件傳輸成功。

4 實(shí)驗(yàn)分析

將簡單文件上傳和基于分片的斷點(diǎn)續(xù)傳方法進(jìn)行對(duì)比測(cè)試。測(cè)試網(wǎng)絡(luò)環(huán)境是校內(nèi)千兆網(wǎng)絡(luò)，正常上行帶寬為8～10 MB/s，測(cè)試服務(wù)器是虛擬化服務(wù)器，CPU32核，內(nèi)存為32 GB，硬盤空間為1 T，操作系統(tǒng)為CenterOS7，客戶端是個(gè)人電腦，CPU4核，Intel Core i7，內(nèi)存為16 GB，使用Chrome 瀏覽器進(jìn)行上傳測(cè)試。

考慮到學(xué)習(xí)平臺(tái)的實(shí)際運(yùn)行情況，該次測(cè)試使用簡單文件上傳方法、不同分片大小和不同線程的斷點(diǎn)續(xù)傳方法分別對(duì)四個(gè)不同大小的文件（4.1、53、102、511 MB）進(jìn)行上傳，對(duì)比其上傳效率，每個(gè)組合分別上傳三次，取其平均上傳時(shí)間（s），測(cè)試結(jié)果如表1 所示。

表1 測(cè)試結(jié)果

通過文件上傳測(cè)試可知，文件秒傳和斷點(diǎn)續(xù)傳的功能都已實(shí)現(xiàn)，從表1 可知，由于分片上傳相比簡單文件多了前端分片、MD5 值計(jì)算和服務(wù)器端合并分片等步驟的開銷，單線程模式下，不論分片大小，各種尺寸的文件傳輸效率都低于簡單文件上傳模式，在多線程模式下，分片尺寸4 MB 的上傳效率要顯著高于分片尺寸2 MB，但分片尺寸的繼續(xù)增長對(duì)上傳效率的提高影響不大。

5 結(jié)論

文中提出基于分片的斷點(diǎn)續(xù)傳方法，前端使用百度提供的開源項(xiàng)目WebUpload 組件，服務(wù)器端使用SpringBoot框架，利用Java提供的RandomAccessFile類實(shí)現(xiàn)文件的讀取和合并，該方法已在華南理工大學(xué)特色專業(yè)在線學(xué)習(xí)平臺(tái)上部署并運(yùn)行，有效地提高了文件上傳的效率和可靠性。