内存缓冲

目�为止Django�得到的最快的最高效的缓存类型是基于内存的缓存框架Memcached，它起�开��为LiveJournal.com处�高负�并��被Danga Interactive(http://www.danga.com)开�，它被Slashdot和Wikipedia等站点采用以�少数�库访问并�大的��了站点性能

Memcached�以在http://danga.com/memcached/�费得到，它作为��进程�行并分�一个指定数�的RAM.它能为你�供在缓存中*如闪电般快速的*添加，获�和删除任�数�，所有的数�直接存储在内存中，所以没有数�库和文件系统使用的过度使用

在安装了Memcached本身之å�Žï¼Œä½ å°†éœ€è¦�安装Memcached Python绑定，它没有直接和Django绑定，这些绑定在一个å�•ç‹¬çš„Python模å�—中，’memcache.py’，å�¯ä»¥åœ¨http://www.djangoproject.com/thirdparty/python-memcached得到

设置 CACHE_BACKEND 为 memcached://ip:port/ �让Django使用Memcached，这里的 ip 是Memcached��进程的IP地�， port 则是Memcached�行所在的端�

在这个例�中，Memcached�行在本地主机 (127.0.0.1)上,端�为11211：

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

Memcached的一个�好的特性是它在多个�务器分享缓存的能力，这�味�你�以在多�机器上�行Memcached进程，程�将会把这组机器当作一个*�独的*缓存，而�需�在��机器上�制缓存值，为了让Django利用此特性，需�在CACHE_BACKEND里包�所有的�务器地�并用分�分隔

这个例�中，缓存在�行在172.19.26.240和172.19.26.242的IP地�和11211端�的Memcached实例间分享:

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

这个例�中，缓存在�行在172.19.26.240(端�11211)，172.19.26.242(端�11212)，172.19.26.244(端�11213)的Memcached实例间分享:

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

最�关于Memcached的是基于内存的缓存有一个�大的缺点，因为缓存数��存储在内存中，则如果�务器死机的�数�会丢失，显然内存�是为�久数�存储准备的，Django没有一个缓存�端是用���久存储的，它们都是缓存方案，而�是存储.但是我们在这里指出是因为基于内存的缓存特别的短暂 .

数�库缓存

为了将数�库表作为缓存�端，需�在数�库中创建一个缓存表并将Django的缓存系统指�该表

首先,使用如下语�创建一个缓存用数�表:

python manage.py createcachetable [cache_table_name]

这里的[cache_table_name]是�创建的数�库表�，�字�以是任何你想�的，��它是�法的在你的数�库中没有被使用，这个命令在你的数�库创建一个�循Django的数�库缓存系统期望形�的�独的表.

一旦你创建了数æ�®åº“表，设置你的CACHE_BACKEND设置为”db://tablename”，这里的tablename是数æ�®åº“表的å��字，在这个例å­�中，缓存表å��为my_cache_table:

CACHE_BACKEND = 'db://my_cache_table'

数�库缓存�端使用你的settings文件指定的�一数�库，你�能为你的缓存表使用��的数�库�端.

文件系统缓存

使用”file://“缓存类型作为CACHE_BACKEND并指定存储缓存数æ�®çš„文件系统目录æ�¥åœ¨æ–‡ä»¶ç³»ç»Ÿå­˜å‚¨ç¼“存数æ�®.

例如，使用下�的设置�在/var/tmp/django_cache存储缓存数�:

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

注æ„�例å­�中开头有三个å‰�斜线，å‰�两个是file://，第三个是目录路径的第一个字符，/var/tmp/django_cache，如果你使用Windows系统，把盘符字æ¯�放在file://å�Žé�¢ï¼Œåƒ�这样:’file://c:/foo/bar‘.

目录路径应该是*�对*路径，�应该以你的文件系统的根开始，你在设置的结尾放置斜线与�无关紧�.

确认该设置指�的目录存在并且你的Web�务器�行的系统的用户�以读写该目录，继续上�的例�，如果你的�务器以用户apache�行，确认/var/tmp/django_cache存在并且用户apache�以读写/var/tmp/django_cache目录

æ¯�个缓存值将被存储为å�•ç‹¬çš„文件，其内容是Pythonçš„pickle模å�—以åº�列化(“pickled”)å½¢å¼�ä¿�存的缓存数æ�®ï¼Œæ¯�个文件的 文件å��是缓存键，以规é�¿å¼€å®‰å…¨æ–‡ä»¶ç³»ç»Ÿçš„使用

本地内存缓存

如果你想�内存缓存的速度优势但没有能力�行Memcached，�以考虑使用本地存储器缓存�端，该缓存是多线程和线程安全 的，但是由于其简�的�和内存分�策略它没有Memcached高效

设置 CACHE_BACKEND 为 locmem:/// �使用它，例如:

CACHE_BACKEND = 'locmem:///'

简易缓存（用于开�阶段）

�以通过�置 'simple:///' �使用一个简�的�进程内存缓存，例如：

CACHE_BACKEND = 'simple:///'

这个缓存仅仅是将数��存在进程内，因此它应该�在开�环境或测试环境中使用.

仿缓存（供开�时使用）

最�，Django�供一个�缓存的设置：它仅仅实现了缓存的接�而��任何实际的事情

这是个有用的特性，如果你的线上站点使用了很多比较�的缓存，而在开�环境中��想使用缓存，那么你��修改�置文件，将 CACHE_BACKEND 设置为 'dummy:///' 就�以了，例如：

CACHE_BACKEND = 'dummy:///'

这样的结果就是你的开�环境没有使用缓存，而线上环境�然在使用缓存.

CACHE_BACKEND�数

�个缓存�端都�能使用�数，它们在CACHE_BACKEND设置中以查询字符串形�给出，�法的�数为:

timeout:用于缓存的过期时间，以秒为��。这个�数默认被设置为300秒（五分钟）

max_entries : 对于simple, local-memory与database类型的缓存,这个�数是指定缓存中存放的最大�目数，大于这个数时，旧的�目将会被删除。这个�数默认是300.

cull_frequency :当达到 max_entries 的时候,被接�的访问的比率。实际的比率是 1/cull_frequency ,所以设置cull_frequency=2就是在达到 max_entries 的时候去除一�数�的缓存

把 cull_frequency 的值设置为 0 �味�当达到 max_entries 时,缓存将被清空。这将以很多缓存丢失为代价,大大�高接�访问的速度。这个值默认是3

在这个例�中， timeout 被设� 60

CACHE_BACKEND = "locmem:///?timeout=60"

而在这个例�中， timeout 设为 30 而 max_entries 为 400 :

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

其中，�法的�数与�法的�数值都将被忽略。

在 URLconf 中指定视图缓存

�一节中的范例将视图硬编�为使用缓存，因为 cache_page 在适当的�置对 my_view 函数进行了转�。该方法将视图与缓存系统进行了耦�，从几个方��说并��想。例如，你�能想在�个无缓存的站点中�用该视图函数，或者你�能想将该视图�布给那些�想通过缓存使用它们的人。解决这些问题的方法是在 URLconf 中指定视图缓存，而�是紧挨�这些视图函数本身�指定。

完�这项工作�常简�：在 URLconf 中用到这些视图函数的时候简�地包裹一个 cache_page 。以下是刚�用到过的 URLconf :

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

以下是�一个 URLconf ，�过用 cache_page 包裹了 my_view ：

from django.views.decorators.cache import cache_page

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

如果采�这�方法, ��忘记在 URLconf 中导入 cache_page .

使用 Vary 头标

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

缺�情况下，Django 的缓存系统使用所请求的路径（比如： "/stories/2005/jun/23/bank_robbed/" ）�创建其缓存键。这�味�对该 URL 的�个请求都将使用�一个已缓存版本，而�考虑 cookies 或语言�好之类的 user-agent 差别。然而，如果该页�基于请求头标的区别（例如 cookies�语言或者 user-agent)产生��内容，你就�得�使用

Vary 头标�通知缓存机制：该页�的输出�决于这些东西。

�在 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-Control HTTP 指令的相关解释, �以查阅 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 的规范文档。

注�

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