负载均衡缓存服务器只需要保留数据的一小部分
这时，你可能会奇怪，到底为什么需要映射一个特定的URL到一台特定的真实服务器。这是个合理的问题，而且答案并非显而易见，考虑如所示的设置。
假定某个大型的后台存储器上有需要提供给客户的文件。我们当然可以选择直接从磁盘上提供，但磁盘速度缓慢，而且我们打算每 秒服务大量请求，因此需要Squid这样的缓存代理（本章末会讨论这个）来缓存需要服务的文件。一旦文件工作集合增大了，就需要增加另一台缓存服务器或很 多缓存服务器来应付负载。缓存服务器只需要保留数据的一小部分在内存中和小而快速的磁盘上，就可以让整体速度较快。
如 果使用的是第四层的负载平衡器，那么请求会散布在全部的缓存服务器上，负载均衡看起来一切都很好。真的么？如果现在工作集很大，那么我们会逐渐把一些内容移出缓 存，或者至少从内存缓存中移除它们。增加更多服务器的目的也是增加在线缓存的大小。实践结果表明，在每个缓存中的内容都大同小异——最 经常被请求的文件被请求很多很多次，其中部分请求发向第一台缓存服务器，部分请求发向第二台服务器，依此类推。这意味着即使有五台缓存服务器，实际上也可 能没有存放任何额外的对象——所有的缓存服务器都包含相同的内容，这是对空间的浪费。
使用第七层负载平衡时，就可以使单个对象只存在于一台缓存服务器上，负载均衡确保所有的缓存都是完全唯一的（不考虑一台机器出故障 时的故障转移语义）。这样能充分利用所有可用的缓存空间，能同时把更多的数据缓存起来。这提高了缓存命中率，并且能够服务的请求数目远胜从前，因为不在缓 存中，因而需要到磁盘上去获取的对象更少了。
使用Apache的mod_rewrite，再加上一些脚本，就能实现第七层的负载平衡。把一个Apache实例设置成负载平衡器，就可以通过一个脚本来路由所有的请求。
RewriteEngine on
RewriteMap balance prg:/var/balance.pl
RewriteLock /var/balance.lock
RewriteRule ^/(.*)$ ${balance:$1} [P,L]
每个抵达负责负载平衡的Apache实例的请求，都被传递给了/var/balance.pl脚本，负载均衡由这个脚本决定把请求均衡到哪儿。mod_rewrite接着在proxy模式（P选项）下重写URL。如果不考虑池中的服务器是正常运行还是当机，那么可以用非常简单的一个Perl脚本实现基负载均衡于URL的均衡：
#!/usr/bin/perl -w
use strict;
use String::CRC;
$|++;
my @servers = qw(cache1 cache2 cache3);
while () {
my $crc = String::CRC::crc($_, 16);
my $server = $servers[$crc % scalar @servers];
}
Apache启动后，该脚本被执行，然后就一直接收需要重写的URL。String::CRC模块为每个URL计算循环冗 余校验码（CRC），这个过程非常快（这个模块是用C语言写的），并且对于相同的字符串总是给出相同的结果。接着使用计算出来的CRC的值从后台机器列表 中选择一台服务器。
经过稍许努力，就可以加入一个数据库查找或者缓存查找，每几秒检查一次后台服务器的状态，或者向每台服务器依次执行HTTP请求，以检查其是否可用，当第一个选择不可用的时候，返回列表中的下一台服务器（或者采用其他某种算法）。
把代理作为后台服务器的一部分运行并不是一个明智的选择，因为Apache往往有很“厚重”的线程，而且对每台后台服务器 的每个当前请求，负载平衡器都要保持一个线程处于打开状态。作为替代方案，可以运行一个最小化的Apache实例，只加载必需的模块（这里是 mod_rewrite和mod_proxy），减小每个线程的体积。还有一种方案，是在某台后端服务器上运行两个Apache实例来运行这个负载平衡代 理，一个在端口80上，用于负载平衡，另一个在不同的端口上（比如81），用于内容服务。
使用Apache作负载平衡器还有一个缺点——运行它的机器会成为独立的故障点。要解决这个问题，可以在多个Apache 负载平衡器前端使用一个专用的平衡硬件设备，在多台Apache负载平衡器之间使用DNS负载平衡，或者在操作系统层级，使用某种灵活的IP故障转移软 件。
相关信息