设定缓存

缓存系统需要一些少量的设定工作。 也就是说，你必须告诉它缓存的数据应该放在哪里，在数据库中，在文件系统，或直接在内存中。 这是一个重要的决定，影响您的高速缓存的性能，是的，有些类型的缓存比其它类型快。

缓存设置在settings文件的 CACHE_BACKEND中。 这里是一个CACHE_BACKEND所有可用值的解释。

CACHE_BACKEND = 'memcached://127.0.0.1:11211/'

CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11211/'

CACHE_BACKEND = 'memcached://172.19.26.240:11211;172.19.26.242:11212;172.19.26.244:11213/'

python manage.py createcachetable [cache_table_name]

CACHE_BACKEND = 'db://my_cache_table'

CACHE_BACKEND = 'file:///var/tmp/django_cache'

file://c:/foo/bar

CACHE_BACKEND = 'locmem:///'

CACHE_BACKEND = 'dummy:///'

CACHE_BACKEND = 'path.to.backend://'

CACHE_BACKEND = "memcached://127.0.0.1:11211/?timeout=60"

CACHE_BACKEND = "locmem:///?timeout=30&max_entries=400"

站点级 Cache

一旦高速缓存设置，最简单的方法是使用缓存缓存整个网站。 您 需要添加’django.middleware.cache.UpdateCacheMiddleware’和 ‘django.middleware.cache.FetchFromCacheMiddleware’到您的MIDDLEWARE_CLASSES设置中，在这个例子中是：

MIDDLEWARE_CLASSES = (
    'django.middleware.cache.UpdateCacheMiddleware',
    'django.middleware.common.CommonMiddleware',
    'django.middleware.cache.FetchFromCacheMiddleware',
)

注意：

不，这里并没有排版错误： 修改的中间件，必须放在列表的开始位置，而fectch中间件，必须放在最后。 细节有点费解，如果您想了解完整内幕请参看下面的MIDDLEWARE_CLASSES顺序。

然后，在你的Django settings文件里加入下面所需的设置：

• CACHE_MIDDLEWARE_SECONDS :每个页面应该被缓存的秒数。

• CACHE_MIDDLEWARE_KEY_PREFIX ：如果缓存被多个使用相同Django安装的网站所共享，那么把这个值设成当前网站名，或其他能代表这个Django实例的唯一字符串，以避免key发生冲突。 如果你不在意的话可以设成空字符串。

缓存中间件缓存每个没有GET或者POST参数的页面。 或者，如果CACHE_MIDDLEWARE_ANONYMOUS_ONLY设置为True，只有匿名请求（即不是由登录的用户）将被缓存。 如果想取消用户相关页面（user-specific pages）的缓存，例如Djangos 的管理界面，这是一种既简单又有效的方法。 CACHE_MIDDLEWARE_ANONYMOUS_ONLY，你应该确保你已经启动AuthenticationMiddleware。

此外，缓存中间件为每个HttpResponse自动设置了几个头部信息：

• 当一个新(没缓存的)版本的页面被请求时设置Last-Modified头部为当前日期/时间。

• 设置Expires头部为当前日期/时间加上定义的CACHE_MIDDLEWARE_SECONDS。

• 设置Cache-Control头部来给页面一个最长的有效期，值来自于CACHE_MIDDLEWARE_SECONDS设置。

参阅更多的中间件第17章。

如果视图设置自己的缓存到期时间（即 它有一个最大年龄在头部信息的Cache-Control中），那么页面将缓存直到过期，而不是CACHE_MIDDLEWARE_SECONDS。使用django.views.decorators.cache装饰器，您可以轻松地设置视图的到期时间（使用cache_control装饰器）或禁用缓存视图（使用never_cache装饰器）。 请参阅下面的”使用其他头部信息“小节以了解装饰器的更多信息。

视图级缓存

更加颗粒级的缓存框架使用方法是对单个视图的输出进行缓存。 django.views.decorators.cache定义了一个自动缓存视图响应的cache_page装饰器。 他是很容易使用的:

from django.views.decorators.cache import cache_page

def my_view(request):
    # ...

my_view = cache_page(my_view, 60 * 15)

也可以使用Python2.4的装饰器语法：

@cache_page(60 * 15)
def my_view(request):
    # ...

cache_page 只接受一个参数： 以秒计的缓存超时时间。 在前例中， “my_view()” 视图的结果将被缓存 15 分钟。 （注意： 为了提高可读性，该参数被书写为 60 * 15 。 60 * 15 将被计算为 900 ，也就是说15 分钟乘以每分钟 60 秒。）

和站点缓存一样，视图缓存与 URL 无关。 如果多个 URL 指向同一视图，每个视图将会分别缓存。 继续 my_view 范例，如果 URLconf 如下所示：

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', my_view),
)

那么正如你所期待的那样，发送到 /foo/1/ 和 /foo/23/ 的请求将会分别缓存。 但一旦发出了特定的请求（如： /foo/23/ ），之后再度发出的指向该 URL 的请求将使用缓存。

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', my_view),
)

from django.views.decorators.cache import cache_page

urlpatterns = ('',
    (r'^foo/(\d{1,2})/$', cache_page(my_view, 60 * 15)),
)

模板碎片缓存

你同样可以使用cache标签来缓存模板片段。 在模板的顶端附近加入{% load cache %}以通知模板存取缓存标签。

模板标签{% cache %}在给定的时间内缓存了块的内容。 它至少需要两个参数: 缓存超时时间（以秒计）和指定缓存片段的名称。 示例：

{% load cache %}
{% cache 500 sidebar %}
    .. sidebar ..
{% endcache %}

有时你可能想缓存基于片段的动态内容的多份拷贝。 比如，你想为上一个例子的每个用户分别缓存侧边栏。 这样只需要给{% cache %}传递额外的参数以标识缓存片段。

{% load cache %}
{% cache 500 sidebar request.user.username %}
    .. sidebar for logged in user ..
{% endcache %}

传递不止一个参数也是可行的。 简单地把参数传给{% cache %}。

缓存超时时间可以作为模板变量，只要它可以解析为整数值。 例如，如果模板变量my_timeout值为600，那么以下两个例子是等价的。

{% cache 600 sidebar %} ... {% endcache %}
{% cache my_timeout sidebar %} ... {% endcache %}

这个特性在避免模板重复方面非常有用。 可以把超时时间保存在变量里，然后在别的地方复用。

低层次缓存API

有些时候，对整个经解析的页面进行缓存并不会给你带来太多好处，事实上可能会过犹不及。

比如说，也许你的站点所包含的一个视图依赖几个费时的查询，每隔一段时间结果就会发生变化。 在这种情况下，使用站点级缓存或者视图级缓存策略所提供的整页缓存并不是最理想的，因为你可能不会想对整个结果进行缓存（因为一些数据经常变化），但你仍然会想对很少变化的部分进行缓存。

针对这样的情况，Django提供了简单低级的缓存API。 你可以通过这个API，以任何你需要的粒度来缓存对象。 你可以对所有能够安全进行 pickle 处理的 Python 对象进行缓存： 字符串、字典和模型对象列表等等。 （查阅 Python 文档可以了解到更多关于 pickling 的信息。）

缓存模块django.core.cache拥有一个自动依据CACHE_BACKEND设置创建的django.core.cache对象。

>>> from django.core.cache import cache

基本的接口是 set(key, value, timeout_seconds) 和 get(key) :

>>> cache.set('my_key', 'hello, world!', 30)
>>> cache.get('my_key')
'hello, world!'

timeout_seconds 参数是可选的, 并且默认为前面讲过的 CACHE_BACKEND 设置中的 timeout 参数.

如果缓存中不存在该对象，那么cache.get()会返回None。

# Wait 30 seconds for 'my_key' to expire...

>>> cache.get('my_key')
None

我们不建议在缓存中保存 None 常量，因为你将无法区分你保存的 None 变量及由返回值 None 所标识的缓存未命中。

cache.get() 接受一个 缺省 参数。 它指定了当缓存中不存在该对象时所返回的值：

>>> cache.get('my_key', 'has expired')
'has expired'

使用add()方法来新增一个原来没有的键值。 它接受的参数和set()一样，但是并不去尝试更新已经存在的键值。

>>> cache.set('add_key', 'Initial value')
>>> cache.add('add_key', 'New value')
>>> cache.get('add_key')
'Initial value'

如果想确定add()是否成功添加了缓存值，你应该测试返回值。 成功返回True，失败返回False。

还有个get_many()接口。 get_many() 所返回的字典包括了你所请求的存在于缓存中且未超时的所有键值。

>>> cache.set('a', 1)
>>> cache.set('b', 2)
>>> cache.set('c', 3)
>>> cache.get_many(['a', 'b', 'c'])
{'a': 1, 'b': 2, 'c': 3}

最后,你可以用 cache.delete() 显式地删除关键字。

>>> cache.delete('a')

也可以使用incr()或者decr()来增加或者减少已经存在的键值。 默认情况下，增加或减少的值是1。可以用参数来制定其他值。 如果尝试增减不存在的键值会抛出ValueError。

>>> cache.set('num', 1)
>>> cache.incr('num')
2
>>> cache.incr('num', 10)
12
>>> cache.decr('num')
11
>>> cache.decr('num', 5)
6

注意

incr()/decr()方法不是原子操作。 在支持原子增减的缓存后端上（最著名的是memcached），增减操作才是原子的。 然而，如果后端并不原生支持增减操作，也可以通过取值/更新两步操作来实现。

上游缓存

目前为止，本章的焦点一直是对你 自己的 数据进行缓存。 但还有一种与 Web 开发相关的缓存： 上游缓存。 有一些系统甚至在请求到达站点之前就为用户进行页面缓存。

下面是上游缓存的几个例子：

• 你的 ISP (互联网服务商)可能会对特定的页面进行缓存，因此如果你向 http://example.com/ 请求一个页面，你的 ISP 可能无需直接访问 example.com 就能将页面发送给你。 而 example.com 的维护者们却无从得知这种缓存，ISP 位于 example.com 和你的网页浏览器之间，透明地处理所有的缓存。

• 你的 Django 网站可能位于某个 代理缓存 之后，例如 Squid 网页代理缓存 (http://www.squid-cache.org/)，该缓存为提高性能而对页面进行缓存。 在此情况下 ，每个请求将首先由代理服务器进行处理，然后仅在需要的情况下才被传递至你的应用程序。

• 你的网页浏览器也对页面进行缓存。 如果某网页送出了相应的头部，你的浏览器将在为对该网页的后续的访问请求使用本地缓存的拷贝，甚至不会再次联系该网页查看是否发生了变化。

上游缓存将会产生非常明显的效率提升，但也存在一定风险。 许多网页的内容依据身份验证以及许多其他变量的情况发生变化，缓存系统仅盲目地根据 URL 保存页面，可能会向这些页面的后续访问者暴露不正确或者敏感的数据。

举个例子，假定你在使用网页电邮系统，显然收件箱页面的内容取决于登录的是哪个用户。 如果 ISP 盲目地缓存了该站点，那么第一个用户通过该 ISP 登录之后，他（或她）的用户收件箱页面将会缓存给后续的访问者。 这一点也不好玩。

幸运的是， HTTP 提供了解决该问题的方案。 已有一些 HTTP 头标用于指引上游缓存根据指定变量来区分缓存内容，并通知缓存机制不对特定页面进行缓存。 我们将在本节后续部分将对这些头标进行阐述。

使用 Vary头部

Vary 头部定义了缓存机制在构建其缓存键值时应当将哪个请求头标考虑在内。 例如，如果网页的内容取决于用户的语言偏好，该页面被称为根据语言而不同。

缺省情况下，Django 的缓存系统使用所请求的路径（比如："/stories/2005/jun/23/bank_robbed/" ）来创建其缓存键。这意味着每次请求都会使用同样的缓存版本，不考虑才客户端cookie和语言配置的不同。 除非你使用Vary头部通知缓存机制页面输出要依据请求头里的cookie，语言等的设置而不同。

要在 Django 完成这项工作，可使用便利的 vary_on_headers 视图装饰器，如下所示：

from django.views.decorators.vary import vary_on_headers

# Python 2.3 syntax.
def my_view(request):
    # ...
my_view = vary_on_headers(my_view, 'User-Agent')

# Python 2.4+ decorator syntax.
@vary_on_headers('User-Agent')
def my_view(request):
    # ...

在这种情况下，缓存机制（如 Django 自己的缓存中间件）将会为每一个单独的用户浏览器缓存一个独立的页面版本。

使用 vary_on_headers 装饰器而不是手动设置 Vary 头部（使用像 response['Vary'] = 'user-agent' 之类的代码）的好处是修饰器在（可能已经存在的） Vary 之上进行 添加 ，而不是从零开始设置，且可能覆盖该处已经存在的设置。

你可以向 vary_on_headers() 传入多个头标：

@vary_on_headers('User-Agent', 'Cookie')
def my_view(request):
    # ...

该段代码通知上游缓存对 两者 都进行不同操作，也就是说 user-agent 和 cookie 的每种组合都应获取自己的缓存值。 举例来说，使用 Mozilla 作为 user-agent 而 foo=bar 作为 cookie 值的请求应该和使用 Mozilla 作为 user-agent 而 foo=ham 的请求应该被视为不同请求。

由于根据 cookie 而区分对待是很常见的情况，因此有 vary_on_cookie 装饰器。 以下两个视图是等效的：

@vary_on_cookie
def my_view(request):
    # ...

@vary_on_headers('Cookie')
def my_view(request):
    # ...

传入 vary_on_headers 头标是大小写不敏感的； "User-Agent" 与 "user-agent" 完全相同。

你也可以直接使用帮助函数：django.utils.cache.patch_vary_headers。 该函数设置或增加 Vary header ，例如：

from django.utils.cache import patch_vary_headers

def my_view(request):
    # ...
    response = render_to_response('template_name', context)
    patch_vary_headers(response, ['Cookie'])
    return response

patch_vary_headers 以一个 HttpResponse 实例为第一个参数，以一个大小写不敏感的头标名称列表或元组为第二个参数。

控制缓存： 使用其它头部

关于缓存剩下的问题是数据的隐私性以及在级联缓存中数据应该在何处储存的问题。

通常用户将会面对两种缓存： 他或她自己的浏览器缓存（私有缓存）以及他或她的提供者缓存（公共缓存）。 公共缓存由多个用户使用，而受其他某人的控制。 这就产生了你不想遇到的敏感数据的问题，比如说你的银行账号被存储在公众缓存中。 因此，Web 应用程序需要以某种方式告诉缓存那些数据是私有的，哪些是公共的。

解决方案是标示出某个页面缓存应当是私有的。 要在 Django 中完成此项工作，可使用 cache_control 视图修饰器： 例如：

from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request):
    # ...

该修饰器负责在后台发送相应的 HTTP 头部。

还有一些其他方法可以控制缓存参数。 例如, HTTP 允许应用程序执行如下操作:

• 定义页面可以被缓存的最大时间。

• 指定某个缓存是否总是检查较新版本，仅当无更新时才传递所缓存内容。 （一些缓存即便在服务器页面发生变化的情况下仍然会传送所缓存的内容，只因为缓存拷贝没有过期。）

在 Django 中，可使用 cache_control 视图修饰器指定这些缓存参数。 在本例中， cache_control 告诉缓存对每次访问都重新验证缓存并在最长 3600 秒内保存所缓存版本：

from django.views.decorators.cache import cache_control

@cache_control(must_revalidate=True, max_age=3600)
def my_view(request):
    # ...

在 cache_control() 中，任何合法的Cache-Control HTTP 指令都是有效的。下面是完整列表：

• public=True

• private=True

• no_cache=True

• no_transform=True

• must_revalidate=True

• proxy_revalidate=True

• max_age=num_seconds

• s_maxage=num_seconds

缓存中间件已经使用 CACHE_MIDDLEWARE_SETTINGS 设置设定了缓存头部 max-age 。 如果你在cache_control修饰器中使用了自定义的max_age，该修饰器将会取得优先权，该头部的值将被正确地被合并。

如果你想用头部完全禁掉缓存，django.views.decorators.cache.never_cache装饰器可以添加确保响应不被缓存的头部信息。 例如：

from django.views.decorators.cache import never_cache

@never_cache
def myview(request):
    # ...

其他优化

Django 带有一些其它中间件可帮助您优化应用程序的性能:

• django.middleware.http.ConditionalGetMiddleware 为现代浏览器增加了有条件的，基于 ETag 和 Last-Modified 头标的GET响应的相关支持。

• django.middleware.gzip.GZipMiddleware 为所有现代浏览器压缩响应内容，以节省带宽和传送时间。

MIDDLEWARE_CLASSES 的顺序

如果使用缓存中间件，注意在MIDDLEWARE_CLASSES设置中正确配置。 因为缓存中间件需要知道哪些头部信息由哪些缓存区来区分。 中间件总是尽可能得想Vary响应头中添加信息。

UpdateCacheMiddleware在相应阶段运行。因为中间件是以相反顺序运行的，所有列表顶部的中间件反而last在相应阶段的最后运行。 所有，你需要确保UpdateCacheMiddleware排在任何可能往Vary头部添加信息的中间件之前。 下面的中间件模块就是这样的：

• 添加 Cookie 的 SessionMiddleware

• 添加 Accept-Encoding 的 GZipMiddleware

• 添加Accept-Language的LocaleMiddleware

另一方面，FetchFromCacheMiddleware在请求阶段运行，这时中间件循序执行，所以列表顶端的项目会首先执行。 FetchFromCacheMiddleware也需要在会修改Vary头部的中间件之后运行，所以FetchFromCacheMiddleware必须放在它们后面。

下一章

Django捆绑了一系列可选的方便特性。 我们已经介绍了一些： admin站点（第六章）和session/user框架（第十四章）。 下一章中，我们将讲述Django中其他的子框架。