扩展Django

既然您已经知道如何让Django在单个服务器上运行，那么我们来看看如何扩展Django安装。 本节将介绍站点如何从单个服务器扩展到可支持数百万次点击的大型群集。 然而，需要注意的是，几乎每个大型网站都以不同的方式大型化，因此扩展只是一种万能的操作。

下面的报道应该足以说明一般原则，只要有可能，我们会试着指出可以做出不同选择的地方。 首先，我们将做一个很大的假设，并专门讨论Apache和mod_python下的扩展。 虽然我们知道许多成功的中型到大型FastCGI部署，但我们对Apache更加熟悉。

在单台服务器上运行

大多数网站开始运行在单台服务器上，架构如图13-1所示。 但是，随着流量的增加，您将很快陷入不同软件之间的资源争夺。

数据库服务器和Web服务器喜欢将整个服务器放在自己的服务器上，因此当它们运行在同一台服务器上时，它们最终会争夺相同的资源（RAM，CPU），而他们更倾向于垄断它们。 通过将数据库服务器移动到第二台机器可以轻松解决这个问题。 图13-1：单个服务器Django设置.png

分离数据库服务器

就Django而言，分离数据库服务器的过程非常简单：您只需将DATABASE_HOST设置更改为数据库服务器的IP或DNS名称。如果可能的话使用IP可能是一个好主意，因为建议不要依赖DNS来连接Web服务器和数据库服务器。使用单独的数据库服务器，
我们的架构现在看起来如图13-2所示。

在这里，我们开始进入通常称为n层体系结构。不要被流行语所吓倒 - 它只是指不同层次的Web堆栈分离到不同的物理机器上。

此时，如果您预计需要超越单个数据库服务器，那么开始考虑连接池和/或数据库复制可能是一个好主意。不幸的是，本书中没有足够的空间来处理这些主题，因此您需要查阅数据库的文档和/或社区以获取更多信息。 图13-2：将数据库移动到专用服务器上.png

运行单独的媒体服务器

我们仍然存在单服务器设置遗留下来的大问题：从处理动态内容的相同盒子中提供媒体服务。这两种活动在不同的情况下表现最好，并且在同一个盒子里把它们砸在一起，你的表现都不会特别出色。

因此，下一步是将媒体（即，不是由Django视图生成的媒体）分离出来到专用服务器上（请参见图13-3）。

理想情况下，这个媒体服务器应该运行一个优化的静态媒体传送的简化Web服务器。 Nginx是这里的首选，尽管lighttpd是另一种选择，或者严重剥离Apache也可以。对于静态内容较多的网站（照片，视频等），转移到单独的媒体服务器是非常重要的，应该可能是扩大规模的第一步。

然而，这一步可能有点棘手。如果您的应用程序涉及文件上传，Django需要能够将上传的媒体写入媒体服务器。如果媒体存在于另一台服务器上，则需要为整个网络上的写入安排一种方式。 图13-3：分离出媒体服务器。.png

实现负载平衡和冗余

在这一点上，我们已经尽可能地分解了​​一些东西。这种三服务器设置应该处理大量的流量 - 我们每天从这种架构提供约1000万次点击 - 所以如果您进一步发展，您需要开始添加冗余。

实际上，这是一件好事。从图13-3可以看出，如果三台服务器中只有一台服务器出现故障，则会导致整个站点停机。因此，当您添加冗余服务器时，您不仅可以增加容量，还可以提高可靠性。为了这个例子，我们假设Web服务器首先击中容量。

获取在不同硬件上运行的Django站点的多个副本相对比较容易 - 只需将所有代码复制到多台计算机上，然后在所有计算机上启动Apache。但是，您需要另一个软件来将流量分配到多个服务器上：负载均衡器。

您可以购买昂贵且专有的硬件负载平衡器，但是那里有一些高质量的开源软件负载平衡器。 Apache的mod_proxy是一种选择，但我们发现Perlbal非常棒。它是由编写memcached的相同人员编写的负载均衡器和反向代理（请参见第16章）。

随着Web服务器现在集群化，我们不断发展的架构开始变得更加复杂，如图13-4所示。 图13-4：负载均衡的冗余服务器设置.png

请注意，在该图中，Web服务器被称为群集，以指示服务器的数量基本上是可变的。 一旦您拥有负载均衡器，您就可以轻松添加和删除后端Web服务器，而无需停机。

开始变大了

在这一点上，接下来的几步几乎是最后一步的衍生物：

• 由于您需要更多的数据库性能，因此您可能需要添加复制的数据库服务器。 MySQL包含内置复制; PostgreSQL用户应该分别查看Slony和pgpool的复制和连接池。

• 如果单个负载均衡器不够用，您可以在前面添加更多的负载均衡器机器，并使用循环DNS来分配它们。

• 如果单个介质服务器不足，则可以添加更多介质服务器，并使用负载平衡群集分配负载。

• 如果您需要更多缓存存储，则可以添加专用缓存服务器。

• 在任何阶段，如果群集性能不佳，则可以向群集添加更多服务器。
  

  经过几次这些迭代之后，大规模架构可能如图13-5所示 图13-5：一个大规模的Django设置示例。.png 尽管我们在每个级别上只显示了两到三台服务器，但您可以添加的数量没有根本的限制。

性能调整

如果你有大量的资金，你可以继续投放硬件来解决扩展问题。 但对于我们其他人来说，性能调整是必须的。

顺便说一句，如果有人带着可怕的现金在阅读这本书，请考虑向Django基金会捐款。 他们也接受未切割的钻石和金锭。

不幸的是，性能调优更像是一门艺术而不是一门科学，而写作比调整更困难。 如果您对部署大型Django应用程序非常认真，您应该花费大量时间学习如何调整您的每个堆栈。

但是，以下部分介绍了多年来我们发现的一些Django特定调优技巧。

没有太多内存的东西

即使是非常昂贵的RAM现在也相对便宜。 购买尽可能多的RAM，然后购买更多。 更快的处理器不会提高性能，大多数Web服务器花费高达90％的时间等待磁盘I / O。 只要你开始交换，性能就会消失。 更快的磁盘可能会有所帮助，但是它们比RAM更昂贵，所以它并不重要。

如果你有多个服务器，放置你的RAM的第一个地方是在数据库服务器中。 如果你负载担得起，获得足够的内存以适合你的整个数据库。 这不应该太难; 我们已经开发了一个有50多万份报纸文章的网站，并且它占用了2GB的空间。

接下来，在Web服务器上最大化RAM。 理想的情况是，不需要服务器互换。 如果你达到这一点，你应该能够承受最正常的交通。

关闭Keep-Alive

Keep-Alive是HTTP的一项功能，它允许通过单个TCP连接提供多个HTTP请求，避免TCP设置/拆卸开销。乍一看这看起来不错，但它可能会导致Django站点的性能下降。如果您正在从一台单独的服务器正常提供媒体服务，则每个浏览您网站的用户将只会每隔十秒左右从您的Django服务器请求一个页面。这使HTTP服务器等待下一个保持活动请求，而空闲的HTTP服务器只消耗活动的应该使用的RAM。

使用Memcached

尽管Django支持许多不同的缓存后端，但它们都没有像Memcached那么快。如果您拥有高流量的网站，请不要打扰其他后端 - 直接访问Memcached。

经常使用Memcached

当然，如果你没有真正使用它，选择memcached就不好。第16章是你最好的朋友：学习如何使用Django的缓存框架，并在任何可能的地方使用它。
积极的先发制人的高速缓存通常是唯一能够保持主要流量下的网站。

加入对话

每个Django堆栈 - 从Linux到Apache到PostgreSQL或MySQL - 都有一个非常棒的社区。如果你真的想在你的服务器中获得最后1％，请加入软件背后的开源社区并寻求帮助。大多数免费软件社区成员都乐意提供帮助。同时也一定要加入Django社区 - 一个令人难以置信的积极的，不断增长的Django开发者群体。我们的社区拥有丰富的集体经验。

下一步是什么？

其余章节着重介绍其他可能需要或可能不需要的Django功能，具体取决于您的应用程序。随意以任何您选择的顺序阅读它们。