這篇文章給大家分享的是有關Django頁面緩存的cache_key是怎樣生成的的內容。小編覺得挺實用的，因此分享給大家做個參考，一起跟隨小編過來看看吧。

創新互聯專注于江城網站建設服務及定制，我們擁有豐富的企業做網站經驗。 熱誠為您提供江城營銷型網站建設，江城網站制作、江城網頁設計、江城網站官網定制、微信小程序開發服務，打造江城網絡公司原創品牌,更為您提供江城網站排名全網營銷落地服務。

頁面緩存

e.g.

@cache_page(time_out, key_prefix=key_prefix)
def my_view():
 ...

默認情況下，將使用配置中的default cache

cache_page 裝飾器是由緩存中間件 CacheMiddleware 轉換而來的

CacheMiddleware 繼承了 UpdateCacheMiddleware 和 FetchFromCacheMiddleware

UpdateCacheMiddleware 繼承自 MiddlewareMixin ，只重寫了 process_response 方法，用于在處理完視圖之后將視圖緩存起來

class UpdateCacheMiddleware(MiddlewareMixin):
 def process_response(self, request, response):
  """Sets the cache, if needed."""
  ...
  if timeout and response.status_code == 200:
   # 根據請求和響應參數、設定的key_prefix生成頁面緩存的key
   cache_key = learn_cache_key(request, response, timeout, self.key_prefix, cache=self.cache)
   self.cache.set(cache_key, response, timeout)
  return response

FetchFromCacheMiddleware 繼承自 MiddlewareMixin ，只重寫了 process_request 方法，用于獲取當前視圖的緩存

# django/middleware/cache.py
class FetchFromCacheMiddleware(MiddlewareMixin):
 def process_request(self, request):
  """
  Checks whether the page is already cached and returns the cached
  version if available.
  """
  # 只對方法為 GET 或 HEAD 的請求獲取緩存
  if request.method not in ('GET', 'HEAD'):
   request._cache_update_cache = False
   return None # Don't bother checking the cache.

  # try and get the cached GET response
  # 這里會根據請求的信息、緩存鍵前綴生成一個cache_key。默認情況下，訪問同一個接口其cache_key應該相同
  cache_key = get_cache_key(request, self.key_prefix, 'GET', cache=self.cache)
  if cache_key is None:
   request._cache_update_cache = True
   return None # No cache information available, need to rebuild.
  # 如果獲取到response，則直接返回緩存的response，那么實際的視圖就不會被執行
  response = self.cache.get(cache_key)
  # if it wasn't found and we are looking for a HEAD, try looking just for that
  if response is None and request.method == 'HEAD':
   cache_key = get_cache_key(request, self.key_prefix, 'HEAD', cache=self.cache)
   response = self.cache.get(cache_key)

  if response is None:
   # 如果沒有獲取到緩存，將返回None，則會執行到實際的視圖，并且重建緩存
   request._cache_update_cache = True
   return None # No cache information available, need to rebuild.

  # hit, return cached response
  request._cache_update_cache = False
  return response

頁面緩存的cache_key

這一節將回答兩個問題：

1. 為什么在redis中，一個頁面會保存兩個key：cache_key以及cache_header？

2. 頁面緩存是如何被標識的？當請求頭不同的時候（比如換了一個用戶請求相同的頁面）會使用同一個緩存嗎？

我們先從保存緩存視圖過程中的learn_cache_key開始

# django/utils/cache.py
def learn_cache_key(request, response, cache_timeout=None, key_prefix=None, cache=None):
 # 見下文，這個cache_key由 request的完整url 以及 key_prefix 確定
 cache_key = _generate_cache_header_key(key_prefix, request)
 if cache is None:
  # cache 是一個緩存實例
  cache = caches[settings.CACHE_MIDDLEWARE_ALIAS]
 # Vary 是一個HTTP響應頭字段。其內容是一個或多個http頭部名稱
 # 比如 `Vary: User-Agent` 表示此響應根據請求頭 `User-Agent` 的值有所不同
 # 只有當下一個請求的 `User-Agent` 值與當前請求相同時，才會使用當前響應的緩存
 if response.has_header('Vary'):
  headerlist = []
  for header in cc_delim_re.split(response['Vary']):
   # 將 Vary 中出現的 http頭部名稱 加到 headerlist 中去
   header = header.upper().replace('-', '_')
   headerlist.append('HTTP_' + header)
  headerlist.sort()
  # 當前 cache_key 實際上是 cache_header_key，它存的是響應頭中Vary字段的值
  cache.set(cache_key, headerlist, cache_timeout)
  # 這里返回的才是頁面內容對應的 cache_key，它由 
  # 出現在Vary字段中的request請求頭字段的值(有序拼在一起)、request的完整url、request的method、key_prefix 確定
  return _generate_cache_key(request, request.method, headerlist, key_prefix)
 else:
  # if there is no Vary header, we still need a cache key
  # for the request.build_absolute_uri()
  cache.set(cache_key, [], cache_timeout)
  return _generate_cache_key(request, request.method, [], key_prefix)

def _generate_cache_header_key(key_prefix, request):
 """Returns a cache key for the header cache."""
 # request.build_absolute_uri()返回的是完整的請求URL。如 http://127.0.0.1:8000/api/leaflet/filterList?a=1
 # 因此，請求同一個接口，但是接口參數不同，會生成兩個cache_key
 url = hashlib.md5(force_bytes(iri_to_uri(request.build_absolute_uri())))
 cache_key = 'views.decorators.cache.cache_header.%s.%s' % (
  key_prefix, url.hexdigest())
 return _i18n_cache_key_suffix(request, cache_key)

def _generate_cache_key(request, method, headerlist, key_prefix):
 """Returns a cache key from the headers given in the header list."""
 ctx = hashlib.md5()
 # headerlist是響應頭中Vary字段的值
 for header in headerlist:
  # 出現在Vary字段中的request請求頭字段的值
  value = request.META.get(header)
  if value is not None:
   ctx.update(force_bytes(value))
 url = hashlib.md5(force_bytes(iri_to_uri(request.build_absolute_uri())))
 cache_key = 'views.decorators.cache.cache_page.%s.%s.%s.%s' % (
  key_prefix, method, url.hexdigest(), ctx.hexdigest())
 return _i18n_cache_key_suffix(request, cache_key)
 再看獲取緩存的get_cache_key方法

def get_cache_key(request, key_prefix=None, method='GET', cache=None):
 # 由 request的完整url 以及 key_prefix 生成 cache_header_key
 cache_key = _generate_cache_header_key(key_prefix, request)
 # headerlist是之前緩存的 與當前請求具有相同cache_header_key 的請求的響應的響應頭中Vary字段的值
 headerlist = cache.get(cache_key)
 # 即使響應頭沒有Vary字段，還是會針對當前 cache_header_key 存一個空數組
 # 因此如果headerlist為None，表示當前請求沒有緩存
 if headerlist is not None:
  # 根據 出現在Vary字段中的request請求頭字段的值(有序拼在一起)、request的完整url、request的method、key_prefix 生成 cache_key
  return _generate_cache_key(request, method, headerlist, key_prefix)
 else:
  return None

綜上所述：

• cache_header中存的是響應頭Vary字段的值，cache_key存的是緩存視圖

• cache_key由 出現在Vary字段中的request請求頭字段的值(有序拼在一起)、request的完整url、request的method、key_prefix 確定

• 當請求頭不同的時候，有可能會使用同一個緩存，這取決于不同的請求頭字段名是否出現在響應頭Vary字段中。比如，如果響應頭中有 Vary: User-Agent ，那么 User-Agent 不同的兩個請求必然生成不同的 cache_key，因此就不會使用同一個緩存。但如果只是在請求頭加一個 cache-control: no-cache （瀏覽器提供的Disable cache功能），訪問同樣的url，那還是會命中之前的緩存的

感謝各位的閱讀！關于“Django頁面緩存的cache_key是怎樣生成的”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，讓大家可以學到更多知識，如果覺得文章不錯，可以把它分享出去讓更多的人看到吧！

本文名稱：Django頁面緩存的cache_key是怎樣生成的-創新互聯
文章分享：http://m.newbst.com/article34/dchppe.html

成都網站建設公司_創新互聯，為您提供建站公司、網站營銷、網站收錄、企業建站、App開發、網站改版

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯