5.2 高可用弹性扩展的实现架构

　　由于校园网的最大并发为4000-5000人，网络压力相对较大，考虑到为确保缓存服务系统的性能和稳定性，使用一个Cache服务器显然不能满足以上需求，同时随着校园网用户数的不断增加、网络需求量地提高，需要考虑一定的扩展性。因此，整个系统中部署了两台服务器，分别规划为Balancer和Cache-Pools，如图4所示，Balancer上面运行了一个Squid实例，主要用做请求调度，其本身并不缓存任何对象。而Cache-Pools运行了4个Squid实例（简称SZone），分别服务在3128，3228，3328，3428等端口，接受并处理来自Balancer转发来的请求，提供并发的缓存服务。

图4 Web缓存服务器群架构

　　 这种部署结构的优点是，一旦Cache-Pools服务器本身的性能或资源出现瓶颈后，可以灵活地通过拆分一部分原有的Szone到其他物理设备上，或者直接在新的物理设备上部署新的SZone即可实现负载均衡，提供了平滑无缝隙的拓展功能。

　　5.3 前置调度器

　　5.3.1 工作原理

　　Balancer前置调度器有两种部署方式，一是串联在现有的网络中，位置通常是内网数据包到达出口路由器/网关前的位置；或者是旁路部署在出口路由/网关处。两种不同的部署方式在Balancer的调度方式是相同的，区别在于数据包进入Balancer的方式不同，前者是主动流入；后者为被动流入，具有更灵活的伸缩性。后者需要在路由器/网关配置路由转发策略，使来自内网到任意地址的http请求数据包都路经Balancer(Cisco公司的IOS系统已经支持WCCP协议，也可以通过WCCP来进行这个转发)。根据实际应用环境的特点，本应用是将前置调度器以旁路方式部署在出口。

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

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