squid请求处理流程（源站故障转向研究）的方法
第一，当然还是修改源代码，这个C++可惜俺不懂，只是大略的通过百大哥谷大婶知道了squid的请求处理流程：
客户端和squid建立连接（client-side模块、clientBeginRequest()函数）；
检查ACL访问控制；
检查重定向；
检查缓存命中（GetMoreData()函数），写入StoreEntry（client-side模块）； 4.1. 命中（client-side模块）； 4.2. 未命中（rotoDispatch()函数启动peer算法，算法检查never|always_direct）；
收到ICP响应，选择中止，转发请求（protoStart()函数）；
打开到源站或peer的连接（HTTP模块），发起请求（Network Communication模块），建立连接并处理异常（comm.c程序）；
建立写缓存（HTTP模块），将请求写入socket；
建立相应的socket读缓存，接受处理HTTP响应（即，如果已有socket，可以跳过6、7步）；
响应被接受，squid接收到header信息，并在被读取时把data追加进StoreEntry，同时通知client-side模块，这个过程的速度取决于delay_pools；
client-side模块从StoreEntry取数据，并写入客户端socket；
客户端读取完成，数据根据情况（refresh、cache）存入磁盘；
回源取完数据，标记StoreEntry为“完成”（client-side模块），socket关闭或保留到持久连接池；
数据写入客户端socket完成，从StoreEntry注释掉client-side模块，同样，关闭或等待客户端连接请求。
原先的想法就是在第3步，而缓存在第4步，所以不行。也就是说，必须在第4步以后操作，才能不影响CDN的命中率。很显然，我注意到一个词，第6步中“建立链接并处理异常”的comm.c程序；其次，第9步“响应被接受”，也就是说，可能建立链接但没响应，这里就应该是socket的存活过期时间来决定。
思路到此为止，往下就是编程开发能力的事儿了，哭ing~~
第二个办法，还在squid本身上做文章。我注意到，处理流程的4.2步上，squid是同时检查源站和cache_peer的。那么，在源站故障的时候，cache_peer可以设成其他服务器顶上。这样的情况，不单解决一个url跳转，还能做一个源站备份。
配置如下：
第一句的意思，就是当originserver挂了，不可层叠的请求（即hierarchy_stoplist定义的）就“可能”发往其他peer。
第二句的意思，就是所有优先originserver，只有挂了以后才去peer，这个配置针对的可cache的请求。
不过两句加起来，还有那些不再hierarchy_stoplist定义又不cache的（没实验，不知道这个可cache是指squid配置还是包括origin的header设置），可就没办法了，也不全面。