高性能Web服务器Nginx的配置与部署研究(11)应用模块之Memcached模块的两大应用场景

晨曦之光 发布于 2012/04/24 14:47
阅读 138
收藏 0

本文来自:CSDN博客专栏《Nginx高性能Web服务器》 及Poechant技术博客,转载请注明出处。

一、应用场景1

(转载请注明:http://blog.csdn.net/poechant/article/details/7176921

最近在一个项目中,用到了Nginx的Memcached模块,所以就在这个系列教程中提前把Memcached模块拿出来写了。另外发现最近我的博客文章频频被很多用采集器的网站拿走,帮我发扬光大,都不听我说声谢谢。在此还是希望我的博文被转载的时候能够被注明出处,满足下我小小的虚荣心。


现在有这样一种应用场景:

客户端Client通过Nginx反向代理,访问服务器Server。每次访问的内容就是将文件File传到Server上,然后可以访问到File的URL被广播到所有Client上,每个Client再加载File。


(转载请注明:http://blog.csdn.net/poechant/article/details/7176921


Analysis:

这么多Client同时加载File,对Server的压力一定很大吧?读者朋友肯定会说,有了Nginx反向代理,Client访问Server的时候,相应访问的资源就可以被Nginx缓存,减轻了Server的压力。但有一点要注意,如果这样的话,Nginx反向代理配置的缓存是在有Client访问到Nginx时才会从Server拿来缓存到Nginx上。可是广播后,所有Client加载File是同时的,如果等地一个访问请求到来并使得Nginx产生缓存后,其他Client接收到广播后的加载响应,恐怕早已经发起并且接近尾声了。负载压力还是落到Server上。怎么办呢?


Solution Overview:

某个Client上传File到Server的同时,将File内容写入到Nginx的缓存中,然后广播后,Client加载File的请求在到达Nginx时去缓存中查找,那么基本是100%命中。


Deployment Solution:

(1)Reverse-Server(192.168.0.1):反向代理服务器,用Nginx实现。对外提供11000端口,接收到HTTP请求后到Cache-Server的14000端口的缓存服务中查找,如果有则返回,如果没有则将请求传递给Store-Server的12000端口。

(2)Store-Server(192.168.0.2):文件存储服务器,用FastDFS实现。对外提供12000端口用于下载,接收来自Reverse-Sever的HTTP请求。对外还提供12500端口用于上传。

(3)Process-Server(192.168.0.3):业务处理服务器,对外提供13000端口,接收Client传递来的File,并将File通过Store-Server的12500端口转储到Store-Server中。

(4)Cache-Server(192.168.0.4):文件缓存服务器,用Memcached实现,对外提供14000端口。接收来自Reverse-Server的读操作,和Process-Server的写操作。


(转载请注明:http://blog.csdn.net/poechant/article/details/7176921


Configuration Solution:

(1)FastDFS的配置与部署,请参见GoogleCode上的FastDFS相关wiki。

(2)Memcached部署很简单,wget,tar,./configure,make,make install就OK了。

(3)Process-Server是由我自己实现的,不具有通用性就不说了。

(4)Reverse-Server的Nginx配置文件中http模块中,建立一个用户解决该问题的server,配置方式如下:

server {
	listen 11000;
	server_namelocalhost;

	default_typetext/html;
	
	location / {
		proxy_set_headerX-Real-IP $remote_addr;
		proxy_set_headerHost $http_host;
		proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;
		
		if ($request_method = POST) {
			proxy_pass http://192.168.0.2:12000;
			break;
		}

		set $memcached_key	"$uri";
		memcached_pass		192.168.0.4:14000;

		error_page	501 404 502 = /fallback$uri;
	}

	location /fallback/ {
		internal;

		proxy_set_header	X-Real-IP	$remote_addr;
		proxy_set_header	Host		$http_host;
		proxy_set_header	X-Forwarded-For	$proxy_add_x_forwarded_for;

		proxy_redirect		off;

		proxy_pass		http://192.168.0.2:12000
	}
}

(转载请注明:http://blog.csdn.net/poechant/article/details/7176921


Details

Nginx的Memcached模块只提供对Memcached的读操作,不提供写操作。如果Memcached中没有相应的键值,即未命中,则返回404。如果请求未能找到Memcached Server,则返回502错误。因此,我们可以采用这样一种方式:当返回这类错误时,将请求交给Store-Server。这样只有在不命中时才访问Store-Server,缓存服务器由此可以为存储服务器分担很多负载。



二、应用场景2


在应用场景1中,将不命中时的逻辑换作向Memcached的写操作。这种场景的服务器系统部署方案如下:


(1)Reverse-Server:Client访问该服务器的11000端口,请求被转至Cache-Server的14000端口,如果Cache-Server命中则response;否则交给Process-Server的13000端口,进行进一步的处理。

(2)Data-Server:对外提供12000端口,用于读取数据。

(3)Process-Server:提供13000端口,用于接收Reverse-Server转发来的HTTP请求,到Store-Server的12000端口查询,并将得到的Value与从Reverse-Server发来的Key值共同构成K-V对,通过Cache-Server的14000端口写入Cache-Server。

(4)Cache-Server:提供14000端口,用于对外提供读写操作。


这是的Nginx的Memcached模块配置,要将request的方法为post和error_log,不再是如“应用场景1”中那样转至Store-Server,而是都转至Process-Server去。因为应用场景1中,向Cache写的操作,是预先完成的。而应用场景2中向Cache写的操作,是在读Cache失败后发生的。注意这两者适用的业务需求。


今天就写到这里,太晚了,该休息了。

本文来自:CSDN博客专栏《Nginx高性能Web服务器》 及Poechant技术博客,转载请注明出处。

-


原文链接:http://blog.csdn.net/poechant/article/details/7176921
加载中
返回顶部
顶部