導(dǎo)讀：分片上傳、斷點(diǎn)續(xù)傳，這兩個(gè)名詞對(duì)于做過或者熟悉文件上傳的朋友來說應(yīng)該不會(huì)陌生，總結(jié)本篇文章希望對(duì)從事相關(guān)工作的同學(xué)能夠有所幫助或者啟發(fā)。

當(dāng)我們的文件特別大的時(shí)候，上傳是不是需要很長(zhǎng)的時(shí)間啊，這么長(zhǎng)時(shí)間的長(zhǎng)連接，如果網(wǎng)絡(luò)波動(dòng)了呢？中間網(wǎng)絡(luò)斷開了呢？在這么長(zhǎng)時(shí)間的過程中如果出現(xiàn)不穩(wěn)定的情況，本次上傳的所有內(nèi)容就全部失敗了，又要重新上傳。

分片上傳，就是將所要上傳的文件，按照一定的大小，將整個(gè)文件分隔成多個(gè)數(shù)據(jù)塊（我們稱之為 Part）來進(jìn)行分別上傳，上傳完之后再由服務(wù)端對(duì)所有上傳的文件進(jìn)行匯總整合成原始的文件。分片上傳不僅可以避免因網(wǎng)絡(luò)環(huán)境不好導(dǎo)致的一直需要從文件起始位置還是上傳的問題，還能使用多線程對(duì)不同分塊數(shù)據(jù)進(jìn)行并發(fā)發(fā)送，提高發(fā)送效率，降低發(fā)送時(shí)間。

一、背景

在系統(tǒng)用戶量突增以后，為了更好適配各群體的定制化需求。業(yè)務(wù)上慢慢實(shí)現(xiàn)了支持 C 端用戶自定義布局和配置，導(dǎo)致配置數(shù)據(jù)讀取 IO 激增。

為了更好優(yōu)化此類場(chǎng)景，將用戶自定義配置靜態(tài)化管理！也就是將對(duì)應(yīng)的配置文件生成靜態(tài)文件，在生成靜態(tài)文件的過程中遇到棘手的問題，配置文件文件過大導(dǎo)致在文件上傳服務(wù)器等待時(shí)間過長(zhǎng)，致使整個(gè)業(yè)務(wù)場(chǎng)景性能整體下滑。

image

二、生成配置文件

生成文件三大要素

• 文件名

• 文件內(nèi)容

• 文件存儲(chǔ)格式

文件內(nèi)容、文件存儲(chǔ)格式都好理解和處理，當(dāng)然先前整理過微服務(wù)中常用的加密方式

• 微服務(wù)架構(gòu) | 微服務(wù)有哪些常用的加密方式 (一)

• 微服務(wù)架構(gòu) | 數(shù)據(jù)加密有哪些常用的加密方式（二）

這里做下補(bǔ)充說明，如果要想對(duì)文件內(nèi)容進(jìn)行加密可以考慮。但是本文的案例場(chǎng)景對(duì)于配置信息保密程度較低，這里不做拓展。

而對(duì)于文件名的命名規(guī)范具體結(jié)合業(yè)務(wù)場(chǎng)景來定，通常都是以文件概要+時(shí)間戳格式為主。但是這類命名規(guī)范容易導(dǎo)致文件名沖突，造成沒有必要的后續(xù)麻煩。

所以我這里對(duì)于文件名的命名做了特殊處理，有處理過前端 Route 路由經(jīng)驗(yàn)的應(yīng)該能聯(lián)想到，文件名可以通過基于內(nèi)容生成 Hash 值來代替。

在Spring 3.0 之后提供了計(jì)算摘要的的方法。

DigestUtils#md

復(fù)制代碼

返回給定字節(jié)的 MD5 摘要的十六進(jìn)制字符串表示形式。

image

md5DigestAsHex 源碼

/**

復(fù)制代碼

文件名、內(nèi)容、后綴(存儲(chǔ)格式)確定后直接生成文件

/**

復(fù)制代碼

通過內(nèi)容生成文件優(yōu)點(diǎn)不言而喻，可以極大減少我們主動(dòng)基于內(nèi)容比較來生成新的文件、如果文件內(nèi)容較大生成對(duì)應(yīng)的文件名相同則表示內(nèi)容未做任何調(diào)整，此時(shí)我們也就不用做后續(xù)的文件更新操作。

三、分片上傳附件

所謂的分片上傳，就是將所要上傳的文件，按照一定的大小，將整個(gè)文件分隔成多個(gè)數(shù)據(jù)塊（我們稱之為 Part）來進(jìn)行分別上傳，上傳完之后再由服務(wù)端對(duì)所有上傳的文件進(jìn)行匯總整合成原始的文件。分片上傳不僅可以避免因網(wǎng)絡(luò)環(huán)境不好導(dǎo)致的一直需要從文件起始位置還是上傳的問題，還能使用多線程對(duì)不同分塊數(shù)據(jù)進(jìn)行并發(fā)發(fā)送，提高發(fā)送效率，降低發(fā)送時(shí)間。

image

分片上傳主要適用于以下幾種場(chǎng)景：

• 網(wǎng)絡(luò)環(huán)境不好：當(dāng)出現(xiàn)上傳失敗的時(shí)候，可以對(duì)失敗的 Part 進(jìn)行獨(dú)立的重試，而不需要重新上傳其他的 Part。

• 斷點(diǎn)續(xù)傳：中途暫停之后，可以從上次上傳完成的 Part 的位置繼續(xù)上傳。

• 加速上傳：要上傳到 OSS 的本地文件很大的時(shí)候，可以并行上傳多個(gè) Part 以加快上傳。

• 流式上傳：可以在需要上傳的文件大小還不確定的情況下開始上傳。這種場(chǎng)景在視頻監(jiān)控等行業(yè)應(yīng)用中比較常見。

• 文件較大：一般文件比較大時(shí)，默認(rèn)情況下一般都會(huì)采用分片上傳。

image

分片上傳的整個(gè)流程大致如下：

• 將需要上傳的文件按照一定的分割規(guī)則，分割成相同大小的數(shù)據(jù)塊；

• 初始化一個(gè)分片上傳任務(wù)，返回本次分片上傳唯一標(biāo)識(shí)；

• 按照一定的策略（串行或并行）發(fā)送各個(gè)分片數(shù)據(jù)塊；

• 發(fā)送完成后，服務(wù)端根據(jù)判斷數(shù)據(jù)上傳是否完整，如果完整，則進(jìn)行數(shù)據(jù)塊合成得到原始文件

? 定義分片規(guī)則大小

默認(rèn)情況都以文件達(dá)到 20MB 進(jìn)行強(qiáng)制分片

/**

復(fù)制代碼

為了方便調(diào)試，強(qiáng)制分片文件的閾值調(diào)整為 1KB

? 定義分片上傳對(duì)象

如上圖紅色序號(hào)的文件碎片，定義分片上傳對(duì)象基礎(chǔ)屬性包含附件文件名、原始文件大小、原始文件 MD5 值、分片總數(shù)、每個(gè)分片大小、當(dāng)前分片大小、當(dāng)前分片序號(hào)等

定義基礎(chǔ)屬于便于后續(xù)對(duì)文件合理分割、分片的合并等業(yè)務(wù)拓展，當(dāng)然根據(jù)業(yè)務(wù)場(chǎng)景可以定義拓展屬性。

分片總數(shù)

long totalSlices = fileSize % forceSliceSize == 0 ? 

復(fù)制代碼

image

每個(gè)分片大小

long eachSize = fileSize % totalSlices == 0 ? 

復(fù)制代碼

image

原始文件的 MD5 值

MD5Util.hex(file)

復(fù)制代碼

如：

當(dāng)前附件大小為：3382KB，強(qiáng)制分片大小限制為 1024KB

通過上述計(jì)算：分片數(shù)量為 4 個(gè)，每個(gè)分片大小為 846KB

image

? 讀取每個(gè)分片的數(shù)據(jù)字節(jié)

標(biāo)記當(dāng)前字節(jié)下標(biāo)，循環(huán)讀取 4 個(gè)分片的數(shù)據(jù)字節(jié)

try (InputStream inputStream = new FileInputStream(uploadVO.getFile())) {

復(fù)制代碼

image

三、總結(jié)

所謂的分片上傳，就是將所要上傳的文件，按照一定的大小，將整個(gè)文件分隔成多個(gè)數(shù)據(jù)塊（我們稱之為 Part）來進(jìn)行分別上傳。

處理大文件進(jìn)行分片主要核心確定三大點(diǎn)

• 文件分片粒度大小

• 分片如何讀取

• 分片如何存儲(chǔ)

本篇文章主要分析和處理大文件上傳過程中如何針對(duì)大文件文件文件內(nèi)容比較、進(jìn)行分片處理。合理設(shè)置分片閾值以及如何讀取和標(biāo)記分片。希望對(duì)從事相關(guān)工作的同學(xué)能夠有所幫助或者啟發(fā)。后續(xù)會(huì)對(duì)分片如何存儲(chǔ)、標(biāo)記、合并文件進(jìn)行詳細(xì)解讀。

原文：微服務(wù)架構(gòu) | 怎樣解決超大附件分片上傳？