url hash是用于提高squid命中率的一种架构算法，一般现行的架构通常是使用dns轮询或lvs等将访问量负载均衡到数台squid，这样做可以使squid的访问量做到了均衡，但是忽略了一个重要方面--数据量。在这种架构下，每台squid的数据量虽然是一致的，但通常都是满载，并且存在数据重复缓存的情况。如果后端服务器数据容量或者用户的访问热点数远远超过缓存机器的内存容量，甚至配置的disk cache容量，那么squid将会大量使用磁盘或者不停与后端服务器索取内容。
在新的架构下，使用nginx架载于squid之前，如果squid机器有4台，那么在这4台机器上装上nginx，nginx使用80端口，而squid改为3128端口或其他端口。nginx的效率非常高，消耗内存也非常少，所以并不需考虑加装nginx所带来的性能损耗。然后在nginx上配置url hash，使访问量根据url均衡分布到各台squid，根据url分流之后，每一个url就会只存在于一台squid中，每台squid的数据都会完全不同。我们有4台机器，每台2G内存的话，原先极有可能因为数据大量重复，内存使用率仍然为2G，而现在我们经过数据均衡分布，8G内存可以达到充分利用。
是否会存在访问不均的情况呢？是有可能的，但是根据大数原理，访问量基本可以保持一致，只要不存在单一的特别夸张的热点。
假如squid是利用squidclient来刷新数据的话，新的架构提供了更高效的方法：在后端服务器中模拟url hash的算法来找到内容所在的squid，然后对此服务器刷新内容即可。在旧的架构中，需要遍历所有的服务器，比较低效。
具体配置如下：
nginx本身并没有提供url hash功能（暂时），需要安装第三方模块ngx_http_upstream_hash_module
?action=AttachFile&do=get&target=nginx_upstream_hash-0.2.tar.gz
cd nginx-0.5.xx
patch -p0 < /path/to/upstream/hash/directory/nginx-0.5.xx.patch
./configure时加上参数
--add-module=path/to/upstream/hash/directory
make; make install
完成安装
配置：
在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法
upstream backend {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}
hash算法可以使用crc32和默认的simple，在Java中可利用java.util.zip.CRC32类实现，simple算法的C语言实现如下
#define ngx_hash(key, c) ((u_int) key * 31 c)
u_int ngx_hash_key(u_char *data, size_t len)
{
u_int i, key;
key = 0;
for (i = 0; i < len; i ) {
key *= 31;
key = data[i];
}
return key;
}
java代码（随手写未测试）：
public static long getSimpleHash(String data)
{
long key = 0;
char[] chars = data.toCharArray();
for (int i=0; i key *= 31;
key = (int) chars[i];
}
return key;
}
然后对生成的key和upstream里的服务器数量做一次求余计算，得到服务器号。
提供hash算法的目的如前所述，是便于后端服务器迅速找到内容对应的squid服务器。
在ngx_http_upstream_hash_module模块里有一个hash_again的标签，可以解决squid意外死机的问题。不过，如果使用了该标签，那么后端的计算对应服务器的方法就会出现错误。可以使用的办法为，提供一台备份的squid服务器，假如有squid死机，那么在nginx里设置error_page 404和502到这台备份服务器，后端刷新缓存时亦要同时刷备份服务器。