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 ，该修饰器将会取得优先权，该头标的值将被正确地被合并。）