The Django Book

Memcached

内存缓冲

By far the fastest, most efficient type of cache available to Django, Memcached is an entirely memory-based cache framework originally developed to handle high loads at LiveJournal (http://www.livejournal.com/) and subsequently open-sourced by Danga Interactive (http://danga.com/). Its used by sites such as Slashdot and Wikipedia to reduce database access and dramatically increase site performance.

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

Memcached is available for free at http://danga.com/memcached/. It runs as a daemon and is allotted a specified amount of RAM. Its primary feature is to provide an interfacea super-lightning-fast interfacefor adding, retrieving, and deleting arbitrary data in the cache. All data is stored directly in memory, so theres no overhead of database or filesystem usage.

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

After installing Memcached itself, youll need to install the Memcached Python bindings, which are not bundled with Django directly. These bindings are in a single Python module, memcache.py , which is available at http://www.tummy.com/Community/software/python-memcached/.

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

To use Memcached with Django, set CACHE_BACKEND to memcached://ip:port/ , where ip is the IP address of the Memcached daemon and port is the port on which Memcached is running.

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

In this example, Memcached is running on localhost (127.0.0.1) port 11211:

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

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

One excellent feature of Memcached is its ability to share cache over multiple servers. This means you can run Memcached daemons on multiple machines, and the program will treat the group of machines as a single cache, without the need to duplicate cache values on each machine. To take advantage of this feature with Django, include all server addresses in CACHE_BACKEND , separated by semicolons.

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

In this example, the cache is shared over Memcached instances running on the IP addresses 172.19.26.240 and 172.19.26.242, both of which are on port 11211:

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

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

In the following example, the cache is shared over Memcached instances running on the IP addresses 172.19.26.240 (port 11211), 172.19.26.242 (port 11212), and 172.19.26.244 (port 11213):

这个例�中，缓存在�行在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/'

A final point about Memcached is that memory-based caching has one important disadvantage. Because the cached data is stored only in memory, the data will be lost if your server crashes. Clearly, memory isnt intended for permanent data storage, so dont rely on memory-based caching as your only data storage. Without a doubt, none of the Django caching back-ends should be used for permanent storagetheyre all intended to be solutions for caching, not storagebut we point this out here because memory-based caching is particularly temporary.

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

Database Caching

数�库缓存

To use a database table as your cache back-end, create a cache table in your database and point Djangos cache system at that table.

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

First, create a cache table by running this command:

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

python manage.py createcachetable [cache_table_name]

where [cache_table_name] is the name of the database table to create. This name can be whatever you want, as long as its a valid table name thats not already being used in your database. This command creates a single table in your database that is in the proper format Djangos database-cache system expects.

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

Once youve created that database table, set your CACHE_BACKEND setting to "db://tablename" , where tablename is the name of the database table. In this example, the cache tables name is my_cache_table :

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

CACHE_BACKEND = 'db://my_cache_table'

The database caching back-end uses the same database as specified in your settings file. You cant use a different database back-end for your cache table.

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

Filesystem Caching

文件系统缓存

To store cached items on a filesystem, use the "file://" cache type for CACHE_BACKEND , specifying the directory on your filesystem that should store the cached data.

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

For example, to store cached data in /var/tmp/django_cache , use this setting:

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

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

Note that there are three forward slashes toward the beginning of the preceding example. The first two are for file:// , and the third is the first character of the directory path, /var/tmp/django_cache . If youre on Windows, put the drive letter after the file:// , like so:: file://c:/foo/bar .

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

The directory path should be absolute that is, it should start at the root of your filesystem. It doesnt matter whether you put a slash at the end of the setting.

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

Make sure the directory pointed to by this setting exists and is readable and writable by the system user under which your Web server runs. Continuing the preceding example, if your server runs as the user apache , make sure the directory /var/tmp/django_cache exists and is readable and writable by the user apache .

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

Each cache value will be stored as a separate file whose contents are the cache data saved in a serialized (pickled) format, using Pythons pickle module. Each files name is the cache key, escaped for safe filesystem use.

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

Local-Memory Caching

本地内存缓存

If you want the speed advantages of in-memory caching but dont have the capability of running Memcached, consider the local-memory cache back-end. This cache is per-process and thread-safe, but it isnt as efficient as Memcached due to its simplistic locking and memory allocation strategies.

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

To use it, set CACHE_BACKEND to 'locmem:///' , for example:

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

CACHE_BACKEND = 'locmem:///'

Simple Caching (for Development)

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

A simple, single-process memory cache is available as 'simple:///' , for example:

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

CACHE_BACKEND = 'simple:///'

This cache merely saves cached data in process, which means it should be used only in development or testing environments.

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

Dummy Caching (for Development)

仿缓存（供开�时使用）

Finally, Django comes with a dummy cache that doesnt actually cache; it just implements the cache interface without doing anything.

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

This is useful if you have a production site that uses heavy-duty caching in various places and a development/test environment on which you dont want to cache. In that case, set CACHE_BACKEND to 'dummy:///' in the settings file for your development environment, for example:

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

CACHE_BACKEND = 'dummy:///'

As a result, your development environment wont use caching, but your production environment still will.

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

CACHE_BACKEND Arguments

CACHE_BACKEND�数

Each cache back-end may take arguments. Theyre given in query-string style on the CACHE_BACKEND setting. Valid arguments are as follows:

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

timeout : The default timeout, in seconds, to use for the cache. This argument defaults to 300 seconds (5 minutes).

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

max_entries : For the simple, local-memory, and database back-ends, the maximum number of entries allowed in the cache before old values are deleted. This argument defaults to 300.

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

cull_frequency : The ratio of entries that are culled when max_entries is reached. The actual ratio is 1/cull_frequency , so set cull_frequency=2 to cull half of the entries when max_entries is reached.

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

A value of 0 for cull_frequency means that the entire cache will be dumped when max_entries is reached. This makes culling much faster at the expense of more cache misses. This argument defaults to 3.

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

In this example, timeout is set to 60 :

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

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

In this example, timeout is 30 and max_entries is 400 :

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

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

Invalid arguments are silently ignored, as are invalid values of known arguments.

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

Specifying Per-View Cache in the URLconf

在 URLconf 中指定视图缓存

The examples in the previous section have hard-coded the fact that the view is cached, because cache_page alters the my_view function in place. This approach couples your view to the cache system, which is not ideal for several reasons. For instance, you might want to reuse the view functions on another, cacheless site, or you might want to distribute the views to people who might want to use them without being cached. The solution to these problems is to specify the per-view cache in the URLconf rather than next to the view functions themselves.

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

Doing so is easy: simply wrap the view function with cache_page when you refer to it in the URLconf. Heres the old URLconf from earlier:

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

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

Heres the same thing, with my_view wrapped in cache_page :

以下是�一个 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)),
)

If you take this approach, dont forget to import cache_page within your URLconf.

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

Using Vary Headers

使用 Vary 头标

The Vary header defines which request headers a cache mechanism should take into account when building its cache key. For example, if the contents of a Web page depend on a users language preference, the page is said to vary on language.

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

By default, Djangos cache system creates its cache keys using the requested path (e.g., "/stories/2005/jun/23/bank_robbed/" ). This means every request to that URL will use the same cached version, regardless of user-agent differences such as cookies or language preferences. However, if this page produces different content based on some difference in request headerssuch as a cookie, or a language, or a user-agentyoull need to use the Vary header to tell caching mechanisms that the page output depends on those things.

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

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

To do this in Django, use the convenient vary_on_headers view decorator, like so:

�在 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):
    # ...

In this case, a caching mechanism (such as Djangos own cache middleware) will cache a separate version of the page for each unique user-agent.

在这�情况下，缓存装置（如 Django 自己的缓存中间件）将会为�一个�独的用户�览器缓存一个独立的页�版本。

The advantage to using the vary_on_headers decorator rather than manually setting the Vary header (using something like response['Vary'] = 'user-agent' ) is that the decorator adds to the Vary header (which may already exist), rather than setting it from scratch and potentially overriding anything that was already in there.

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

You can pass multiple headers to vary_on_headers() :

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

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

This tells upstream caches to vary on both , which means each combination of user-agent and cookie will get its own cache value. For example, a request with the user-agent Mozilla and the cookie value foo=bar will be considered different from a request with the user-agent Mozilla and the cookie value foo=ham .

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

Because varying on cookie is so common, theres a vary_on_cookie decorator. These two views are equivalent:

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

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

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

The headers you pass to vary_on_headers are not case sensitive; "User-Agent" is the same thing as "user-agent" .

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

You can also use a helper function, django.utils.cache.patch_vary_headers , directly. This function sets, or adds to, the Vary header , for example:

你也�以直接使用帮助函数： 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 takes an HttpResponse instance as its first argument and a list/tuple of case-insensitive header names as its second argument.

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

Other Cache Headers

其它缓存头标

Other problems with caching are the privacy of data and the question of where data should be stored in a cascade of caches.

关于缓存剩下的问题是数�的��性以�关于在级�缓存中数�应该在何处储存的问题。

A user usually faces two kinds of caches: his or her own browser cache (a private cache) and his or her providers cache (a public cache). A public cache is used by multiple users and controlled by someone else. This poses problems with sensitive datayou dont want, say, your bank account number stored in a public cache. So Web applications need a way to tell caches which data is private and which is public.

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

The solution is to indicate a pages cache should be private. To do this in Django, use the cache_control view decorator:

解决方案是标示出�个页�缓存应当是�有的。�在 Django 中完�此项工作，�使用 cache_control 视图修饰器：

from django.views.decorators.cache import cache_control

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

This decorator takes care of sending out the appropriate HTTP header behind the scenes.

该修饰器负责在����相应的 HTTP 头标。

There are a few other ways to control cache parameters. For example, HTTP allows applications to do the following:

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

• Define the maximum time a page should be cached.

• 定义页é�¢å�¯ä»¥è¢«ç¼“存的最大次数。

• Specify whether a cache should always check for newer versions, only delivering the cached content when there are no changes. (Some caches might deliver cached content even if the server page changed, simply because the cache copy isnt yet expired.)

• 指定æŸ�个缓存是å�¦æ€»æ˜¯æ£€æŸ¥è¾ƒæ–°ç‰ˆæœ¬ï¼Œä»…当无更新时æ‰�传递所缓存内容。（一些缓存å�³ä¾¿åœ¨æœ�务器页é�¢å�‘生å�˜åŒ–的情况下都å�¯èƒ½è¿˜ä¼šä¼ é€�所缓存的内容，å�ªå› ä¸ºç¼“存拷è´�没有过期。）

In Django, use the cache_control view decorator to specify these cache parameters. In this example, cache_control tells caches to revalidate the cache on every access and to store cached versions for, at most, 3,600 seconds:

在 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):
    ...

Any valid Cache-Control HTTP directive is valid in cache_control() . Heres a full list:

在 cache_control() 中，任何有效 Cache-Control HTTP 指令都是有效的。以下是一个完整的清�：

• public=True

• public=True

• private=True

• private=True

• no_cache=True

• no_cache=True

• no_transform=True

• no_transform=True

• must_revalidate=True

• must_revalidate=True

• proxy_revalidate=True

• proxy_revalidate=True

• max_age=num_seconds

• max_age=num_seconds

• s_maxage=num_seconds

• s_maxage=num_seconds

Tip

��示

For explanation of Cache-Control HTTP directives, see the specification at http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.

�了解有关 Cache-Control HTTP 指令的相关解释, �以查阅 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 的规范文档。

Note

注�

The caching middleware already sets the cache headers max-age with the value of the CACHE_MIDDLEWARE_SETTINGS setting. If you use a custom max_age in a cache_control decorator, the decorator will take precedence, and the header values will be merged correctly.)

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