Python服務器運維筆記：第二章Linux - 1.2.5 nginx代理配置

前言：本文是學習網易微專業的《python全棧工程師》 中的《服務器運維開發工程師》專題的課程筆記，歡迎學習交流。同時感謝老師們的精彩傳授！

一、課程目標

• nginx代理模式
• 簡易集羣
• 代理規則

二、詳情解讀

2.1.nginx代理模式

2.1.1 正向代理

比如我們使用的v,p,n，就是一種代理，通過v,p,n我們就可以一種特別的通道上網。v,p,n的代理模式是正向代理，代理層是透明的。

2.1.2.反向代理

在反向代理中，客戶端只知道代理節點，將請求發給代理節點，由代理節點決定將請求發給哪個服務器節點。

2.1.3.nginx代理模式

nginx作爲web服務器使用時，可以看作是一個文件分發服務器。

2.1.4.nginx反向代理模式

在反向代理模式下，用戶將請求發送到nginx服務器，nginx決定將用戶請求轉發到節點的某一臺服務器節點組成對用戶來講是不透明的，用戶只知道nginx服務器的存在。

當nginx代理請求時，它將請求發送到指定的代理服務器，獲取響應，並將其發送回客戶端。可以使用指定的協議將請求代理到HTTP服務器或非HTTP服務器。
1.代理到HTTP服務器使用Proxy協議。
2.代理到非HTTP服務器支持的協議包括FastCGI，uwsgi，SCGI和memcached。

2.2.proxy代理

2.2.1.節點準備

1.nginx服務器一臺（192.168.3.40）
2.apache web服務器兩臺（192.168.3.41，192.168.3.42）

2.2.2.配置文件

http{
	upstream myservers{
		server 192.168.3.42
		server 192.168.3.43
	}
	server{
		listen 80;
		location /{
			proxy_pass http://myservers;  # 這裏的myservers就是上面定義的 upstream myservers
		}
	}
}

2.3.負載平衡機制

1.循環請求（默認）
nginx按次序，輪流將http請求發送到集羣中的http服務器成員。
缺點：用戶請求帶來的負載是不一樣的，每次請求耗時不同，如果按循環機制來處理負載均衡，會造成有些服務器負載過高，有些則負載過輕。

2.最小連接請求（least_conn)。
每一個請求，實際耗時並不相同，如果按照循環請求機制，可能會造成某些節點服務器實際負載過高，另一些節點實際負載較輕，因此Nginx可以根據連接數來判定，將下一個請求分配給連接數最少的http服務器。

3.持久會話（ip_hash） 【經常使用】
以上兩種機制，不能滿足同一個客戶端多個請求間維持會話的要求基於客戶端的IP，使用ip-hash函數來確定使用哪臺服務器響應客戶端的請求。
說明： 這種機制可以滿足用戶的session。當用戶登錄之後，服務器會給用戶分配一個session，這個session是保存在某一臺服務器上的，另一臺服務器並沒有這個session。如果使用上面的兩種機制，會造成用戶有的登錄，有的非登錄。

4.加權負載
通過weight值指定某臺服務器在集羣中的權重，權重越高，被訪問到機率越高。
說明： 哪臺服務器性能好，就將請求多轉發到這臺服務器上；性能比較低的，就少轉發請求給它。

2.3.1.持久ip_hash示例

upstream myservers {
	ip_hash;
	server 192.168.3.42;
	server 192.168.3.43;
}

三、課程小結

• 01 反向代理
• 02 代理配置
• 03 負載平衡規則