Django 缓存模块 page_cache 源码阅读

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过程。