高效能Web伺服器Nginx的配置與部署研究（13）應用模組之Memcached模組+Proxy_Cache雙層快取模式...

本文來自：CSDN部落格專欄《Nginx高效能Web伺服器》及Poechant技術部落格，轉載請註明出處。

通過《高效能Web伺服器Nginx的配置與部署研究——（11）應用模組之Memcached模組的兩大應用場景》一文，我們知道Nginx從Memcached讀取資料的方式，如果命中，那麼效率是相當高的。那麼：

（轉載請註明來自Poechant的CSDN部落格：http://blog.csdn.net/poechant/article/details/7179891）

1. 如果不命中呢？

我們可以到相應的資料伺服器上讀取資料，然後將它快取到Nginx伺服器上，然後再將該資料返回給客戶端。這樣，對於該資源，只有穿透Memcached的第一次請求是需要到資料伺服器讀取的，之後在快取過期時間之內的所有請求，都是讀取Nginx本地的。不過Nginx的proxy_cache是本地硬碟快取，效率要遠低於Memcached。

2. 應該如何安裝和配置呢？

（1）HttpMemcModule模組

如果使用Nginx的非核心模組——HttpMemcModule模組，則可以下載模組：

http://github.com/agentzh/memc-nginx-module/tags

michael@dev-machine:~$ tar -zxvf agentzh-memc-nginx-module-a0bc33a.tar.gz
michael@dev-machine:~$ tar -zxvf nginx-1.1.12.tar.gz
michael@dev-machine:~$ cd nginx-1.1.12
michael@dev-machine:~$ ./configure --add-module=/home/michael/agentzh-memc-nginx-module-a0bc33a
michael@dev-machine:~$ sudo make
michael@dev-machine:~$ sudo make install

目前驗證發現Nginx 1.0.10版本Nginx的1.1.3及其之前的版本，需要額外通過--add-module來載入upstream-keepalive模組，請自行google之。其他版本還不確定，猜測是在1.1 從nginx的1.1.4及其之後的版本開始，自動攜帶upstream-keeplive模組的。 （感謝agentzh的提示）

（轉載請註明來自Poechant的CSDN部落格：http://blog.csdn.net/poechant/article/details/7179891）

然後我們來編輯配置檔案吧。如下：

http {
	...
	upstream data_server {
		server	192.168.0.133:1234;
		server	192.168.0.134:1234;
		server	192.168.0.135:1234;
		ip_hash;
	}

	upstream memc_backend {
		server	127.0.0.1:11211;
	}
	...
	server {

		listen		8080;
		server_name	localhost;

		default_type	text/html;

		location / {
			set		$memc_cmd	get;
			set		$memc_key	$uri;
			memc_pass	memc_backend;

			error_page	404 @fallback;
		}

		location @fallback {

			internal;

			proxy_pass		http://data_server;

			proxy_cache		cache_one;
			proxy_cache_valid	200 302 1h;
			proxy_cache_valid	301 1d;
			proxy_cache_valid	any 1m;
			expires			30d;
		}
	}
	...
}

從上面的配置檔案我們可以看出，一個請求到達後，會其uri作為key去Memcached伺服器127.0.0.1:11211上查詢value，如果沒有命中，則返回404。這時通過error_page將404接收轉到@fallback，然後去data_server中取檔案，取完後將該檔案在本地磁碟快取，同時使用者的瀏覽器也通過expires設定快取時間。

這樣絕大多數請求如果被第一層Memcached的記憶體快取攔截的話，剩餘的請求可以通過訪問第二層Nginx伺服器的硬碟快取檔案，來減少穿透。

按照上面的方式，客戶端得到的請求響應中雖然包含了正確的檔案內容，但狀態碼都是404（可以通過Fiddler來觀察）。這似乎會引起問題。什麼問題呢？絕大多數瀏覽器，即使在404的情況下，也會嘗試去讀取內容，如果有正確的內容，是可以正確顯示的。但是比較常見的可能引起問題的兩種情況是：

（a）、搜尋引擎的spider爬到的404時，一般不會收錄該URL，我想這不是你所希望看到的；

（b）、Flash等方式載入時，如果頭是404，可能不予顯示，我想著也不是你所希望看到的。

（轉載請註明來自Poechant的CSDN部落格：http://blog.csdn.net/poechant/article/details/7179891）

那我們把它改成都是200，是不是很好呢？

error_page	404 =200 @fallback;

非也，這樣404傳遞到fallback處理請求後的狀態如果不是200，就很不一致了，會引起更多問題。所以應該如下配置：

error_page	404 = @fallback;

這樣fallback的處理結果狀態是什麼，就用什麼替換404。

（2）Nginx內部的Memcached模組

如果你想使用Nginx內部的Memcached模組，配置檔案可以結合參考上面的示例和《高效能Web伺服器Nginx的配置與部署研究——（11）應用模組之Memcached模組的兩大應用場景》

（轉載請註明來自Poechant的CSDN部落格：http://blog.csdn.net/poechant/article/details/7179891）

本文來自：CSDN部落格專欄《Nginx高效能Web伺服器》及Poechant技術部落格，轉載請註明出處。

-