第十五章：缓存机制 · The Django Book 2.0中文版

动态网站的问题就在于它是动态的。也就是说每次用户访问一个页面，服务器要执行数据库查询，启动模板，执行业务逻辑以及最终生成一个你所看到的网页，这一切都是动态即时生成的。从处理器资源的角度来看，这是比较昂贵的。对于大多数网络应用来说，过载并不是大问题。因为大多数网络应用并不是washingtonpost.com或Slashdot；它们通常是很小很简单，或者是中等规模的站点，只有很少的流量。但是对于中等至大规模流量的站点来说，尽可能地解决过载问题是非常必要的。这就需要用到缓存了。缓存的目的是为了避免重复计算，特别是对一些比较耗时间、资源的计算。下面的伪代码演示了如何对动态页面的结果进行缓存。 ~~~ given a URL, try finding that page in the cache if the page is in the cache: return the cached page else: generate the page save the generated page in the cache (for next time) return the generated page ~~~ 为此，Django提供了一个稳定的缓存系统让你缓存动态页面的结果，这样在接下来有相同的请求就可以直接使用缓存中的数据，避免不必要的重复计算。另外Django还提供了不同粒度数据的缓存，例如：你可以缓存整个页面，也可以缓存某个部分，甚至缓存整个网站。 Django也和”上游”缓存工作的很好，例如Squid(http://www.squid-cache.org)和基于浏览器的缓存。这些类型的缓存你不直接控制，但是你可以提供关于你的站点哪部分应该被缓存和怎样缓存的线索(通过HTTP头部)给它们 ## 设定缓存缓存系统需要一些少量的设定工作。也就是说，你必须告诉它缓存的数据应该放在哪里，在数据库中，在文件系统，或直接在内存中。这是一个重要的决定，影响您的高速缓存的性能，是的，有些类型的缓存比其它类型快。缓存设置在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://](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" ~~~ 其中，非法的参数与非法的参数值都将被忽略。 ## 站点级 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_page def 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 函数进行了转换。该方法将视图与缓存系统进行了耦合，从几个方面来说并不理想。例如，你可能想在某个无缓存的站点中重用该视图函数，或者你可能想将该视图发布给那些不想通过缓存使用它们的人。解决这些问题的方法是在 URLconf 中指定视图缓存，而不是紧挨着这些视图函数本身来指定。完成这项工作非常简单：在 URLconf 中用到这些视图函数的时候简单地包裹一个 cache_page 。以下是刚才用到过的 URLconf : 这是之前的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。 ## 模板碎片缓存你同样可以使用cache标签来缓存模板片段。在模板的顶端附近加入{% load cache %}以通知模板存取缓存标签。模板标签{% cache %}在给定的时间内缓存了块的内容。它至少需要两个参数: 缓存超时时间（以秒计）和指定缓存片段的名称。示例： ~~~ {% load cache %} {% cache 500 sidebar %} .. sidebar .. {% endcache %} ~~~ 有时你可能想缓存基于片段的动态内容的多份拷贝。比如，你想为上一个例子的每个用户分别缓存侧边栏。这样只需要给{% cache %}传递额外的参数以标识缓存片段。 ~~~ {% load cache %} {% cache 500 sidebar request.user.username %} .. sidebar for logged in user .. {% endcache %} ~~~ 传递不止一个参数也是可行的。简单地把参数传给{% cache %}。缓存超时时间可以作为模板变量，只要它可以解析为整数值。例如，如果模板变量my_timeout值为600，那么以下两个例子是等价的。 ~~~ {% cache 600 sidebar %} ... {% endcache %} {% cache my_timeout sidebar %} ... {% endcache %} ~~~ 这个特性在避免模板重复方面非常有用。可以把超时时间保存在变量里，然后在别的地方复用。 ## 低层次缓存API 有些时候，对整个经解析的页面进行缓存并不会给你带来太多好处，事实上可能会过犹不及。比如说，也许你的站点所包含的一个视图依赖几个费时的查询，每隔一段时间结果就会发生变化。在这种情况下，使用站点级缓存或者视图级缓存策略所提供的整页缓存并不是最理想的，因为你可能不会想对整个结果进行缓存（因为一些数据经常变化），但你仍然会想对很少变化的部分进行缓存。针对这样的情况，Django提供了简单低级的缓存API。你可以通过这个API，以任何你需要的粒度来缓存对象。你可以对所有能够安全进行 pickle 处理的 Python 对象进行缓存：字符串、字典和模型对象列表等等。（查阅 Python 文档可以了解到更多关于 pickling 的信息。）缓存模块django.core.cache拥有一个自动依据CACHE_BACKEND设置创建的django.core.cache对象。 ~~~ >>> from django.core.cache import cache ~~~ 基本的接口是 set(key, value, timeout_seconds) 和 get(key) : ~~~ >>> cache.set('my_key', 'hello, world!', 30) >>> cache.get('my_key') 'hello, world!' ~~~ timeout_seconds 参数是可选的, 并且默认为前面讲过的 CACHE_BACKEND 设置中的 timeout 参数. 如果缓存中不存在该对象，那么cache.get()会返回None。 ~~~ # Wait 30 seconds for 'my_key' to expire... >>> cache.get('my_key') None ~~~ 我们不建议在缓存中保存 None 常量，因为你将无法区分你保存的 None 变量及由返回值 None 所标识的缓存未命中。 cache.get() 接受一个缺省参数。它指定了当缓存中不存在该对象时所返回的值： ~~~ >>> cache.get('my_key', 'has expired') 'has expired' ~~~ 使用add()方法来新增一个原来没有的键值。它接受的参数和set()一样，但是并不去尝试更新已经存在的键值。 ~~~ >>> cache.set('add_key', 'Initial value') >>> cache.add('add_key', 'New value') >>> cache.get('add_key') 'Initial value' ~~~ 如果想确定add()是否成功添加了缓存值，你应该测试返回值。成功返回True，失败返回False。还有个get_many()接口。 get_many() 所返回的字典包括了你所请求的存在于缓存中且未超时的所有键值。 ~~~ >>> cache.set('a', 1) >>> cache.set('b', 2) >>> cache.set('c', 3) >>> cache.get_many(['a', 'b', 'c']) {'a': 1, 'b': 2, 'c': 3} ~~~ 最后,你可以用 cache.delete() 显式地删除关键字。 ~~~ >>> cache.delete('a') ~~~ 也可以使用incr()或者decr()来增加或者减少已经存在的键值。默认情况下，增加或减少的值是1。可以用参数来制定其他值。如果尝试增减不存在的键值会抛出ValueError。 ~~~ >>> cache.set('num', 1) >>> cache.incr('num') 2 >>> cache.incr('num', 10) 12 >>> cache.decr('num') 11 >>> cache.decr('num', 5) 6 ~~~ > 注意 > incr()/decr()方法不是原子操作。在支持原子增减的缓存后端上（最著名的是memcached），增减操作才是原子的。然而，如果后端并不原生支持增减操作，也可以通过取值/更新两步操作来实现。 ## 上游缓存目前为止，本章的焦点一直是对你 _自己的_ 数据进行缓存。但还有一种与 Web 开发相关的缓存：上游缓存。有一些系统甚至在请求到达站点之前就为用户进行页面缓存。下面是上游缓存的几个例子： * 你的 ISP (互联网服务商)可能会对特定的页面进行缓存，因此如果你向 http://example.com/ 请求一个页面，你的 ISP 可能无需直接访问 example.com 就能将页面发送给你。而 example.com 的维护者们却无从得知这种缓存，ISP 位于 example.com 和你的网页浏览器之间，透明地处理所有的缓存。 * 你的 Django 网站可能位于某个 _代理缓存_ 之后，例如 Squid 网页代理缓存 (http://www.squid-cache.org/)，该缓存为提高性能而对页面进行缓存。在此情况下，每个请求将首先由代理服务器进行处理，然后仅在需要的情况下才被传递至你的应用程序。 * 你的网页浏览器也对页面进行缓存。如果某网页送出了相应的头部，你的浏览器将在为对该网页的后续的访问请求使用本地缓存的拷贝，甚至不会再次联系该网页查看是否发生了变化。上游缓存将会产生非常明显的效率提升，但也存在一定风险。许多网页的内容依据身份验证以及许多其他变量的情况发生变化，缓存系统仅盲目地根据 URL 保存页面，可能会向这些页面的后续访问者暴露不正确或者敏感的数据。举个例子，假定你在使用网页电邮系统，显然收件箱页面的内容取决于登录的是哪个用户。如果 ISP 盲目地缓存了该站点，那么第一个用户通过该 ISP 登录之后，他（或她）的用户收件箱页面将会缓存给后续的访问者。这一点也不好玩。幸运的是， HTTP 提供了解决该问题的方案。已有一些 HTTP 头标用于指引上游缓存根据指定变量来区分缓存内容，并通知缓存机制不对特定页面进行缓存。我们将在本节后续部分将对这些头标进行阐述。 ## 使用 Vary头部 Vary 头部定义了缓存机制在构建其缓存键值时应当将哪个请求头标考虑在内。例如，如果网页的内容取决于用户的语言偏好，该页面被称为根据语言而不同。缺省情况下，Django 的缓存系统使用所请求的路径（比如："/stories/2005/jun/23/bank_robbed/" ）来创建其缓存键。这意味着每次请求都会使用同样的缓存版本，不考虑才客户端cookie和语言配置的不同。除非你使用Vary头部通知缓存机制页面输出要依据请求头里的cookie，语言等的设置而不同。要在 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_MIDDLEWARE_SETTINGS 设置设定了缓存头部 max-age 。如果你在cache_control修饰器中使用了自定义的max_age，该修饰器将会取得优先权，该头部的值将被正确地被合并。如果你想用头部完全禁掉缓存，django.views.decorators.cache.never_cache装饰器可以添加确保响应不被缓存的头部信息。例如： ~~~ from django.views.decorators.cache import never_cache @never_cache def myview(request): # ... ~~~ ## 其他优化 Django 带有一些其它中间件可帮助您优化应用程序的性能: * django.middleware.http.ConditionalGetMiddleware 为现代浏览器增加了有条件的，基于 ETag 和Last-Modified 头标的GET响应的相关支持。 * django.middleware.gzip.GZipMiddleware 为所有现代浏览器压缩响应内容，以节省带宽和传送时间。 ## MIDDLEWARE_CLASSES 的顺序如果使用缓存中间件，注意在MIDDLEWARE_CLASSES设置中正确配置。因为缓存中间件需要知道哪些头部信息由哪些缓存区来区分。中间件总是尽可能得想Vary响应头中添加信息。 UpdateCacheMiddleware在相应阶段运行。因为中间件是以相反顺序运行的，所有列表顶部的中间件反而_last_在相应阶段的最后运行。所有，你需要确保UpdateCacheMiddleware排在任何可能往_Vary_头部添加信息的中间件之前。下面的中间件模块就是这样的： * 添加 Cookie 的 SessionMiddleware * 添加 Accept-Encoding 的 GZipMiddleware * 添加Accept-Language的LocaleMiddleware 另一方面，FetchFromCacheMiddleware在请求阶段运行，这时中间件循序执行，所以列表顶端的项目会_首先_执行。 FetchFromCacheMiddleware也需要在会修改Vary头部的中间件之后运行，所以FetchFromCacheMiddleware必须放在它们_后面_。 ## 下一章 Django捆绑了一系列可选的方便特性。我们已经介绍了一些： admin站点（第六章）和session/user框架（第十四章）。下一章中，我们将讲述Django中其他的子框架。