为什么需要 面向CacheServer的基于Object的Load Balance？
首先定义几个符号：
M 一个域名下所有内容的总字节数
Hot(M) 一天内被访问到的每一个不同Object的字节数加和
C 单台CacheServer的CacheDisk的总字节数
问题：当 Hot(M) > C 的时候，会出现什么样的后果？
答案：CacheServer在一天内的平均命中率将降低为 C/Hot(M)*100%
问题：当出现 Hot(M) > C 的时候，怎么办？
答案：
1. 将 M 平均拆分为多个域名，用多组CacheServer服务不同域名
2. 扩充 CacheDisk 提高 C
3. 使用面向CacheServer的基于Object的Load
Balance
面向CacheServer的基于Object的Load Balance的实现
简单可行的方案：基于Object Hash(Url)的Load Balance方案：Lighttpd+Squid
Lighttpd的mod_proxy可以实现基于Hash(Url)的负载均衡规则
采用Lighttpd架在Squid前面的这种链式结构会导致Squid在日志中无法记录真实的客户端IP地址，但是Squid
Dev Team设计了一个X-Forwarded-For的HTTP
Header，但是Customlog实现上有点小问题，不方便记录这个Header的值，因此需要对Squid进行一下Patch工作。
同时Lighttpd也有个小问题，不能把用户端传入的X-Forwarded-For传递给Squid，因此也需要做一下Patch工作。
X-Forwarded-For Header不属于RFC标准，最初是由Squid Development
Team建议，我在squid follow_xff patch的文档中找到一段文字：
Allowing or Denying the X-Forwarded-For header
to be followed to
find the original source of a request.
Requests may pass through a chain of
several other proxies before reaching us.
The X-Forwarded-For header will
contain a comma-separated list of the IP addresses in the
chain, with the rightmost address being the most
recent.
