摘要:前一陣子被一個(gè)需求困擾附件的打包下載,需要將一批邏輯上一起的文件,讓用戶通過一個(gè)下載按鈕打包下載。用戶體驗(yàn)也是問題,因?yàn)楸仨毚虬瓿珊?,才能開始返回,無法邊打包邊下載。
mod_zip介紹前一陣子被一個(gè)需求困擾:附件的打包下載,需要將一批邏輯上一起的文件,讓用戶通過一個(gè)下載按鈕打包下載。首先想到的方案是服務(wù)端調(diào)用什么zip之類的類庫,將文件打包好后返回客戶端。但是這樣做有一個(gè)很明顯的問題:文件很多很大的情況下,打包可能會(huì)占用大量的內(nèi)存和cpu,就算在磁盤上構(gòu)建臨時(shí)的打包文件,也會(huì)增加服務(wù)器的磁盤IO負(fù)擔(dān),而且這些臨時(shí)的文件無故占用大量的磁盤空間,刪除還是個(gè)問題。用戶體驗(yàn)也是問題,因?yàn)楸仨毚虬瓿珊?,才能開始返回,無法邊打包邊下載。本來都準(zhǔn)備放棄了,不過發(fā)現(xiàn)百度網(wǎng)盤好像實(shí)現(xiàn)了這個(gè)功能,于是再次考慮如何實(shí)現(xiàn)。想到我們實(shí)際上使用了Nginx作為文件服務(wù)器,會(huì)不會(huì)有第三方模塊能夠支持這種功能呢?尋覓之后果然有結(jié)果,就是本文要探討的mod_zip。
mod_zip能夠動(dòng)態(tài)的構(gòu)建zip包,這種動(dòng)態(tài)體現(xiàn)在當(dāng)Nginx作為反向代理服務(wù)器的時(shí)候,該模塊能夠根據(jù)上游服務(wù)器返回的文件列表來打包文件。mod_zip實(shí)際上是利用Nginx的subrequest功能,將zip流發(fā)送到客戶端的,而且它實(shí)際上只打包不壓縮,所以借助Nginx本身作為文件服務(wù)器的能力,該模塊的內(nèi)存占用十分少,對(duì)于上G的大文件也沒有問題。zip文件本身是結(jié)構(gòu)化的,可以自定義目錄結(jié)構(gòu),所以對(duì)于mod_zip而言,要做的只是添加zip的頭部尾部和zip內(nèi)部的目錄結(jié)構(gòu)元數(shù)據(jù)而已,文件數(shù)據(jù)本身依靠Nginx自身的機(jī)制發(fā)送。
除此之外,還有如下兩點(diǎn):
由于使用subrequest機(jī)制,文件甚至可以不在Nginx的服務(wù)器本身,可以是上游服務(wù)器,甚至是互聯(lián)網(wǎng)的遠(yuǎn)程服務(wù)器上
在添加crc校驗(yàn)后,mod_zip還能夠支持HTTP的Range,支持?jǐn)帱c(diǎn)續(xù)傳
基本使用 安裝下載源碼:
$ git clone https://github.com/evanmiller/mod_zip.git
重新編譯Nginx,不要make install:
$ ./configure --add-module=/src/mod_zip $ make
將生成的二進(jìn)制文件覆蓋現(xiàn)有的二進(jìn)制文件。通常編譯出來的二進(jìn)制文件位于源碼目錄的objs/nginx。更多關(guān)于如何添加第三方模塊看如何安裝nginx第三方模塊
使用方法該模塊不需要在nginx.conf中配置任何東西,一切的行為取決于上游服務(wù)器的響應(yīng)內(nèi)容。mod_zip規(guī)定當(dāng)響應(yīng)頭中包含X-Archive-Files的時(shí)候,將啟用mod_zip的功能:
X-Archive-Files: zip
同時(shí),響應(yīng)的body中需要包含一個(gè)欲打包的文件的列表,如:
1034ab38 428 /foo.txt My Document1.txt 83e8110b 100339 /bar.txt My Other Document1.txt
每一行表示一個(gè)文件描述,行與行之間有一個(gè)換行符(最后也有個(gè)換行)。每行從左向右以空格分隔,依次是文件的crc-32校驗(yàn),文件大小(Byte),文件的uri,文件名。其中crc-32可以忽略,并用-代替,文件名可以包含目錄,會(huì)體現(xiàn)在最后的壓縮包中的目錄結(jié)構(gòu)中。
重點(diǎn)是文件的uri怎么理解。這里的/foo.txt和/bar.txt并非指向文件系統(tǒng)的路徑,而是一個(gè)子請(qǐng)求的地址。比如上面的/foo.txt實(shí)際上會(huì)產(chǎn)生一個(gè)Nginx自身的請(qǐng)求:http://host/foo.txt,至于這個(gè)請(qǐng)求得到什么又要根據(jù)nginx.conf中的配置決定了。這樣的設(shè)計(jì)十分靈活,例如下面的配置:
location ~ "^/(?server[12])/(? .*txt)" { proxy_pass http://$srv.domain.com/$file }
于是,可以這樣使用文件uri:
1034ab38 428 /server1/foo.txt My Document1.txt 83e8110b 100339 /server2/bar.txt My Other Document1.txt
這樣兩個(gè)文件分別會(huì)向遠(yuǎn)程服務(wù)器請(qǐng)求文件:
http://server1.domain.com/foo.txt http://server2.domain.com/bar.txt
上游服務(wù)器可以通過在頭部注入Content-Disposition來控制zip文件的輸出文件名
Content-Disposition: attachment; filename=foobar.zip上游服務(wù)器示例
下面是個(gè)測(cè)試用的上游服務(wù)器例子
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://systransis.cn/yun/39072.html
摘要:原文利用第三方模塊,實(shí)現(xiàn)附件打包下載前一陣子被一個(gè)需求困擾附件的打包下載,需要將一批邏輯上一起的文件,讓用戶通過一個(gè)下載按鈕打包下載。用戶體驗(yàn)也是問題,因?yàn)楸仨毚虬瓿珊螅拍荛_始返回,無法邊打包邊下載。 原文:利用Nginx第三方模塊,實(shí)現(xiàn)附件打包下載 前一陣子被一個(gè)需求困擾:附件的打包下載,需要將一批邏輯上一起的文件,讓用戶通過一個(gè)下載按鈕打包下載。首先想到的方案是服務(wù)端調(diào)用什么...
摘要:原文服務(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í)的思路和解決的方案 大文件的...
摘要:本文轉(zhuǎn)自豆?jié){下每天備份數(shù)據(jù)庫并發(fā)送到指定郵箱一配置郵箱這里使用的是網(wǎng)易郵箱郵箱的服務(wù),服務(wù)器是。成功收到郵件,沒問題。編寫腳本和定時(shí)任務(wù)萬事俱備,接下來要做自動(dòng)化工作建立一個(gè)備份腳本,并使用定時(shí)任務(wù)每天執(zhí)行它。 本文轉(zhuǎn)自豆?jié){Melon :linux下每天備份Mysql數(shù)據(jù)庫并發(fā)送到指定郵箱 一、配置郵箱 這里使用的是網(wǎng)易郵箱126郵箱的STMP服務(wù),服務(wù)器是smtp.126.com。...
摘要:文章涉及到路由模塊化,懶加載,安裝,打包配置板塊。項(xiàng)目復(fù)雜,路由變多,代碼維護(hù)性降低,從路由模塊化開始一步步優(yōu)化,解決各種。無法啟動(dòng)服務(wù),報(bào)錯(cuò)參考資料發(fā)現(xiàn)端口沖突,已經(jīng)在服務(wù)中已經(jīng)配置端口。服務(wù)端口更改為。 文章涉及到VUE路由模塊化,懶加載,nginx安裝,打包配置板塊。項(xiàng)目復(fù)雜,路由變多,代碼維護(hù)性降低,從路由模塊化開始一步步優(yōu)化,解決各種BUG。參考了很多方法,會(huì)在文章中引用出來...
閱讀 1165·2021-09-22 15:43
閱讀 2361·2021-09-22 15:32
閱讀 4533·2021-09-22 15:11
閱讀 2236·2019-08-30 15:55
閱讀 2603·2019-08-30 15:54
閱讀 997·2019-08-30 15:44
閱讀 1110·2019-08-29 13:26
閱讀 806·2019-08-29 12:54