高效能Web伺服器Nginx的配置與部署研究（11）應用模組之Memcached模組的兩大應用場景...

本文來自：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技術部落格，轉載請註明出處。

-