A. nginx 支持一致性hash嗎
ngx_http_upstream_consistent_hash 模塊是一個負載均衡器，使用一個內部一致性hash演算法來選擇合適的後端節點。與php的memcache模塊memcache.hash_strategy兼容，這意味著可以使用php-memcache模塊將內容存儲到memcached集群中，而後通過nginx在集群中找到值。
該模塊通過使用客戶端信息(如：$ip, $uri, $args等變數)作為參數，使用一致性hash演算法將客戶端映射到後端節點。
該模塊可以根據配置參數採取不同的方式將請求均勻映射到後端機器，比如：
consistent_hash $remote_addr：可以根據客戶端ip映射
consistent_hash $request_uri： 根據客戶端請求的uri映射
consistent_hash $args：根據客戶端攜帶的參數進行映射
指令
語法：consistent_hash variable_name
默認值：none
上下文：upstream
配置upstream採用一致性hash作為負載均衡演算法，並使用配置的變數名作為hash輸入。
安裝
1
2
3
4
5
# wget https://github.com/replay/ngx_http_consistent_hash/archive/master.zip
# unzip master.zip
# ./configure --add-mole=./3thparty/ngx_http_consistent_hash-master
# make
# make install
例子
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
upstream somestream {
consistent_hash $request_uri;
server 10.50.1.3:11211;
server 10.50.1.4:11211;
server 10.50.1.5:11211;
}
...
server {
listen 80;
server_name localhost;
location / {
default_type text/html;
set $memcached_key $request_uri;
memcached_pass somestream;
error_page 500 404 405 = @fallback;
}
location @fallback {
root /srv/www/whatever;
fastcgi_intercept_errors on;
error_page 404 = @404;
set $script $uri;
set $path_info "";
include /usr/local/nginx/conf/fastcgi_params;
fastcgi_param SCRIPT_FILENAME /srv/www/whatever/test.php;
fastcgi_param SCRIPT_NAME $script;
fastcgi_param REQUEST_URI $uri;
fastcgi_pass 127.0.0.1:9000;
}
}
B. Nginx運行原理和配置詳解（個人總結筆記）
話不多說，擼起鍵盤就是干！正所謂知其然知其所以然，個人總結了下Nginx運行原理和配置詳解，便於理解和後續復盤。
先來看這一張圖。
nginx啟動後會有 一個master進程和多個worker進程 。master進程用來管理worker進程， 一個worker進程處理一個請求 ，一個請求，只可能在一個worker進程中處理，一個worker進程，不可能處理其它進程的請求。 worker進程的個數是可以設置的，一般我們會設置與機器cpu核數一致 ，這裡面的原因與nginx的進程模型以及事件處理模型是分不開的 ，過多的worker數，只會導致進程來競爭cpu資源，從而帶來不必要的上下文切換。
PHP WEB伺服器目前最佳方式之一就是： Nginx + FastCGI（解決CGI並發重復fork問題） + PHP-FPM（管理PHP-CGI進程） 。nginx是怎麼做到把請求拋給PHP解釋來處理的呢？這個過程又是怎麼實現的呢？稍後我們來看一下參數配置。
代理，反向代理，負載均衡是Nginx常用功能。
Http代理，反向代理：作為web伺服器最常用的功能之一，尤其是反向代理。如果你和小馬之前一樣還是分不清代理和反向代理的區別，下面這個圖對理解會有所幫助。
它們的區別就是，前者知道我要找的人並知道地址在哪，代理伺服器按這個地址代為請求一下然後把他說的話返回給我。後者就是，我知道我要找誰問話但不知襲沖道地址在哪，我也襪弊不想管，代理服務你自己去找，只要幫我返回他要說的話就可以了。
負載均衡：其實也是 反向代理 的一種。負載均衡，熱備等等其實都屬於高可用范疇，Nginx提供的負載均衡策略有2種：內置策略和擴展策略。內置策略為 輪詢，加權輪詢，Ip hash 等等。擴展策略，就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負載均衡演算法，給他做下實現。思考一個問題，IP hash真的能解決session共享的問題么？
我們來簡單看下兩個 配置示例 。
這個配置將請求轉發轉向mysvr 定義的伺服器列表。 注意proxy_pass配置。其實這塊也是負載均衡的配置 。如下：
在訪問網站時，由於配置了proxy_pass地址，所有請求都會先通過nginx反向代理伺服器，在伺服器將請求轉發給目的主機時，讀取upstream為 tomcatsever1的地址，讀取分發策略，配置tomcat1權重為3，所以nginx會告禪族將大部分請求發送給49伺服器上的tomcat1，也就是8080埠；較少部分給tomcat2來實現有條件的負載均衡，當然這個條件就是伺服器1、2的硬體指數處理請求能力。
負載均衡配置 還有其他的相關參數，這是只是打個樣，不贅述。
可以認為fastcgi_pass這個配置非常關鍵，將Nginx + FastCGI + PHP-FPM串連 。這個配置將PHP請求都交給 fastcgi_pass配置的PHP-FPM處理。 location分別通過正則過濾和轉發配置決定了各個請求URL將要轉發交與的處理方式 ，location /表示默認請求，location ~\.php(.*)$ 表示PHP 腳本請求全部轉發到 FastCGI處理。 使用FastCGI默認配置.。
以上配置指定了這些 靜態文件要nginx自己處理 。
NGINX負載均衡可以用於很多服務負載均衡的實現，比如做Redis服務的負載均衡，配置upstream的IP列表再配置 proxy_pass 代理即可。那要實現負載均衡除了NGINX，還有哪些呢？
根據7層OSI模型可將負載均衡分為 ：
1）二層負載均衡（一般是用虛擬mac地址方式，外部對虛擬MAC地址請求，負載均衡接收後分配後端實際的MAC地址響應）；
2）三層負載均衡（一般採用虛擬IP地址方式，外部對虛擬的ip地址請求，負載均衡接收後分配後端實際的IP地址響應）；
3）四層負載均衡（在三次負載均衡的基礎上，用 ip+port 接收請求，再轉發到對應的機器）；
4）七層負載均衡（根據虛擬的url或是IP，主機名接收請求，再轉向相應的處理伺服器）。
這其中，最常見的是四層和七層負載均衡。思考一下，NGINX的負載均衡是屬於哪一種？
關於負載均衡的架構
C. 不容錯過的Nginx配置詳解，一文帶你搞懂Nginx
Nginx是一個高性能的HTTP和反向代理伺服器，特點是佔用內存少，並發能力強，事實上Nginx的並發能力確實在同類型的網頁伺服器中表現好。Nginx專為性能優化而開發，性能是其最重要的考量，實現上非常注重效率，能經受高負載的考驗，有報告表明能支持高達50000個並發連接數。
需要客戶自己在瀏覽器配置代理伺服器地址。
例如：在大陸訪問www.google.com，我們需要一個代理伺服器，我們通過代理伺服器去訪問谷歌，這個過程就是正向代理。
反向代理，客戶端對代理是無感知的，因為客戶端不需要任何配置就可以訪問，我們只需要將請求發送到反向代理伺服器，由反向代理伺服器去選擇目標伺服器獲取數據後，在返回給客戶端，此時反向代理伺服器和目標伺服器對外就是一個伺服器，暴露的是代理伺服器地址，隱藏了真實伺服器IP地址。
單個伺服器解決不了，我們增加伺服器的數量，然後將請求分發到各個伺服器上，將原先請求集中到單個伺服器上的情況改為將請求分發到多個伺服器上，將負載分發到不同的伺服器，也就是我們說的負載均衡。
為了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的伺服器來解析，加快解析速度。降低原來單個伺服器的壓力。
進入到下面的目錄，然後使用命令
配置文件所在位置：/usr/local/nginx/conf/nginx.conf
由全局塊+events塊+http塊組成
從配置文件開始到events之間的內容，主要會設置一些影響Nginx伺服器整體運行的配置指令，主要包括配置運行Nginx伺服器的用戶（組）、允許生成的worker process數，進程pid存放路徑、日誌存放路徑和類型以及配置文件的引入等。
events塊設計的指令主要影響Nginx伺服器與用戶的網路連接，常用的設置包括是否開啟對多work process下的網路連接進行序列化，是否允許同時接收多個網路連接，選取哪種事件驅動模型來處理連接請求，每個work process可以同時支持的最大連接數等。下面的例子表示每個work process支持的最大連接數為1024。這部分配置對Nginx的性能影響較大，在實際中應該靈活配置。
Nginx伺服器配置中最頻繁的部分，代理、緩存和日誌定義等絕大多數功能和第三方模塊的配置都在這里，http塊又包括http全局塊和server塊。
http全局塊配置的指令包括文件引入、MIME-TYPE定義、日誌自定義、連接超時時間、單鏈接請求數上限等。
這塊和虛擬主機有密切關系，虛擬主機從用戶角度看，和一台獨立的硬體主機是完全一樣的，該技術的產生是為了節省互聯網伺服器硬體成本。
每個http塊可以包括多個server塊，而每個server塊就相當於一個虛擬主機。
每個server塊也可以分為全局server塊，以及可以同時包含多個location塊。
最常見的配置時本虛擬主機的監聽配置和本虛擬主機的名稱或IP配置。
一個server塊可以配置多個location塊。
這塊的主要作用是基於Nginx伺服器接收到的請求字元串（例如server_name/uri-string），對虛擬主機名稱（也可以是IP別名）之外的字元串（例如前面的/uri-string）進行匹配，對特定的請求進行處理。地址定向、數據緩存和應答控制等功能，還有許多第三方模塊的配置也在這里進行。
訪問http://ip，訪問到的是Tomcat的主頁面http://ip:8080。
Nginx+JDK8+Tomcat
訪問：http://192.168.71.167/，看到的是Tomcat的首頁。
根據訪問的路徑跳轉到不同的伺服器中去。
訪問http://ip:9001/e 直接跳到http://127.0.0.1:8080/e
訪問http://ip:9001/vod 直接跳到http://127.0.0.1:9090/vod
Nginx+JDK8+配置兩個Tomcat，Tomcat的配置不再講述。
訪問http://192.168.71.167:9001/e/a.html跳到了http://127.0.0.1:8080/e/a.html頁面。
訪問http://192.168.71.167:9001/vod/a.html跳到了http://127.0.0.1:9090/vod/a.html頁面。
假如Nginx代理伺服器Server的配置為：192.168.71.167:9001，跳到：127.0.0.1:8080，訪問者的IP為：192.168.71.200:20604。
通過訪問http://192.168.71.167/e/a.html，實現負載均衡的效果，平均分攤到8080和8081埠中。
Nginx+JDK8+2台Tomcat，一台8080，一台8081。
訪問：http://192.168.71.167/e/a.html，8080和8081交替訪問。
1 輪詢（默認）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。
2 weight
weight代表權重，默認為1，權重越高被分配的客戶端越多。
指定輪詢幾率，weight和訪問比率成正比，用於後端伺服器性能不均的情況。
3 ip_hash
每個請求按訪問IP的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題，示例如下：
4 fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
訪問圖片：http://192.168.71.167/image/1.jpg
訪問頁面：http://192.168.71.167/www/a.html
訪問目錄：http://192.168.71.167/image/（因為設置了autoindex on;）
兩台機器，每台機器都裝有keepalived+Nginx+Tomcat。
主備keepalived伺服器中只有master一台機器會出現VIP地址，否則會出現腦裂問題。
【提示】腳本要加+x的執行許可權：chmod +x chk_nginx.sh
在Nginx里把虛擬IP配置進去即可。
一個Nginx是由一個master進程和多個worker進程組成的。
客戶端發送請求到Master，然後給worker，再由這些work爭搶處理這個請求。
1 可以使用nginx -s reload進行熱部署方式；
2 每個worker是獨立的進程，如果有其中的一個worker出現了問題，其他worker獨立的繼續進行爭搶，實現請求的過程，不會造成服務的中斷；
Nginx和Redis類似，都採用了io多路復用機制。每個worker進程都可以把CPU發揮到極致，一般來說worker數和伺服器的CPU數相等是最為適宜的。
發送請求：訪問靜態資源佔用2個連接，反向代理佔用4個連接。
【溫馨提示】
D. nginx 負載均衡之一致性hash，普通hash
哈希負載均衡原理
ngx_http_upstream_hash_mole支持普通的hash及一致性hash兩種負載均衡演算法，默認的是普通的hash來進行負載均衡。
nginx 普通的hash演算法支持配置http變數值作為hash值計算的key，通過hash計算得出的hash值和總權重的余數作為挑選server的依據；nginx的一致性hash(chash)演算法則要復雜一些。這里會對一致性hash的機制原理作詳細的說明。
一致性hash演算法的原理
一致性hash用於對hash演算法的改進，後端伺服器在配置的server的數量發生變化後，同一個upstream server接收到的請求會的數量和server數量變化之間會有變化。尤其是在負載均衡配置的upstream server數量發生增長後，造成產生的請求可能會在後端的upstream server中並不均勻，有的upstream server負載很低，有的upstream server負載較高，這樣的負載均衡的效果比較差，可能對upstream server造成不良的影響。由此，產生了一致性hash演算法來均衡。
那麼為什麼一致性hash演算法能改善這種情況呢？這里引用網上資料的一致性hash演算法的圖例。
因為對於hash(k)的范圍在int范圍，所以我們將0~2^32作為一個環。其步驟為：
1，求出每個伺服器的hash（伺服器ip）值，將其配置到一個 0~2^n 的圓環上（n通常取32）。
2，用同樣的方法求出待存儲對象的主鍵 hash值，也將其配置到這個圓環上，然後從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。
其分布如圖：
除了上邊的優點，其實還有一個優點：對於熱點數據，如果發現node1訪問量明顯很大，負載高於其他節點，這就說明node1存儲的數據是熱點數據。這時候，為了減少node1的負載，我們可以在熱點數據位置再加入一個node，用來分擔熱點數據的壓力。
雪崩效應
接下來我們來看一下，當有節點宕機時會有什麼問題。如下圖：
如上圖，當B節點宕機後，原本存儲在B節點的k1，k2將會遷移到節點C上，這可能會導致很大的問題。如果B上存儲的是熱點數據，將數據遷移到C節點上，然後C需要承受B+C的數據，也承受不住，也掛了。。。。然後繼續CD都掛了。這就造成了雪崩效應。
上面會造成雪崩效應的原因分析：
如果不存在熱點數據的時候，每台機器的承受的壓力是M/2(假設每台機器的最高負載能力為M)，原本是不會有問題的，但是，這個時候A伺服器由於有熱點數據掛了，然後A的數據遷移至B，導致B所需要承受的壓力變為M（還不考慮熱點數據訪問的壓力），所以這個失敗B是必掛的，然後C至少需要承受1.5M的壓力。。。。然後大家一起掛。。。
所以我們通過上面可以看到，之所以會大家一起掛，原因在於如果一台機器掛了，那麼它的壓力全部被分配到一台機器上，導致雪崩。
怎麼解決雪崩問題呢，這時候需要引入虛擬節點來進行解決。
虛擬節點
虛擬節點，我們可以針對每個實際的節點，虛擬出多個虛擬節點，用來映射到圈上的位置，進行存儲對應的數據。如下圖：
如上圖：A節點對應A1，A2，BCD節點同理。這時候，如果A節點掛了，A節點的數據遷移情況是:A1數據會遷移到C2，A2數據遷移到D1。這就相當於A的數據被C和D分擔了，這就避免了雪崩效應的發送，而且虛擬節點我們可以自定義設置，使其適用於我們的應用。
ngx_http_upstream_consistent_hash
該模塊可以根據配置參數採取不同的方式將請求均勻映射到後端機器，比如：
指令
語法：consistent_hash variable_name
默認值：none
上下文：upstream
配置upstream採用一致性hash作為負載均衡演算法，並使用配置的變數名作為hash輸入。
參考文檔：
https://www.cnblogs.com/FengGeBlog/p/10615345.html
http://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-mole/