Django cache中比较常用的有 cache_page 这么个 decorators, 下面就根据请求流程,结合源码来说说它是怎么工作的?
版本是django1.8,不同版本可能函数等会变化,逻辑应该类似。
cache_page的功能
从逻辑上来说 cache_page 的功能非常简单,无非就是针对被装饰views对应的request进行缓存。当请求来了就检查是否有缓存
,如果没有命中
就正常获取 response,然后缓存给定的时间
,如果命中
缓存就从缓存中获取 缓存的response
对象并返回给客户端。缓存的方式key,value。
逻辑很简单,那么Django怎么实现,带着一些问题来研究。
1. Django是怎样对应请求
和缓存
的?
2. 缓存的key是怎样的格式?
3. 当views关联的数据变化了,而缓存又没有过期,怎么手动过期缓存
呢?django并没有这个api,见 Django中过期@cache_page中缓存的views数据
代码逻辑
涉及到的几个代码文件,文件都是相对django源码目录
1. views/decorators/cache.py
cache_page所在的文件
2. utils/decorators.py
装饰器和middleware的调用封装,通用的库,这里不用看。
3. middleware/cache.py
CacheMiddleware和它的父类 主要的逻辑
在这里了
例如 http://xxx.com/hello
在views中对应下面的方法
@cache_page(60*3, key_prefix='lzz')
def hello(request):
....
return HttpResponse()
上面的代码表示缓存 response 3分钟。缓存是一个动词,也是一个名次,也是个服务,有点绕。
请求进来
当一个请求进来之后,cache_page 检查 cache 的逻辑在 django.middleware.cache.FetchFromCacheMiddleware
的 process_request 方法
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 = 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.
# 从根据cache_key从缓存中读取缓存值
response = self.cache.get(cache_key, None)
# if it wasn't found and we are looking for a HEAD, try looking just for that
# 如果没有获取到缓存,再尝试获取HEAD方法的缓存
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, None)
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
代码中的注释已经很清楚了,总结几点
- 只缓存 HTTP method 为 GET和HEAD的请求
cache_key
是当前请求获取其对应的关键,get_cache_key
是一个核心的方法。获取这个key之后,后续的操作跟平时使用缓存服务类似。- 通过
request._cache_update_cache
这个属性来标记,响应的时候是否更新缓存。像遇到POST请求,还有命中缓存的时候就不用更新缓存内容了。 self.key_prefix
这个值是从cache_page的参数中传递过来的,默认为”
下面说说这个 get_cache_key
的逻辑,中间涉及到的调用.
这个方法的定义 get_cache_key(request, key_prefix=None, method='GET', cache=None)
在django.utils.cache中
def get_cache_key(request, key_prefix=None, method='GET', cache=None):
"""
Returns a cache key based on the request URL and query. It can be used
in the request phase because it pulls the list of headers to take into
account from the global URL registry and uses those to build a cache key
to check against.
If there is no headerlist stored, the page needs to be rebuilt, so this
function returns None.
"""
if key_prefix is None:
key_prefix = settings.CACHE_MIDDLEWARE_KEY_PREFIX
cache_key = _generate_cache_header_key(key_prefix, request)
if cache is None:
cache = caches[settings.CACHE_MIDDLEWARE_ALIAS]
# get header list
headerlist = cache.get(cache_key, None)
if headerlist is not None:
return _generate_cache_key(request, method, headerlist, key_prefix)
else:
return None
1、_generate_cache_header_key
的代码 header key生成的逻辑
2、_generate_cache_key
的代码 response生成的逻辑
3、_i18n_cache_key_suffix
的代码 语言和时区的处理
- 上面代码 cache 变量可以理解为
cache服务
- 首先调用
_generate_cache_header_key
生成cache_key
,它依据什么生成的呢?url, key_prefix,语言, 时区(后面两个需要有settings中配置), 结果类似views.decorators.cache.cache_header..bcd1deb2a62fa916f88d6faca741df45.zh-hans
这么个东西。这个key的有什么作用呢?从代码中看出来是为了获取 headerlist(17行),这个key在缓存服务中对应的是一些header信息,例如 HTTP_COOKIE,对应 using-vary-headers这部分API,如果没有设置 vary_on_headers, 结果就为空。 - 接着调用
_generate_cache_key
返回上面middleware中的 cache_key,这个key的产生需要那些东西呢? method,headerlist,key_prefix,语言,时区 最后的结果像这样views.decorators.cache.cache_page..GET.bcd1deb2a62fa916f88d6faca741df45.66f40c1b9365da184c0dd0ba7087a7f0.zh-hans
,这个key对应的是真正的response
可以看到一个请求会在缓存服务中缓存两个key,一个是 header key 对应 headerlist(配合vary_on_headers
),另外一个key对应response的内容。
响应返回
当请求没有命中缓存的时候,views就会处理,然后返回响应,这个时候就会 更新缓存
。
重要逻辑在 django.middleware.cache.UpdateCacheMiddleware
的 process_respons 方法中。
- 检查是否要更新缓存,就是检查
request._cache_update_cache
这个属性 - 对于返回 streaming 和 非200 的响应不会缓存
- 对于有cookie并且header已经设置了
Vary:Cookie
的不缓存 (例如在views中设置了) - 如果header
Cache-Control
设置为0,也不进行缓存 - 设置response的header,缓存header key,缓存response内容
大概就这些,django的缓存一方面利用浏览器cache,一方面使用自己的缓存框架,一起完成整个cache过程。