于nginx的url和hash给squid提速的介绍

tyxiayu

　　关于nginx的url和hash给squid提速的介绍，很有用的教程，希望能给您带来帮助。
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

http://wiki.codemongers.com/NginxHttpUpstreamRequestHashModule?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;
    }

    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;
}
return key;
}

然后对生成的key和upstream里的服务器数量做一次求余计算，得到服务器号。

提供hash算法的目的如前所述，是便于后端服务器迅速找到内容对应的squid服务器。

在ngx_http_upstream_hash_module模块里有一个hash_again的标签，可以解决squid意外死机的问题。不过，如果使用了该标签，那么后端的计算对应服务器的方法就会出现错误。可以使用的办法为，提供一台备份的squid服务器，假如有squid死机，那么在nginx里设置error_page 404和502到这台备份服务器，后端刷新缓存时亦要同时刷备份服务器。


另外一种实现url hash的方法：



使用NginxHttpUpstreamRequestHashModule的方式，增加或减少机器时所引起的hash全部错乱的问题还是很令人担心，所以经过一段时间细致思考，觉得由自己手工制定并实现url hash规则，然后利用nginx的location标签或if语法来实现来得更为灵活，可操作性和可用性会大大加强。不过配置就稍显复杂了，也需要程序方面的支持。

使用这种环境，主要需要考虑链接形式，链接形式不能够是/xxx.jsp?id=1这样的带有?的，否则处理起来会很复杂，需要使用rewrite将这种形式的url变化成/1/1.html，其中加一级目录的目的是可以利用到location标签。如果是纯静态页或图片，一般都会有自成的目录规则。

首先我们制定一个链接的划分规则，这个规则有点区别于文件目录的划分规则，它本身并不需要考虑文件夹内文件数目的多少，制定这个规则的目的是容纳足够多的服务器！一般来说，如果id是字符型的，只需要分出26个字母 10个数字，能够容纳36台cache服务器，这已经很足够了。如果是数字型的id，那就拿数字id0，就可以支持100台cache，已经足够夸张。一般说来，，支持10台服务器应该就足够了，配置也容易一点。

有了这个目录规则，就可以通过nginx的语法来书写配置了。

首先制定一堆upstream，如果是偶数，理论能够分得更均衡。




upstream a {
server 127.0.0.1:3121;
}

upstream b {
server 127.0.0.1:3122;
}

#配置一个all的目的是兼容不进行hash的剩余的页面，比如首页
upstream all {
server 127.0.0.1:3121;
server 127.0.0.1:3122;
}

1、已经按/a/划好的，使用location划分

location ~* /a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r/ {
proxy_pass http://a;
}

location ~* /s|t|u|v|w|x|y|z|0|1|2|3|4|5|6|7|8|9|0/ {
proxy_pass http://b;
}

location / {
proxy_pass http://all;
}

2、已经有一定链接规则，不想变化，可以使用if语句判断

location / {
proxy_pass http://all;
if  ( $request_uri ~* /page_(a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r)/ ) {
proxy_pass http://a;
}
if  ( $request_uri ~* /page_(s|t|u|v|w|x|y|z|0|1|2|3|4|5|6|7|8|9|0)/ ) {
proxy_pass http://b;
}
}

在新增服务器后，需要改动配置，手工将一些目录规则的文件分出去，剩下的仍然访问原先的服务器，不会造成太严重影响。

在这种配置下，像首页这样的访问量大的单页，它访问量大，容量小，所以不可能产生容灾问题。使用轮循的方式工作，会比原先分到死定一台cac