關(guān)于緩存剩下的問題是數(shù)據(jù)的隱私性以及在級(jí)聯(lián)緩存中數(shù)據(jù)應(yīng)該在何處儲(chǔ)存的問題。

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

解決方案是標(biāo)示出某個(gè)頁面緩存應(yīng)當(dāng)是私有的。 要在 Django 中完成此項(xiàng)工作，可使用 cache_control 視圖修飾器： 例如：

from django.views.decorators.cache import cache_control

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

該修飾器負(fù)責(zé)在后臺(tái)發(fā)送相應(yīng)的 HTTP 頭部。

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

•     定義頁面可以被緩存的最大時(shí)間。
•     指定某個(gè)緩存是否總是檢查較新版本，僅當(dāng)無更新時(shí)才傳遞所緩存內(nèi)容。 （一些緩存即便在服務(wù)器頁面發(fā)生變化的情況下仍然會(huì)傳送所緩存的內(nèi)容，只因?yàn)榫彺婵截悰]有過期。）

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

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

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

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

from django.views.decorators.cache import never_cache

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

其他優(yōu)化

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

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

MIDDLEWARE_CLASSES 的順序

如果使用緩存中間件，注意在MIDDLEWARE_CLASSES設(shè)置中正確配置。 因?yàn)榫彺嬷虚g件需要知道哪些頭部信息由哪些緩存區(qū)來區(qū)分。 中間件總是盡可能得想Vary響應(yīng)頭中添加信息。

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

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

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

最新評(píng)論