Django 部署Django

能够获得足够的权限来处理上传的媒体（通过设置MEDIA_ROOT ）。如果媒体资源在另外的一台服务器上，你需要获得通过网络写操作的权限。 如果你的应用牵涉到文件上载，Django需要能够面向媒体服务器撰写上载媒体 如果媒体是在另外一台服务器上的，你需要部署一种方法使得Django可以通过网络去写这些媒体。实现负担均衡和数据冗余备份现在，我们已经尽可能地进行了分解。 这种三台服务器的构架可以承受很大的流量，比如每天1000万的点击率。这是个好主意。 请看图 20-3，一旦三个服务器中的任何一个发生了故障，你就得关闭整个站点。 因此在引入冗余备份的时候，你并不只是增加了容量，同时也增加了可靠性。我们首先来考虑Web服务器的点击量。 把同一个Django的站点复制多份，在多台机器上同时运行很容易，我们也只需要同时运行多台机器上的Apache服务器。你还需要另一个软件来帮助你在多台服务器之间均衡网络流量： 流量均衡器（load balancer） 。你可以购买昂贵的专有的硬件均衡器，当然也有一些高质量的开源的软件均衡器可供选择。Apaches 的 mod_proxy 是一个可以考虑的选择，但另一个配置更棒的选择是： memcached是同一个团队的人写的一个负载均衡和反向代理的程序.(见第15章)记录如果你使用FastCGI，你同样可以分离前台的web服务器，并在多台其他机器上运行FastCGI服务器来实现相同的负载均衡的功能。 前台的服务器就相当于是一个均衡器，而后台的FastCGI服务进程代替了Apache/mod_python/Django服务器。现在我们拥有了服务器集群，我们的构架慢慢演化，越来越复杂，如图20-4。图 20-4： 负载均衡的服务器设置。值得一提的是，在图中，Web服务器指的是一个集群，来表示许多数量的服务器。 一旦你拥有了一个前台的均衡器，你就可以很方便地增加和删除后台的Web服务器，而且不会造成任何网站不可用的时间。慢慢变大下面的这些步骤都是上面最后一个的变体：当你需要更好的数据库性能，你可能需要增加数据库的冗余服务器。 MySQL内置了备份功能；PostgreSQL应该看一下Slony (http://www.djangoproject.com/r/slony/) 和 pgpool (http://www.djangoproject.com/r/pgpool/) ，这两个分别是数据库备份和连接池的工具。如果单个均衡器不能达到要求，你可以增加更多的均衡器，并且使用轮训（round-robin）DNS来实现分布访问。如果单台媒体服务器不够用，你可以增加更多的媒体服务器，并通过集群来分布流量。如果你需要更多的高速缓存（cache），你可以增加cache服务器。在任何情况下，只要集群工作性能不好，你都可以往上增加服务器。重复了几次以后，一个大规模的构架会像图20-5。图 20-5。 大规模的Django安装。尽管我们只是在每一层上展示了两到三台服务器，你可以在上面随意地增加更多。性能优化如果你有大笔大笔的钱，遇到扩展性问题时，你可以简单地投资硬件。 对于剩下的人来说，性能优化就是必须要做的一件事。注意顺便提一句，谁要是有大笔大笔的钞票，请捐助一点Django项目。 我们也接受未切割的钻石和金币。不幸的是，性能优化比起科学来说更像是一种艺术，并且这比扩展性更难描述。 如果你真想要构建一个大规模的Django应用，你需要花大量的时间和精力学习如何优化构架中的每一部分。以下部分总结了多年以来的经验，是一些专属于Django的优化技巧。RAM怎么也不嫌多最近即使那些昂贵的RAM也相对来说可以负担的起了。 购买尽可能多的RAM，再在别的上面投资一点点。高速的处理器并不会大幅度地提高性能；大多数的Web服务器90%的时间都浪费在了硬盘IO上。 当硬盘上的数据开始交换，性能就急剧下降。 更快速的硬盘可以改善这个问题，但是比起RAM来说，那太贵了。如果你拥有多台服务器，首要的是要在数据库服务器上增加内存。 如果你能负担得起，把你整个数据库都放入到内存中。 这应该不是很困难，我们已经开发过一个站点上面有多于一百万条报刊文章，这个站点使用了不到2GB的空间。下一步，最大化Web服务器上的内存。 最理想的情况是，没有一台服务器进行磁盘交换。 如果你达到了这个水平，你就能应付大多数正常的流量。禁用 Keep-AliveKeep-Alive 是HTTP提供的功能之一，它的目的是允许多个HTTP请求复用一个TCP连接，也就是允许在同一个TCP连接上发起多个HTTP请求，这样有效的避免了每个HTTP请求都重新建立自己的TCP连接的开销。这一眼看上去是好事，但它足以杀死Django站点的性能。 如果你从单独的媒体服务器上向用户提供服务，每个光顾你站点的用户都大约10秒钟左右发出一次请求。 这就使得HTTP服务器一直在等待下一次keep-alive 的请求，空闲的HTTP服务器和工作时消耗一样多的内存。使用 memcached尽管Django支持多种不同的cache后台机制，没有一种的性能可以 接近 memcached。 如果你有一个高流量的站点，不要犹豫，直接选择memcached。经常使用memcached当然，选择了memcached而不去使用它，你不会从中获得任何性能上的提升。 Chapter 15 is your best friend here: 学习如何使用Django的cache框架，并且尽可能地使用它。 大量的可抢占式的高速缓存通常是一个站点在大流量下正常工作的唯一瓶颈。参加讨论Django相关的每一个部分，从Linux到Apache到PostgreSQL或者MySQL背后，都有一个非常棒的社区支持。 如果你真想从你的服务器上榨干最后1%的性能，加入开源社区寻求帮助。 多数的自由软件社区成员都会很乐意地提供帮助。别忘了Django社区。 这本书谦逊的作者只是Django开发团队中的两位成员。 我们的社区有大量的经验可以提供。下一章下面的章节集中在其他的一些Django特性上，你是否需要它们取决于你的应用项目。 可以自由选择阅读。