这篇文章给大家分享的是有关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
这一节将回答两个问题:
为什么在redis中,一个页面会保存两个key:cache_key以及cache_header?
页面缓存是如何被唯一标识的?当请求头不同的时候(比如换了一个用户请求相同的页面)会使用同一个缓存吗?
我们先从保存缓存视图过程中的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是怎样生成的”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。