淺談Python的Django框架中的緩存控制

更新時間：2015年07月24日 11:06:02 投稿：goldensun

這篇文章主要介紹了Python的Django框架中的緩存控制,包括Vary頭部以外的其他頭部使用等,需要的朋友可以參考下

關于緩存剩下的問題是數(shù)據的隱私性以及在級聯(lián)緩存中數(shù)據應該在何處儲存的問題。

通常用戶將會面對兩種緩存：他或她自己的瀏覽器緩存（私有緩存）以及他或她的提供者緩存（公共緩存）。公共緩存由多個用戶使用，而受其他某人的控制。這就產生了你不想遇到的敏感數(shù)據的問題，比如說你的銀行賬號被存儲在公眾緩存中。因此，Web 應用程序需要以某種方式告訴緩存那些數(shù)據是私有的，哪些是公共的。

解決方案是標示出某個頁面緩存應當是私有的。要在 Django 中完成此項工作，可使用 cache_control 視圖修飾器：例如：

from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request):
  # ...

該修飾器負責在后臺發(fā)送相應的 HTTP 頭部。

還有一些其他方法可以控制緩存參數(shù)。例如, HTTP 允許應用程序執(zhí)行如下操作:

定義頁面可以被緩存的最大時間。
指定某個緩存是否總是檢查較新版本，僅當無更新時才傳遞所緩存內容。（一些緩存即便在服務器頁面發(fā)生變化的情況下仍然會傳送所緩存的內容，只因為緩存拷貝沒有過期。）

在 Django 中，可使用 cache_control 視圖修飾器指定這些緩存參數(shù)。在本例中， cache_control 告訴緩存對每次訪問都重新驗證緩存并在最長 3600 秒內保存所緩存版本：

from django.views.decorators.cache import cache_control

@cache_control(must_revalidate=True, max_age=3600)
def my_view(request):
  # ...

在 cache_control() 中，任何合法的Cache-Control HTTP 指令都是有效的。下面是完整列表：

  public=True

  private=True

  no_cache=True

  no_transform=True

  must_revalidate=True

  proxy_revalidate=True

  max_age=num_seconds

  s_maxage=num_seconds

緩存中間件已經使用 CACHE_MIDDLEWARE_SETTINGS 設置設定了緩存頭部 max-age 。如果你在cache_control修飾器中使用了自定義的max_age，該修飾器將會取得優(yōu)先權，該頭部的值將被正確地被合并。

如果你想用頭部完全禁掉緩存，django.views.decorators.cache.never_cache裝飾器可以添加確保響應不被緩存的頭部信息。例如：

from django.views.decorators.cache import never_cache

@never_cache
def myview(request):
  # ...

其他優(yōu)化

Django 帶有一些其它中間件可幫助您優(yōu)化應用程序的性能:

django.middleware.http.ConditionalGetMiddleware 為現(xiàn)代瀏覽器增加了有條件的，基于 ETag 和 Last-Modified 頭標的GET響應的相關支持。
django.middleware.gzip.GZipMiddleware 為所有現(xiàn)代瀏覽器壓縮響應內容，以節(jié)省帶寬和傳送時間。

MIDDLEWARE_CLASSES 的順序

如果使用緩存中間件，注意在MIDDLEWARE_CLASSES設置中正確配置。因為緩存中間件需要知道哪些頭部信息由哪些緩存區(qū)來區(qū)分。中間件總是盡可能得想Vary響應頭中添加信息。

UpdateCacheMiddleware在相應階段運行。因為中間件是以相反順序運行的，所有列表頂部的中間件反而last在相應階段的最后運行。所有，你需要確保UpdateCacheMiddleware排在任何可能往Vary頭部添加信息的中間件之前。下面的中間件模塊就是這樣的：

添加 Cookie 的 SessionMiddleware
添加 Accept-Encoding 的 GZipMiddleware
添加Accept-Language的LocaleMiddleware

另一方面，F(xiàn)etchFromCacheMiddleware在請求階段運行，這時中間件循序執(zhí)行，所以列表頂端的項目會首先執(zhí)行。 FetchFromCacheMiddleware也需要在會修改Vary頭部的中間件之后運行，所以FetchFromCacheMiddleware必須放在它們后面。

您可能感興趣的文章: