一般與頁面有關(guān)的系統(tǒng)都會(huì)有大量的靜態(tài)文件，包括js、css以及圖標(biāo)圖片等，這些文件一般是項(xiàng)目的相對路徑，在加載的時(shí)候會(huì)從本地讀取再轉(zhuǎn)發(fā)出去。由于這類文件一般比較大，導(dǎo)致接口響應(yīng)變長，但是這些文件一般很少改動(dòng)，所以非常適合通過Nginx或者云服務(wù)來緩存。一般云服務(wù)與cdn無縫集成，能夠更快下發(fā)到客戶端。我們后臺系統(tǒng)很多使用的是基于python的Django框架，該怎么來實(shí)現(xiàn)靜態(tài)文件緩存呢？

這個(gè)過程簡單的讓人驚訝，但是開始一直搞不清楚關(guān)系，前前后后耽誤了不少時(shí)間。

1.collectstatic命令

首先 Django有一個(gè)collectstatic的命令，該腳本的功能是將本地的靜態(tài)文件以及需要的依賴，例如Django和python自己需要的靜態(tài)文件等打包到一個(gè)統(tǒng)一的目錄下。這有點(diǎn)類似于maven發(fā)布前的打包功能。

這個(gè)腳本一般在上線的時(shí)候會(huì)執(zhí)行。例如我們的啟動(dòng)腳本里這么寫的：

sh collectstatic.sh

然后在djang的配置文件里加這么一行：

static-map = /static=./static_files

我們將本地的靜態(tài)文件打包發(fā)送到云服務(wù)就是用collectstatic來實(shí)現(xiàn)的。

2.如何發(fā)布到云服務(wù)

方法非常簡單，代碼也非常少，但是貌似很多地方都沒說清楚為什么，害的我搞了好久，白了很多垃圾代碼。

首先你要新建一個(gè)繼承了Storage的類，例如這樣子:

@deconstructible
class CosStorage(Storage):

上面的注解也必須要有的。

然后在很多材料里會(huì)將，要在這里類里實(shí)現(xiàn)多個(gè)方法，有的是以_開頭，有的就是普通的類，我理解_開頭的主要是collectstatic執(zhí)行的方法，而不帶的是程序執(zhí)行的時(shí)候調(diào)用的。前者類似java中的各類service，程序啟動(dòng)的時(shí)候就會(huì)執(zhí)行。而后者類似controller下的接口，只有外部調(diào)用的時(shí)候才會(huì)執(zhí)行。

以_開頭的方法最重要的是下面這三個(gè):

def __init__(self):
        logging.info('init cos file list...')
        self.get_cos_file_list()
 
    # 看看這里是否需要
    def _open(self, name, mode='r'):
        return File(open(self.path(name), mode))
 
    def _save(self, name, content):       
        cms.util.upload_os_file(FileBizType.TRUMAN_CMS_STATIC_FILES, content, name, name)         
            time.sleep(0.02)

__init__自然是為了初始化而設(shè)置的。根據(jù)需要寫對應(yīng)的代碼，例如調(diào)用云服務(wù)需要的簽名等等

_open()這個(gè)我當(dāng)時(shí)忘了測試一下有沒有用了，按道理這里是打開文件的，反正我是上么這么寫的。

_save(self, name, content)是最關(guān)鍵的代碼。這個(gè)接口是理解Storage的兩大鑰匙。這個(gè)方法的功能是處理當(dāng)前已經(jīng)打開的文件，文件標(biāo)題就是name，content就是將文件內(nèi)容轉(zhuǎn)換成的字節(jié)流，你直接用就行。這個(gè)該怎么理解呢？

name的含義：假如你的靜態(tài)路徑很深，文件很多，類型也很雜。那么Storage首先就幫你處理路徑的問題了，name就是相對路徑+文件名。所以你傳的時(shí)候使用name就將相對目錄一起傳過去了。

content的含義：content就是文件的內(nèi)容，不管是js、css、還是圖標(biāo)圖片，在網(wǎng)絡(luò)傳的時(shí)候都會(huì)先轉(zhuǎn)換成字節(jié)流是不是。這里的content就是當(dāng)前文件的字節(jié)流。所以就使用upload_os_file(content) 就將文件內(nèi)容發(fā)出去了，不需要自己再讀文件 ，轉(zhuǎn)換成字節(jié)流等操作。不過這里的upload_os_file是我自己的業(yè)務(wù)代碼，你可以根據(jù)需要做對應(yīng)的實(shí)現(xiàn)。

另外一個(gè)重要的問題是_save一次只處理一個(gè)文件，所以你寫這個(gè)方法里的代碼的時(shí)候只要考了一個(gè)文件就行了，不用多此一舉寫批量等邏輯。

這里還有一點(diǎn)就是如果不加限制，_save的執(zhí)行速度會(huì)非常快 ，一下就將所有文件全部讀到，并且一個(gè)文件一個(gè)請求全部發(fā)出去，這可能導(dǎo)致服務(wù)端來不及處理而被拒絕等情況。方法也很簡單，_save里加個(gè)等待就行了

time.sleep(0.02)

上面的代碼在服務(wù)啟動(dòng)過程中執(zhí)行到collectstatic時(shí)會(huì)自動(dòng)掃描，自動(dòng)加載，自動(dòng)執(zhí)行，但是你要在自己的配置文件中添加如下信息，否則會(huì)找不到。

STATICFILES_STORAGE = 'cos.cos_storage.CosStorage'

3.訪問時(shí)是如何重定向到cos的

將文件存到云服務(wù)之后，頁面執(zhí)行的時(shí)候怎么訪問呢？

這就涉及到Storage的其他幾個(gè)方法了，主要是：

def listdir(self, path):
        pass
 
    def delete(self, name):
        pass
 
    def size(self, name):
        pass
 
    def url(self, name):
      url = cms.util.get_file_os_download_url(name)
        return url
 
    def exists(self, name):
        pass

  上面看名字我們就能大致知道功能，最重要的是url()方法，這個(gè)是理解Storage的第二把鑰匙。

這里的name就是文件在云服務(wù)中的相對路徑，你需要將拼接一下你的域名等就是文件的地址了。然后返回就行了。

如果靜態(tài)文件都是公開的，這里的url貌似不寫也行，能夠自動(dòng)實(shí)現(xiàn)將域名和文件相對路徑拼接程完整的訪問url。

但是在我們的系統(tǒng)中，靜態(tài)文件是不允許直接訪問，需要帶簽名的。 所以我們這里需要在url里通過自定義的get_file_os_download_url()方法去訪問我們另外一個(gè)服務(wù)。

但是這里有一個(gè)坑，就是python的基礎(chǔ)包中也會(huì)用相對路徑訪問自己的靜態(tài)文件，也就是這么寫"/title.png"等，這種情況無法被url攔截到。因?yàn)槲覀儤I(yè)務(wù)的代碼里是統(tǒng)一加前綴/static/的。

該怎么攔截，至今沒有解決，如果你知道，請和我說，謝謝！

到此這篇關(guān)于Django實(shí)現(xiàn)靜態(tài)文件緩存到云服務(wù)的操作方法的文章就介紹到這了,更多相關(guān)Django靜態(tài)文件緩存內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論