原文在此。翻译：我；润色： Cindy 。 注意：此文章中包含引用自 Speaker Deck 的幻灯片，如果你无法正常访问 Speaker Deck ，将无法看到这些内容。 剧透：其实通篇内容只有两个字：“缓存”。

mattrobenolt 发表于 2013年9月24日

接近每月80亿页面访问量以及每秒45000个请求，让我们学习到了如何给大量用户分发评论。 Disqus 以使用 Django 处理几乎所有 Web 流量而著称，并且现在也是如此。 对于任何 Web 框架都有起内在的权衡：快速开发 vs 性能，新手熟悉程度 vs 用户定制 等等。 相较于性能， Disqus 更乐意倾向于快速开发、新手熟悉程度，以及针对我们实际需求进行调整。

Web 框架为何变慢？

表面上看，第一印象可能是由于其中有很多样板文件以及非必需代码。 这种印象没有错。 实际上，运行缓慢通常不是你选择的语言或者框架的臃肿造成的，而可能是你的请求正在通过网络与其他服务进行通信的结果。 在我们的案例中，举几例来说，这些服务是 PostgreSQL 、 Redis 、 Cassandra 和 Memcached 。 缓慢的数据库查询和网络延迟通常超出了像 Django 这种健壮框架的性能开销。

为了避开这些延迟，人们使用各种各样的缓存。 最明显的途径就是使用 Django 内建的缓存库。

应用层面缓存的一般模式如下：

1
2
3
4
5

data = cache.get('stuff')
if data is None:
    data = list(Stuff.objects.all())
    cache.set('stuff', data)
return data

如果你对 Django 熟悉的话，对这个模式应该也很熟悉。 这种形式的缓存简单直接，足够应对大部分情况。 它配合 Memcached 一起使用已经足够快，但要响应一个请求还有很多工作要做。

每秒处理45000请求

我们已经缓存了那些“缓慢”的东西。在每秒45000请求的压力下还有很多工作要做。 我们可能要渲染 JSON 、渲染 HTML 模板，或者简单地解析 HTML 并执行我们的 Django 中间件。 重点是，我们想要短路这些工作，让 Django 做它最擅长的：只处理独特的数据。

45000个请求中有多少是真正独特的？ 这些响应中有多少是真的与其他不一样的？ 如果结果总是一样的话，我们真的有必要把相同的工作一遍遍重复吗？ 我们真想把整个响应都缓存起来，直接跳过其他所有流程。

Varnish 简介

Varnish 是什么？ Varnish 是处于我们的负载均衡系统与 Django 后端中，作为 HTTP 缓存层的一个软件。 这意味着如果某个请求并非独特的， Varnish 就能缓存整个 HTTP 响应，（请求）甚至都无需命中 Django 服务器。

从前， Varnish 对我们来说就相当于一个黑盒。 我们安装后仅进行了非常少的配置，说实话它运作得非常好。 但是我觉得我们能做得更多。

我花了一点时间来学习更多关于 Varnish 以及一些我们能够使用到的其他技巧。 随着时间的推移，我们已经能够从 Django 服务器接收的请求中每秒剔除掉几千次请求。 如今，每秒45000个入站请求中，只有15000个左右真正命中我们的应用服务器。 其余的请求都由 Varnish 接管，并且快速高效地服务于客户。

这对于我们是非常实用的，也是一种很棒的学习经历，这已经成为我最近一些讲话的主题。

最近我在芝加哥的 DjangoCon US 做了演讲，主要针对的是不熟悉 Varnish 的人，希望能够鼓励和激发他们更深入的了解。 对我来说，这次演讲是非常激动人心的，因为这对于应用开发者来说不是经常被提到的话题。 我非常想在几年前就听到这样的演讲，同时在理解 HTTP 是怎样工作的和如何操纵 HTTP 与像 Varnish 这样的工具互动方面，我非常希望能够建立起桥梁。

在这之前我在纽约 VUG7 （Varnish 用户组）上做过演讲，并且分享了一些帮助我们克服某些问题所使用的确切的技巧。这次演讲中谈到了许多关于 VCL 的详情，我们利用 VCL 为每个终端需求提供嵌入（代码）。

言简意赅

尝试一下 Varnish 。它不能解决你所有的问题，但它值得你投资时间去学习和评价。

如果你对这些感兴趣，并且你能接受每周与我对着电脑大喊五天的话，请联系我们，我们正在招聘！