服務(wù)器端文件分片合并的思考和實(shí)踐

huaixiaoz 發(fā)布于2019-07-25 13:24 / 3577人閱讀

摘要：原文服務(wù)器端文件分片合并的思考和實(shí)踐筆者在項(xiàng)目中處理大文件上傳的需求，仿照七牛云存儲(chǔ)的接口設(shè)計(jì)。然而，在服務(wù)器端文件合并時(shí)遇到了很大的問題合并太慢。服務(wù)器端的分片合并現(xiàn)在進(jìn)入本文的重點(diǎn)。

原文：服務(wù)器端文件分片合并的思考和實(shí)踐

筆者在項(xiàng)目中處理大文件上傳的需求，仿照七牛云存儲(chǔ)的接口設(shè)計(jì)。然而，在服務(wù)器端文件合并時(shí)遇到了很大的問題：合并太慢。本文記錄了當(dāng)時(shí)的思路和解決的方案

大文件的需求

文件上傳是個(gè)很常見的需求。盡管HTTP是基于TCP上層的協(xié)議，但是HTTP協(xié)議本身并不適合處理超大的請(qǐng)求體，文件上傳有很大的穩(wěn)定性問題，如果中途斷開了，將前功盡棄。為了改善用戶體驗(yàn)或者緩解服務(wù)器壓力，通常會(huì)考慮將文件分成小片，將小片一個(gè)個(gè)上傳，如果中途斷開了也能從某個(gè)失敗的小片開始繼續(xù)上傳。

在前端的處理上，對(duì)于Web頁(yè)面，可以采用plupload作為上傳組件，該組件支持html5、flash、sl等多種上傳方式，因此，可以提供較好的瀏覽器兼容性。七牛云存儲(chǔ)的js-sdk就是基于這個(gè)組件開發(fā)的。不過本文的重點(diǎn)并不是討論前端技術(shù)，關(guān)于前端就到此為止。

服務(wù)器端的策略

既然文件被分成片上傳，那么自然在服務(wù)器端需要將分片合并成原始的文件，那么這里存在兩種策略

邊傳邊合并：每上傳一個(gè)分片，就將分片合并到文件的后面

傳完一起合并：先將分片保存起來，客戶端發(fā)起一個(gè)合并請(qǐng)求時(shí)，再將分片合并成一個(gè)文件

邊傳邊合并

這種方式要注意：

由于HTTP的無狀態(tài)性，這種方式需要客戶端和服務(wù)器端維持一個(gè)標(biāo)識(shí)。服務(wù)器端根據(jù)標(biāo)識(shí)，才能知道分片應(yīng)該向哪個(gè)目標(biāo)文件Append

如果客戶端中途停止上傳，那么保存在服務(wù)器上的目標(biāo)文件將成為垃圾文件，文件即不能被刪除又沒有利用價(jià)值。因?yàn)榉?wù)端無法知道文件究竟的完成狀態(tài)還是正在進(jìn)行狀態(tài)

由于分片直接合并進(jìn)了文件，無法管理分片

傳完一起合并

七牛云存儲(chǔ)就是使用的這種策略，具體的實(shí)現(xiàn)方式如下：

每上傳一個(gè)分片，服務(wù)端將分片保存下來，并返回客戶端一個(gè)唯一標(biāo)識(shí)ctx，這個(gè)標(biāo)識(shí)ctx與當(dāng)前這個(gè)分片關(guān)聯(lián)

客戶端應(yīng)當(dāng)妥善保存每個(gè)分片的標(biāo)識(shí)，以及它們的先后順序

服務(wù)端需要提供一個(gè)接口，客戶端用這個(gè)接口請(qǐng)求分片合并，在請(qǐng)求時(shí)候?qū)?biāo)識(shí)按順序告知服務(wù)端，ctx0,ctx1,ctx2...

服務(wù)端根據(jù)標(biāo)識(shí)的順序找到對(duì)應(yīng)的分片，并合并成完成的文件

這種設(shè)計(jì)解決了客戶端中途停止上傳帶來的服務(wù)器端資源的浪費(fèi)，因?yàn)榉制际钦谶M(jìn)行態(tài)，可以對(duì)時(shí)間很早的分片進(jìn)行清理。而且分片被記錄了下來，容易對(duì)分片進(jìn)行一些管理。

服務(wù)器端的分片合并

現(xiàn)在進(jìn)入本文的重點(diǎn)。文件合并是IO操作，IO操作是最耗時(shí)的工作了。上文的第一種策略，有一個(gè)好處是文件的合并是在上傳的過程中完成的，對(duì)于用戶來說幾乎感知不到文件Append時(shí)的延時(shí)。然而，第二種策略的文件合并卻是在一個(gè)時(shí)刻同時(shí)進(jìn)行的。筆者測(cè)試過，即使是4-5個(gè)4MB的分片，也會(huì)使客戶端有明顯的延遲感。如果分片再多的話，延遲將更大，甚至請(qǐng)求超時(shí)，這是不能接受的。

但是筆者在七牛云上的測(cè)試，合并的請(qǐng)求在七牛的服務(wù)器端幾乎沒有延時(shí)。為此，筆者還發(fā)了一問：七牛云mkfile如何實(shí)現(xiàn)將大量的文件chunk快速合并的，但是七牛的技術(shù)太“吝嗇”，一點(diǎn)也不透露。那該怎么辦呢？

并行處理?

由于是將分片合并，那么很容易會(huì)想到并行。類似歸并排序的思想，將合并任務(wù)分開，然后通過集群服務(wù)器的協(xié)調(diào)完成合并。但是筆者對(duì)這方面是知之甚少，而且這種方案會(huì)使原本簡(jiǎn)單的架構(gòu)變的異常復(fù)雜，不敢采用這種方案。而且感覺會(huì)有坑：

并行處理往往是異步的，如何處理好與web服務(wù)器的同步

再怎么分任務(wù)，合并終究是IO操作，IO操作總是要耗費(fèi)時(shí)間的

文件系統(tǒng)底層處理?

仔細(xì)思考合并這個(gè)動(dòng)作，實(shí)際上是將多個(gè)文件在文件系統(tǒng)里面復(fù)制了一次，而文件的內(nèi)容并沒有任何的變化。如果能夠在文件系統(tǒng)層面將分片直接連接起來話，合并文件僅僅是修改一些指針，速度將十分的快。不過文件系統(tǒng)各不相同，能不能實(shí)現(xiàn)還需要看。而且，由于筆者使用nfs作為數(shù)據(jù)存儲(chǔ)，nfs的文件讀寫完全是通過接口提供的，接口也不提供底層的文件系統(tǒng)操作，所以似乎是無法實(shí)現(xiàn)。

為什么非要合并!

再思考下去，如果文件系統(tǒng)無法做到將分片直接連接起來的的話，那么從用戶接口層(HTTP)是否能做到呢？試想，通過HTTP的方式提供文件的訪問，如果HTTP服務(wù)器能夠知道這個(gè)文件是由多個(gè)小文件按何種順序組成的，那么就可以按照順序?qū)⒎制来畏旁谕粋€(gè)HTTP流中返回，對(duì)用戶來說一次請(qǐng)求還是得到一個(gè)文件，好像文件是合并好的一樣，但實(shí)際上文件在文件系統(tǒng)并不存在。

這樣做需要多帶帶將分片的順序維護(hù)好，每次都要讀出分片的順序和位置，然后依次一個(gè)個(gè)寫入HTTP流中。但是高層的Web編程框架似乎無法支持這種做法。

巧用Nginx避免文件合并

筆者立刻想到了之前用過的Nginx模塊mod_zip，這個(gè)模塊能夠?qū)⒍鄠€(gè)文件打包以zip流的方式返回。現(xiàn)在的需求其實(shí)跟這個(gè)模塊的工作幾乎差不多，甚至還要更簡(jiǎn)單。苦苦尋覓網(wǎng)上的Nginx模塊，似乎沒有找到筆者需要的，于是決定自己基于mod_zip開發(fā)一個(gè)。幸好，之前用mod_zip的時(shí)候看過一些源碼。

目前這個(gè)模塊筆者命名為mod_pieces，已經(jīng)開發(fā)完成并在windows和linux兩個(gè)平臺(tái)下測(cè)試通過，唯一不好的是無法支持HTTP Range，HTTP Range有點(diǎn)難弄，以后可能有時(shí)間再慢慢實(shí)現(xiàn)。代碼還沒有整理，有時(shí)間放到Github上去共享。

mod_pieces的工作方式和原理和mod_zip很相似，有進(jìn)一步需求的讀者可以移步至：利用Nginx第三方模塊，實(shí)現(xiàn)附件打包下載

后續(xù)還是要合并的

現(xiàn)在用戶那頭可以"欺騙"成功了，但是如果系統(tǒng)本身需要對(duì)文件進(jìn)一步處理，比如視頻的格式轉(zhuǎn)換，那么還是需要將文件合并起來的，不過這個(gè)時(shí)候就可以用一個(gè)后臺(tái)的服務(wù)異步的慢慢做了，用戶不會(huì)感知。基于這些復(fù)雜的問題，筆者已經(jīng)把文件上傳下載和處理作為的一個(gè)全新的產(chǎn)品功能獨(dú)立出來，以支持主產(chǎn)品對(duì)文件的各種功能需求。

后記

本文沒有一張圖片，沒有一行代碼，有些不適應(yīng)。文字雖短，但是這些東西都是經(jīng)過筆者的實(shí)踐并且有感而發(fā)，希望有個(gè)總結(jié)，并能夠帶來更多的交流。