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