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

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

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

            
from django.views.decorators.cache import cache_control

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


          

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

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

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

在 Django 中，可使用 cache_control 視圖修飾器指定這些緩存參數(shù)。 在本例中， cache_control 告訴緩存對每次訪問都重新驗證緩存并在最長 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，該修飾器將會取得優(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 頭標的GET響應(yīng)的相關(guān)支持。
• ??? django.middleware.gzip.GZipMiddleware 為所有現(xiàn)代瀏覽器壓縮響應(yīng)內(nèi)容，以節(jié)省帶寬和傳送時間。

MIDDLEWARE_CLASSES 的順序

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

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

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

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