Django 缓存机制

r/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 被设成 60CACHE_BACKEND = "memcached://127.0.0.1:11211/?timeout=60"而在这个例子中， timeout 设为 30 而 max_entries 为 400 :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_pagedef 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 的请求将使用缓存。在 URLconf 中指定视图缓存前一节中的范例将视图硬编码为使用缓存，因为 cache_page 在适当的位置对 my_view 函数进行