前言
如果使用缓存中间件（在settings里面加上设置）那么中间件将会基于URL对Django的页面进行缓存。启用缓存中间件的规范方法是设置“UpdateCacheMiddleware”作为你的第一件中间件，而且“FetchFromCacheMiddleware”作为最后的中间件。
就像下面一样：
MIDDLEWARE = [
'django.middleware.cache.UpdateCacheMiddleware',
...
'django.middleware.cache.FetchFromCacheMiddleware'
]
这是违反直觉的，而违反直觉的原因在于：“UpdateCacheMiddleware” 需要运行最后的响应阶段，处理中间件自下而上; “FetchFromCacheMiddleware” 需要在请求阶段最后运行，自上而下处理中间件。
在缓存中间件中，还有一类简单的中间件：“CacheMiddleware”可以用于一些简单的站点。但是，如果有任何其他中间件需要影响缓存密钥，那么您就可以需要 “UpdateCacheMiddleware” 和 “FetchFromCacheMiddleware”两个中间件，而不是仅用CacheMiddleware一个中间件。这种情况在有“LocaleMiddleware”出现的情况下是尤为经常。
缓存中间件的工作任务：
- 只有状态码为200的GET或HEAD请求被高速缓存。
- 每个页面存储的秒数由响应（Response）的“缓存控制（Cache-Control）”头部中的“max-age”部分设置的。如果“max-age”部分没有的话，那么此项设置落到CACHE_MIDDLEWARE_SECONDS变量上。
- 这个中间件期望HEAD请求与相应的GET请求完全相同的响应头。【见工作任务1。
- 发生异常故障时时，从process_request那返回原始请求的浅层拷贝。【告诉了我们这个东西是直接短路process_request， 直接生成HTTPResponse对象，然后这个HTTPResponse对象就是从原始的返回请求那边传过来的浅拷贝】
- 页面将根据请求头中的内容缓存响应的“Vary”title。
- 该中间件还在响应对象上设置ETag，Last-Modified，Expires和Cache-Control头部。
缓存的代码解析：
中间件
- UpdateCacheMiddleware
- FetchFromCacheMiddleware
- CacheMiddleware(继承上面两个)
UpdateCacheMiddleware
def process_response(self, request, response):
"""Sets the cache, if needed."""
if not self._should_update_cache(request, response):
# We don't need to update the cache, just return.
return response
if response.streaming or response.status_code != 200:
return response
# Don't cache responses that set a user-specific (and maybe security
# sensitive) cookie in response to a cookie-less request.
if not request.COOKIES and response.cookies and has_vary_header(response, 'Cookie'):
return response
# Try to get the timeout from the "max-age" section of the "Cache-
# Control" header before reverting to using the default cache_timeout
# length.
timeout = get_max_age(response)
if timeout is None:
timeout = self.cache_timeout
elif timeout == 0:
# max-age was set to 0, don't bother caching.
return response
patch_response_headers(response, timeout)
if timeout:
cache_key = learn_cache_key(request, response, timeout, self.key_prefix, cache=self.cache)
if hasattr(response, 'render') and callable(response.render):
response.add_post_render_callback(
lambda r: self.cache.set(cache_key, r, timeout)
)
else:
self.cache.set(cache_key, response, timeout)
return response
Hook点：process_response
内容：
- 检查是否需要更新缓存：
- 方法，过期，cookie等
- 如果需要更新缓存，则
- 先获取cookie_key。
- 如果要渲染：把httpresponse对象中的缓存加入渲染好的模板。
- 如果不要渲染：就直接吧HttpResponse对象加入缓存中。
- 返回HttpRespone对象。
FetchFromCacheMiddleware
def process_request(self, request):
"""
Checks whether the page is already cached and returns the cached
version if available.
"""
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 = 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 = 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:
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
源码解析：
- Hook点在process_request阶段。
- 请求刚处理进来，针对工作任务中的2要求验证HEAD和GET方法。
- 通过请求，找到cache_key从而能通过cache_key找到cache的内容。
- 按照【缓存中间件的工作任务】中的要求2，进行response的构建
- 这里直接构建一个response属于一个返回短路。
