请求调度层的作用是通过截获进入本机的HTTP请求并转发到本地Squid所监听的80端口，然后由Squid程序负责解析请求。Balancer将后台Cache-Pools中所有的SZone定义为父服务器（parent），并使用CARP调度算法进行请求调度。CARP算法是一种URI策略算法，一种确定性的算法,它以每个服务器的状态作为请求分发的前提条件，然后进行均衡的请求转发，并在转发后记录本次分发策略，下次如有同样的请求时会按照这个策略直接分发，而不再进行均衡评估从而节省了分发决策时间，经过实践证明这种分发策略较为适合这个应用环境，它可以带来最大化的命中目标和最小化的目标重复。Balancer层的配置除了CARP算法和服务端口外，其他的使用Squid的通用配置即可。以下是实现CARP算法调度的配置语句：

　　cache_peer zone1 parent 3128 0 carp proxy-only no-query
　　cache_peer zone2 parent 3228 0 carp proxy-only no-query
　　cache_peer zone3 parent 3328 0 carp proxy-only no-query
　　cache_peer zone4 parent 3428 0 carp proxy-only no-query

　　Balancer会定期去检查父服务器的状态：存活或者死亡，当Balancer检测到某个父服务器为死亡状态，那么将不再向其转发请求，直到再次检测其为存活状态后才对其转发请求。这种调度策略体现了均衡性的同时，也有效地避免了单点故障，从而提高了系统的可用性。

　　2. 高可用和弹性扩展的后端缓存池（Cache-Pools）

　　图2中，Cache-Pools中配置有4个SZone，即四个Squid实例，他们分别进行请求响应、原始内容请求、内容缓存等工作。其中SZone-1，SZone-2，SZone-3，SZone-4是相互独立的，即它们分别运行于互相独立的系统用户。之所以设计成多个实例是因为：一是可以解决系统对用户和进程的资源占用限制，从而充分利用硬件资源；二是提高大并发用户情况下的并行处理能力和整体性能；三是增加可扩展性，一旦发现现有的Cache-Pools不能满足实际需求后，可以迅速的配置更多的SZone来缓解负载压力；四是提高可用性，即在某个SZone因为处理异常导致服务崩溃后，其它SZone可以不受影响继续提供服务。也就是说任何一个SZone出现故障，都不会影响其他的SZone进行缓存服务。

　　本文仅用一台服务器承担所有Cache-Pools服务，即将多个实例运行在一个物理服务器和操作系统之上。实际使用环境中，如果需要提高用户容纳量或降低用户等待响应时间，可以适当地增加Cache-Pools的数量，即增加父服务器数量（由于Balancer层资源开销不是很大，无需同比增加）。扩展时可以迁移一部分现有实例到新的物理服务器上，让每个实例拥有更大的内存来响应请求以及更大的磁盘存储空间来缓存更多的对象数据，并且拥有足够的CPU计算时间进行事务处理；假如单台服务器硬件资源充足也可以直接在新的服务器上新建更多的实例，以减轻现有实例的负载，提高服务的稳定性和响应速度。不同的网络和用户环境，SZone的调配基准会有所不同。

　　如上所述，这种以前端调度器和后端缓存池相结合的部署结构充分体现了高可用和弹性扩展的特点：前端调度器以旁路部署的方式接入，可以灵活的控制进入Web缓存服务器的用户量，体现了弹性扩展的特点；而后端缓存池，多个SZone并行且又独立地提供服务，体现了高可用的特点，不仅如此，一旦服务器本身的性能或资源出现瓶颈后，可以简单地通过拆分一部分原有的SZone到其他物理服务器上，或者直接在新的物理服务器上部署新的SZone，同样体现了弹性扩展的特点。