在新的架构下,使用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.z ip.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到这台备份服务器,后端刷新缓存时亦要同时刷备份服务器。
另外一种实现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;
}
}
在新增服务器后,需要改动配置,手工将一些目录规则的文件分出去,剩下的仍然访问原先的服务器,不会造成太严重影响。
在这种配置下,像首页这样的访问量大的单页,它访问量大,容量小,所以不可能产生容灾问题。使用轮循的方式工作,会比原先分到死定一台cache,在可用性上要好得多。