设定缓存

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

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

内存缓冲

Memcached是迄今为止可用于Django的最快，最有效的缓存类型，Memcached是完全基于内存的缓存框架，最初开发它是用以处理高负荷的LiveJournal.com随后由Danga Interactive公司开源。 它被用于一些站点，例如Facebook和维基百科网站，以减少数据库访问，并大幅提高站点的性能。

Memcached是免费的（http://danga.com/memcached）。它作为一个守护进程运行，并分配了特定数量的内存。 它只是提供了添加，检索和删除缓存中的任意数据的高速接口。 所有数据都直接存储在内存中，所以没有对使用的数据库或文件系统的开销。

在安装了Memcached本身之后，你将需要安装Memcached Python绑定，它没有直接和Django绑定。 这两个可用版本。 选择和安装以下模块之一：

• 最快的可用选项是一个模块，称为cmemcache，在http://gijsbert.org/cmemcache。

• 如果您无法安装cmemcache，您可以安装python - Memcached，在ftp://ftp.tummy.com/pub/python-memcached/。如果该网址已不再有效，只要到Memcached的网站http://www.danga.com/memcached/），并从客户端API完成Python绑定。

若要使用Memcached的Django，设置CACHE_BACKEND到memcached：/ / IP：port/，其中IP是Memcached的守护进程的IP地址，port是Memcached运行的端口。

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

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

Memcached的一个极好的特性是它在多个服务器间分享缓存的能力。 这意味着您可以在多台机器上运行Memcached的守护进程，该程序会把这些机器当成一个单一缓存，而无需重复每台机器上的缓存值。 要充分利用此功能，请在CACHE_BACKEND里引入所有服务器的地址，用分号分隔。

这个例子中，缓存在运行在IP地址为172.19.26.240和172.19.26.242，端口号为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的缓存后端不应该用于持久化，它们本来就被设计成缓存的解决方案。但我们仍然指出此点，这里是因为基于内存的缓存是暂时的。

数据库缓存

为了使用数据库表作为缓存后端，首先在数据库中运行这个命令以创建缓存表：

python manage.py createcachetable [cache_table_name]

这里的[cache_table_name]是要创建的数据库表名。 （这个名字随你的便，只要它是一个有效的表名，而且不是已经在您的数据库中使用的表名。）这个命令以Django的数据库缓存系统所期望的格式创建一个表。

一旦你创建了数据库表，把你的CACHE_BACKEND设置为”db://tablename”，这里的tablename是数据库表的名字，在这个例子中，缓存表名为my_cache_table: 在这个例子中，高速缓存表的名字是my_cache_table：

CACHE_BACKEND = 'db://my_cache_table'

数据库缓存后端使用你的settings文件指定的同一数据库。 你不能为你的缓存表使用不同的数据库后端.

如果你已经有了一个快速，良好的索引数据库服务器，那么数据库缓存的效果最明显。

文件系统缓存

要把缓存项目放在文件系统上，请为CACHE_BACKEND使用”file://“的缓存类型。例如，要把缓存数据存储在/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，可以考虑使用本地存储器缓存后端。 此缓存的多进程和线程安全。 设置 CACHE_BACKEND 为 locmem:/// 来使用它，例如:

CACHE_BACKEND = 'locmem:///'

请注意，每个进程都有自己私有的缓存实例，这意味着跨进程缓存是不可能的。 这显然也意味着本地内存缓存效率并不是特别高，所以对产品环境来说它可能不是一个好选择。 对开发来说还不错。

仿缓存（供开发时使用）

最后，Django提供了一个假缓存（只是实现了缓存接口，实际上什么都不做）。

假如你有一个产品站点，在许多地方使用高度缓存，但在开发/测试环境中，你不想缓存，也不想改变代码，这就非常有用了。 要激活虚拟缓存，就像这样设置CACHE_BACKEND：

CACHE_BACKEND = 'dummy:///'

使用自定义缓存后端

尽管Django包含对许多缓存后端的支持，在某些情况下，你仍然想使用自定义缓存后端。 要让Django使用外部缓存后端，需要使用一个Python import路径作为的CACHE_BACKEND URI的（第一个冒号前的部分），像这样：

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

如果您构建自己的后端，你可以参考标准缓存后端的实现。 源代码在Django的代码目录的django/core/cache/backends/下。

注意 如果没有一个真正令人信服的理由，比如主机不支持，你就应该坚持使用Django包含的缓存后端。 它们经过大量测试，并且易于使用。

CACHE_BACKEND参数

每个缓存后端都可能使用参数。 它们在CACHE_BACKEND设置中以查询字符串形式给出。 有效参数如下：

timeout:用于缓存的过期时间，以秒为单位。 这个参数默认被设置为300秒（五分钟）。max_entries：对于内存，文件系统和数据库后端，高速缓存允许的最大条目数，超出这个数则旧值将被删除。 这个参数默认是300。cull_percentage :当达到 max_entries 的时候,被删除的条目比率。 实际的比率是 1/cull_percentage ,所以设置cull_frequency=2就是在达到 max_entries 的时候去除一半数量的缓存。把 cull_frequency 的值设置为 0 意味着当达到 max_entries 时,缓存将被清空。 这将以很多缓存丢失为代价,大大提高接受访问的速度。

在这个例子中， timeout 被设成 60

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

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

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

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