Java實(shí)現(xiàn)瀏覽器端大文件分片上傳
背景介紹
Breakpoint-http，是不是覺(jué)得這個(gè)名字有點(diǎn)low，break point斷點(diǎn)。這是一個(gè)大文件上傳的一種實(shí)現(xiàn)。因?yàn)楸緛?lái)很久沒(méi)寫(xiě)過(guò)前端了，本來(lái)想自己好好寫(xiě)一番js，可惜因?yàn)榉N種原因而作罷了。該項(xiàng)目是基于一款百度開(kāi)源的前端上傳控件：WebUploader（百度開(kāi)源的東西文檔一如既往的差，哈哈?；蛘呤俏依斫饽芰Σ睿?。
Breakpoint-http，當(dāng)初想實(shí)現(xiàn)這一塊web大文件上傳，是因?yàn)橛幸惶焱瑫r(shí)詢(xún)問(wèn)我這方面的知識(shí)，我發(fā)現(xiàn)好像在實(shí)戰(zhàn)中沒(méi)寫(xiě)過(guò)這類(lèi)的代碼啊。既然知道了自己不足那肯定要狠狠補(bǔ)一下。所以才有了這個(gè)項(xiàng)目。
對(duì)了這個(gè)項(xiàng)目是gradle+Spring Boot可能有部分人還沒(méi)接觸過(guò)這兩個(gè)東西，這里就不進(jìn)行講解了，畢竟這不是重點(diǎn)，把gradle當(dāng)成maven吧，雖然它還有更出色的功能。Spring Boot用來(lái)簡(jiǎn)化Spring應(yīng)用的初始搭建以及開(kāi)發(fā)過(guò)程，一個(gè)約定大于規(guī)范的框架。
項(xiàng)目介紹
Breakpoint-http 是一個(gè)基于大文件上傳，并參考網(wǎng)盤(pán)上傳文件，而基于web的大文件上傳實(shí)現(xiàn)項(xiàng)目。web中上傳大文件沒(méi)有桌面軟件那么容易，還好現(xiàn)在是身處于一個(gè)html5的時(shí)代。我們web端上傳文件常用的做法就是用表單上傳了，一旦上傳的文件大小較大，一旦帶寬跟不上，那用戶只能在哪里一直等著，不能做刷新頁(yè)面的操作，并且一旦產(chǎn)生網(wǎng)絡(luò)波動(dòng)，那么用戶所做的一切就白費(fèi)了。
Breakpoint-http就是為了保證在web端上傳大文件能達(dá)到基本的可靠性的一種方案，方法多種，可能的方案會(huì)更出色，歡迎討論。要讓大文件上傳能達(dá)到可用性，我們需要做到怎么樣的程度呢？
* 斷點(diǎn)續(xù)傳 最主要的功能之一，在斷網(wǎng)或者在暫停的情況下，能夠在上傳斷點(diǎn)中繼續(xù)上傳。
* 分塊上傳 也是斷點(diǎn)續(xù)傳的基礎(chǔ)之一，把大文件通過(guò)前端分塊，然后后臺(tái)在組在一起。
* 文件妙傳 這個(gè)相信大家在網(wǎng)盤(pán)中見(jiàn)過(guò)不少了，就是服務(wù)中已經(jīng)有人上傳過(guò)得文件，其他人再上傳這個(gè)文件就秒上傳到服務(wù)中去。
* 其他功能 把下面這些功能歸類(lèi)到其他，是因?yàn)樗鼈兓径际峭ㄟ^(guò)WebUploader(http://fex.baidu.com/webuploader)來(lái)實(shí)現(xiàn)的，很簡(jiǎn)單。
- 多線程上傳 多個(gè)線程上傳不同的塊文件。
- 文件進(jìn)度顯示 顯示文件的上傳完成情況。
- UI等等。
需要知識(shí)點(diǎn)
- 基于spring boot開(kāi)發(fā)的。
- WebUploader，WebUploader是由Baidu WebFE(FEX)團(tuán)隊(duì)開(kāi)發(fā)的一個(gè)簡(jiǎn)單的以HTML5為主，F(xiàn)LASH為輔的現(xiàn)代文件上傳組件。
- redis,key-value存儲(chǔ)系統(tǒng)，在這里我把redis用作存儲(chǔ)文件路徑來(lái)使用。
- Gradle，Gradle是一個(gè)基于JVM的構(gòu)建工具。這里我用Gradle頂替了Maven。嗯，多學(xué)點(diǎn)東西。
啟動(dòng)項(xiàng)目
main方法直接運(yùn)行：
(1)找到App啟動(dòng)類(lèi)（win.pangniu.learn包下）
(2)執(zhí)行main方法。
(3)然后用瀏覽器訪問(wèn)：http://localhost:9090
tomcat運(yùn)行：
(1)執(zhí)行命令gradle war。
(2)在out目錄下找到bphttp.war包。
(3)拷貝到tomcat，然后運(yùn)行tomcat。
(4)然后用瀏覽器訪問(wèn)：http://localhost:9090
項(xiàng)目示范
上傳完后的頁(yè)面
妙傳功能演示頁(yè)面
核心講解
核心原理
該項(xiàng)目核心就是文件分塊上傳。前后端要高度配合，需要雙方約定好一些數(shù)據(jù)，才能完成大文件分塊，我們?cè)陧?xiàng)目中要重點(diǎn)解決的以下問(wèn)題。
* 如何分片；
* 如何合成一個(gè)文件；
* 中斷了從哪個(gè)分片開(kāi)始。
如何分，利用強(qiáng)大的js庫(kù)，來(lái)減輕我們的工作，市場(chǎng)上已經(jīng)能有關(guān)于大文件分塊的輪子，雖然程序員的天性曾迫使我重新造輪子。但是因?yàn)闀r(shí)間的關(guān)系還有工作的關(guān)系，我只能罷休了。最后我選擇了百度的WebUploader來(lái)實(shí)現(xiàn)前端所需。
如何合，在合之前，我們還得先解決一個(gè)問(wèn)題，我們?nèi)绾螀^(qū)分分塊所屬那個(gè)文件的。剛開(kāi)始的時(shí)候，我是采用了前端生成了唯一uuid來(lái)做文件的標(biāo)志，在每個(gè)分片請(qǐng)求上帶上。不過(guò)后來(lái)在做秒傳的時(shí)候我放棄了，采用了Md5來(lái)維護(hù)分塊和文件關(guān)系。
在服務(wù)端合并文件，和記錄分塊的問(wèn)題，在這方面其實(shí)行業(yè)已經(jīng)給了很好的解決方案了。參考迅雷，你會(huì)發(fā)現(xiàn)，每次下載中的時(shí)候，都會(huì)有兩個(gè)文件，一個(gè)文件主體，另外一個(gè)就是文件臨時(shí)文件，臨時(shí)文件存儲(chǔ)著每個(gè)分塊對(duì)應(yīng)字節(jié)位的狀態(tài)。
這些都是需要前后端密切聯(lián)系才能做好，前端需要根據(jù)固定大小對(duì)文件進(jìn)行分片，并且請(qǐng)求中要帶上分片序號(hào)和大小。前端發(fā)送請(qǐng)求順利到達(dá)后臺(tái)后，服務(wù)器只需要按照請(qǐng)求數(shù)據(jù)中給的分片序號(hào)和每片分塊大小（分片大小是固定且一樣的）算出開(kāi)始位置，與讀取到的文件片段數(shù)據(jù)，寫(xiě)入文件即可。
功能分析
分塊上傳
分塊上傳可以說(shuō)是我們整個(gè)項(xiàng)目的基礎(chǔ)，像斷點(diǎn)續(xù)傳、暫停這些都是需要用到分塊。
分塊這塊相對(duì)來(lái)說(shuō)比較簡(jiǎn)單。前端是采用了webuploader，分塊等基礎(chǔ)功能已經(jīng)封裝起來(lái)，使用方便。
借助webUpload提供給我們的文件API,前端就顯得異常簡(jiǎn)單。
// 實(shí)例化wu
var uploader = WebUploader.create({
pick: {
id: '#picker',
label: '點(diǎn)擊選擇文件'
},
formData: {
uid: 0,
md5: '',
chunkSize: chunkSize
},
//dnd: '#dndArea',
//paste: '#uploader',
swf: 'js/Uploader.swf',
chunked: true,
chunkSize: chunkSize, // 字節(jié) 1M分塊
threads: 3,
server: 'index/fileUpload',
auto: false,
// 禁掉全局的拖拽功能。這樣不會(huì)出現(xiàn)圖片拖進(jìn)頁(yè)面的時(shí)候，把圖片打開(kāi)。
disableGlobalDnd: true,
fileNumLimit: 1024,
fileSizeLimit: 1024 * 1024 * 1024, // 200 M
fileSingleSizeLimit: 1024 * 1024 * 1024 // 50 M
});
分則必合。把大文件分片了，但是分片了就沒(méi)有原本文件功能，所以我們要把分片合成為原本的文件。我們只需要把分片按原本位置寫(xiě)入到文件中去。因?yàn)榍懊嬖砟且徊课覀円呀?jīng)講到了，我們知道分塊大小和分塊序號(hào)，我就可以知道該分塊在文件中的起始位置。所以這里使用RandomAccessFile是明智的，RandomAccessFile能在文件里面前后移動(dòng)。但是在andomAccessFile的絕大多數(shù)功能，已經(jīng)被JDK1.4的NIO的“內(nèi)存映射文件(memory-mapped files)”取代了。我在該項(xiàng)目中分別寫(xiě)了使用RandomAccessFile與MappedByteBuffer來(lái)合成文件。分別對(duì)應(yīng)的方法是uploadFileRandomAccessFile和uploadFileByMappedByteBuffer。兩個(gè)方法代碼如下。
public void uploadFileRandomAccessFile(MultipartFileParam param) throws IOException {
String fileName = param.getName();
String tempDirPath = finalDirPath + param.getMd5();
String tempFileName = fileName + "_tmp";
File tmpDir = new File(tempDirPath);
File tmpFile = new File(tempDirPath, tempFileName);
if (!tmpDir.exists()) {
tmpDir.mkdirs();
}
RandomAccessFile accessTmpFile = new RandomAccessFile(tmpFile, "rw");
long offset = CHUNK_SIZE * param.getChunk();
//定位到該分片的偏移量
accessTmpFile.seek(offset);
//寫(xiě)入該分片數(shù)據(jù)
accessTmpFile.write(param.getFile().getBytes());
// 釋放
accessTmpFile.close();
boolean isOk = checkAndSetUploadProgress(param, tempDirPath);
if (isOk) {
boolean flag = renameFile(tmpFile, fileName);
System.out.println("upload complete !!" + flag + " name=" + fileName);
}
}
public void uploadFileByMappedByteBuffer(MultipartFileParam param) throws IOException {
String fileName = param.getName();
String uploadDirPath = finalDirPath + param.getMd5();
String tempFileName = fileName + "_tmp";
File tmpDir = new File(uploadDirPath);
File tmpFile = new File(uploadDirPath, tempFileName);
if (!tmpDir.exists()) {
tmpDir.mkdirs();
}
RandomAccessFile tempRaf = new RandomAccessFile(tmpFile, "rw");
FileChannel fileChannel = tempRaf.getChannel();
//寫(xiě)入該分片數(shù)據(jù)
long offset = CHUNK_SIZE * param.getChunk();
byte[] fileData = param.getFile().getBytes();
MappedByteBuffer mappedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, offset, fileData.length);
mappedByteBuffer.put(fileData);
// 釋放
FileMD5Util.freedMappedByteBuffer(mappedByteBuffer);
fileChannel.close();
boolean isOk = checkAndSetUploadProgress(param, uploadDirPath);
if (isOk) {
boolean flag = renameFile(tmpFile, fileName);
System.out.println("upload complete !!" + flag + " name=" + fileName);
}
}
秒傳功能
秒傳功能，相信大家都體現(xiàn)過(guò)了，網(wǎng)盤(pán)上傳的時(shí)候，發(fā)現(xiàn)上傳的文件秒傳了。其實(shí)原理稍微有研究過(guò)的同學(xué)應(yīng)該知道，其實(shí)就是檢驗(yàn)文件MD5，記錄下上傳到系統(tǒng)的文件的MD5,在一個(gè)文件上傳前先獲取文件內(nèi)容MD5值或者部分取值MD5，然后在匹配系統(tǒng)上的數(shù)據(jù)。
Breakpoint-http實(shí)現(xiàn)秒傳原理，客戶端選擇文件之后，點(diǎn)擊上傳的時(shí)候觸發(fā)獲取文件MD5值，獲取MD5后調(diào)用系統(tǒng)一個(gè)接口（/index/checkFileMd5），查詢(xún)?cè)揗D5是否已經(jīng)存在（我在該項(xiàng)目中用redis來(lái)存儲(chǔ)數(shù)據(jù)，用文件MD5值來(lái)作key，value是文件存儲(chǔ)的地址。）接口返回檢查狀態(tài)，然后再進(jìn)行下一步的操作。相信大家看代碼就能明白了。
嗯，前端的MD5取值也是用了webuploader自帶的功能，這還是個(gè)不錯(cuò)的工具。
斷點(diǎn)續(xù)傳
斷點(diǎn)續(xù)傳，就是在文件上傳的過(guò)程中發(fā)生了中斷，人為因素（暫停）或者不可抗力（斷網(wǎng)或者網(wǎng)絡(luò)差）導(dǎo)致了文件上傳到一半失敗了。然后在環(huán)境恢復(fù)的時(shí)候，重新上傳該文件，而不至于是從新開(kāi)始上傳的。
前面也已經(jīng)講過(guò)，斷點(diǎn)續(xù)傳的功能是基于分塊上傳來(lái)實(shí)現(xiàn)的，把一個(gè)大文件分成很多個(gè)小塊，服務(wù)端能夠把每個(gè)上傳成功的分塊都落地下來(lái)，客戶端在上傳文件開(kāi)始時(shí)調(diào)用接口快速驗(yàn)證，條件選擇跳過(guò)某個(gè)分塊。
實(shí)現(xiàn)原理，就是在每個(gè)文件上傳前，就獲取到文件MD5取值，在上傳文件前調(diào)用接口（/index/checkFileMd5，沒(méi)錯(cuò)也是秒傳的檢驗(yàn)接口）如果獲取的文件狀態(tài)是未完成，則返回所有的還沒(méi)上傳的分塊的編號(hào)，然后前端進(jìn)行條件篩算出哪些沒(méi)上傳的分塊，然后進(jìn)行上傳。
/**
* 秒傳判斷，斷點(diǎn)判斷
*
* @return
*/
@RequestMapping(value = "checkFileMd5", method = RequestMethod.POST)
@ResponseBody
public Object checkFileMd5(String md5) throws IOException {
Object processingObj = stringRedisTemplate.opsForHash().get(Constants.FILE_UPLOAD_STATUS, md5);
if (processingObj == null) {
return new ResultVo(ResultStatus.NO_HAVE);
}
String processingStr = processingObj.toString();
boolean processing = Boolean.parseBoolean(processingStr);
String value = stringRedisTemplate.opsForValue().get(Constants.FILE_MD5_KEY + md5);
if (processing) {
return new ResultVo(ResultStatus.IS_HAVE, value);
} else {
File confFile = new File(value);
byte[] completeList = FileUtils.readFileToByteArray(confFile);
List<String> missChunkList = new LinkedList<>();
for (int i = 0; i < completeList.length; i++) {
if (completeList[i] != Byte.MAX_VALUE) {
missChunkList.add(i + "");
}
}
return new ResultVo<>(ResultStatus.ING_HAVE, missChunkList);
}
}
總結(jié)
身為一個(gè)具有拖延癥的程序猿，寫(xiě)個(gè)文檔及其不容易，這方面還是優(yōu)待加強(qiáng)，寫(xiě)代碼時(shí)間都還沒(méi)寫(xiě)這個(gè)文檔長(zhǎng)，并且寫(xiě)了那么久還那么爛的文檔。實(shí)在抱歉，望諒解。
獲取代碼
GitHub:https://github.com/Fourwenwen/Breakpoint-http.git
OSChina項(xiàng)目主頁(yè): https://git.oschina.net/Fourwenwen/breakpoint-http.git
參考文獻(xiàn)
[1]http://fex.baidu.com/webuploader/
[2]http://www.zuidaima.com/blog/2819949848316928.htm
[3]https://my.oschina.net/feichexia/blog/212318
到此這篇關(guān)于Java實(shí)現(xiàn)瀏覽器端大文件分片上傳的文章就介紹到這了,更多相關(guān)Java 大文件分片上傳內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
這篇文章主要介紹了Java結(jié)構(gòu)型模式之代理模式，代理模式是常用的java設(shè)計(jì)模式，他的特征是代理類(lèi)與委托類(lèi)有同樣的接口，代理類(lèi)主要負(fù)責(zé)為委托類(lèi)預(yù)處理消息、過(guò)濾消息、把消息轉(zhuǎn)發(fā)給委托類(lèi)，以及事后處理消息等2023-02-02
SpringBoot Redis緩存數(shù)據(jù)實(shí)現(xiàn)解析
這篇文章主要介紹了SpringBoot Redis緩存數(shù)據(jù)實(shí)現(xiàn)解析,文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-01-01
Java List移除相應(yīng)元素的超簡(jiǎn)潔寫(xiě)法分享
這篇文章主要介紹了Java List移除相應(yīng)元素的超簡(jiǎn)潔寫(xiě)法，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2021-11-11
這篇文章主要介紹了Java集合中的LinkedHashMap使用解析,LinkedHashMap是繼承于HashMap的,所以它的很多屬性和方法都是HashMap中的,那么它是怎么實(shí)現(xiàn)有序存儲(chǔ)的呢,需要的朋友可以參考下2023-12-12
Redis的字典緩存是支撐其高性能的一個(gè)關(guān)鍵因素,它使得Redis能夠以極快的速度處理大量的數(shù)據(jù),這篇文章主要介紹了springboot集成redis之字典緩存,需要的朋友可以參考下2024-07-07
SpringBoot中的multipartResolver上傳文件配置
這篇文章主要介紹了SpringBoot中的multipartResolver上傳文件配置，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2021-10-10
關(guān)于SpringCloud灰度發(fā)布的實(shí)現(xiàn)
這篇文章主要介紹了關(guān)于SpringCloud灰度發(fā)布的實(shí)現(xiàn),灰度發(fā)布又稱(chēng)金絲雀發(fā)布,是在系統(tǒng)升級(jí)的時(shí)候能夠平滑過(guò)渡的一種發(fā)布方式,灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定,在初始灰度的時(shí)候就可以發(fā)現(xiàn)、調(diào)整問(wèn)題,以保證其影響度,需要的朋友可以參考下2023-08-08
這篇文章主要為大家介紹了流式圖表拒絕增刪改查之kafka核心消費(fèi)邏輯詳解的上篇，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-04-04
Java實(shí)現(xiàn)的3des加密解密工具類(lèi)示例
這篇文章主要介紹了Java實(shí)現(xiàn)的3des加密解密工具類(lèi),結(jié)合完整實(shí)例形式分析了3des加密解密的具體步驟與相關(guān)操作技巧,需要的朋友可以參考下2017-10-10
教你用Springboot實(shí)現(xiàn)攔截器獲取header內(nèi)容
項(xiàng)目中遇到一個(gè)需求,對(duì)接上游系統(tǒng)是涉及到需要增加請(qǐng)求頭,請(qǐng)求頭的信息是動(dòng)態(tài)獲取的,需要?jiǎng)討B(tài)從下游拿到之后轉(zhuǎn)給上游,文中非常詳細(xì)的介紹了該需求的實(shí)現(xiàn),需要的朋友可以參考下2021-05-05