核心原理：

該項目核心就是文件分塊上傳。前后端要高度配合，需要雙方約定好一些數(shù)據(jù)，才能完成大文件分塊，我們在項目中要重點解決的以下問題。

*如何分片；

*如何合成一個文件；

*中斷了從哪個分片開始。

如何分，利用強大的js庫，來減輕我們的工作，市場上已經(jīng)能有關于大文件分塊的輪子，雖然程序員的天性曾迫使我重新造輪子。但是因為時間的關系還有工作的關系，我只能罷休了。最后我選擇了百度的WebUploader來實現(xiàn)前端所需。

如何合，在合之前，我們還得先解決一個問題，我們?nèi)绾螀^(qū)分分塊所屬那個文件的。剛開始的時候，我是采用了前端生成了唯一uuid來做文件的標志，在每個分片請求上帶上。不過后來在做秒傳的時候我放棄了，采用了Md5來維護分塊和文件關系。

在服務端合并文件，和記錄分塊的問題，在這方面其實行業(yè)已經(jīng)給了很好的解決方案了。參考迅雷，你會發(fā)現(xiàn)，每次下載中的時候，都會有兩個文件，一個文件主體，另外一個就是文件臨時文件，臨時文件存儲著每個分塊對應字節(jié)位的狀態(tài)。

這些都是需要前后端密切聯(lián)系才能做好，前端需要根據(jù)固定大小對文件進行分片，并且請求中要帶上分片序號和大小。前端發(fā)送請求順利到達后臺后，服務器只需要按照請求數(shù)據(jù)中給的分片序號和每片分塊大?。ǚ制笮∈枪潭ㄇ乙粯拥模┧愠鲩_始位置，與讀取到的文件片段數(shù)據(jù)，寫入文件即可。

為了便于開發(fā)，我 將服務端的業(yè)務邏輯進行了如下劃分，分成初始化，塊處理，文件上傳完畢等。

服務端的業(yè)務邏輯模塊如下

功能分析：

文件夾生成模塊

文件夾上傳完畢后由服務端進行掃描代碼如下

分塊上傳，分塊處理邏輯應該是最簡單的邏輯了，up6已經(jīng)將文件進行了分塊，并且對每個分塊數(shù)據(jù)進行了標識，這些標識包括文件塊的索引，大小，偏移，文件MD5，文件塊MD5（需要開啟）等信息，服務端在接收這些信息后便可以非常方便的進行處理了。比如將塊數(shù)據(jù)保存到分布式存儲系統(tǒng)中

分塊上傳可以說是我們整個項目的基礎，像斷點續(xù)傳、暫停這些都是需要用到分塊。

分塊這塊相對來說比較簡單。前端是采用了webuploader，分塊等基礎功能已經(jīng)封裝起來，使用方便。

借助webUpload提供給我們的文件API,前端就顯得異常簡單。

前臺HTML模板

分則必合。把大文件分片了，但是分片了就沒有原本文件功能，所以我們要把分片合成為原本的文件。我們只需要把分片按原本位置寫入到文件中去。因為前面原理那一部我們已經(jīng)講到了，我們知道分塊大小和分塊序號，我就可以知道該分塊在文件中的起始位置。所以這里使用RandomAccessFile是明智的，RandomAccessFile能在文件里面前后移動。但是在andomAccessFile的絕大多數(shù)功能，已經(jīng)被JDK1.4的NIO的“內(nèi)存映射文件(memory-mapped files)”取代了。我在該項目中分別寫了使用RandomAccessFile與MappedByteBuffer來合成文件。分別對應的方法是uploadFileRandomAccessFile和uploadFileByMappedByteBuffer。兩個方法代碼如下。

秒傳功能

服務端邏輯

秒傳功能，相信大家都體現(xiàn)過了，網(wǎng)盤上傳的時候，發(fā)現(xiàn)上傳的文件秒傳了。其實原理稍微有研究過的同學應該知道，其實就是檢驗文件MD5，記錄下上傳到系統(tǒng)的文件的MD5,在一個文件上傳前先獲取文件內(nèi)容MD5值或者部分取值MD5，然后在匹配系統(tǒng)上的數(shù)據(jù)。

Breakpoint-http實現(xiàn)秒傳原理，客戶端選擇文件之后，點擊上傳的時候觸發(fā)獲取文件MD5值，獲取MD5后調(diào)用系統(tǒng)一個接口（/index/checkFileMd5），查詢該MD5是否已經(jīng)存在（我在該項目中用redis來存儲數(shù)據(jù)，用文件MD5值來作key，value是文件存儲的地址。）接口返回檢查狀態(tài)，然后再進行下一步的操作。相信大家看代碼就能明白了。

嗯，前端的MD5取值也是用了webuploader自帶的功能，這還是個不錯的工具。

控件計算完文件MD5后會觸發(fā)md5_complete事件，并傳值md5，開發(fā)者只需要處理這個事件即可，

斷點續(xù)傳

up6已經(jīng)自動對斷點續(xù)傳進行了處理，不需要開發(fā)都再進行單獨的處理。

在f_post.jsp中接收這些參數(shù)，并進行處理，開發(fā)者只需要關注業(yè)務邏輯，不需要關注其它的方面。

斷點續(xù)傳，就是在文件上傳的過程中發(fā)生了中斷，人為因素（暫停）或者不可抗力（斷網(wǎng)或者網(wǎng)絡差）導致了文件上傳到一半失敗了。然后在環(huán)境恢復的時候，重新上傳該文件，而不至于是從新開始上傳的。

前面也已經(jīng)講過，斷點續(xù)傳的功能是基于分塊上傳來實現(xiàn)的，把一個大文件分成很多個小塊，服務端能夠把每個上傳成功的分塊都落地下來，客戶端在上傳文件開始時調(diào)用接口快速驗證，條件選擇跳過某個分塊。

實現(xiàn)原理，就是在每個文件上傳前，就獲取到文件MD5取值，在上傳文件前調(diào)用接口（/index/checkFileMd5，沒錯也是秒傳的檢驗接口）如果獲取的文件狀態(tài)是未完成，則返回所有的還沒上傳的分塊的編號，然后前端進行條件篩算出哪些沒上傳的分塊，然后進行上傳。

當接收到文件塊后就可以直接寫入到服務器的文件中

這是文件塊上傳的效果

這是文件夾上傳完后的效果

這是文件夾上傳完后在服務端的存儲結構

以上就是本文的全部內(nèi)容，希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論