① 發布在nginx上的前端項目如何查看源碼
點擊獲取Nginx源碼。在nginx上的前端項目中的整體頁面上，為了防止項目的錯誤出現，管理員可以在前台系統中，點擊獲取Nginx源碼，即可顯示原代碼。Nginx是一個高性能的HTTP和反向代理web伺服器。
② 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;
}
}
③ 07《Nginx 入門教程》Nginx 的 Http 模塊介紹（上）
本部分內容將詳細介紹 Nginx 中對 Http請求的 11 個處理階段，分成 3 個小節講解並進行相關實驗操作。
Nginx 將一個 Http 請求分成多個階段，以模塊為單位進行處理。其將 Http請求的處理過程分成了 11 個階段，各個階段可以包含任意多個 Http 的模塊並以流水線的方式處理請求。這 11 個 Http 階段如下所示：
網上有人做了一個非常形象的圖片，如下圖所示。我們可以看到 11 個階段的處理順序，以及每個階段中涉及到的相關模塊以及模塊梁拍之間的順序。
POST_READ 階段是 Nginx 接收到 Http 請求完整頭部後的處理階段，這里主要使用的是 realip 模塊獲取用戶的真實地址，方便後續對該 IP 進行限速或者過濾其請求等。
SERVER_REWRITE 和後面的 REWRITE 階段一般是使用 rewrite 模塊修改 Http請求的 uri，實現請求的控制。
FIND_CONFIG 階段只是做 location 的匹配項。
PREACCESS、ACCESS 和 POST_ACCESS 是和橡啟羨 Http 請求訪問許可權相關的階段。PREACCESS 階段是在連接之前要做的訪問控制, 這個階段有 limit_conn 和 limit_req 等模塊工作。ACCESS 階段是解決用戶能不能訪問，比如根據用戶名、密碼限制用戶訪問(auth_basic 模塊)、根據 ip 限制用戶訪問(access 模塊)以及第三方模塊認證限制用戶的訪問(auth_request模塊)。POST_ACCESS 是在 ACCESS 之後要做的一些工作。
TRY_FILES 階段為訪問靜態文件資源而設置的。有時候又稱之為 PRECONTENT 階段，即在 CONTENT 階段之前做的事情。主要是 try_files 模塊在此階段工作。
最重要的 CONTENT 是處理 Http 請求內容的階段，大部分 HTTP 模塊介入這個階段，比如 index、autoindex、concat 以及反向代理的模塊都是在這里生效的。
LOG 是處理完請求後的日誌記錄階段，如 access_log 模塊。
realip 模塊是旁段在 postread 階段生效的，它的作用是: 當本機的 nginx 處於一個反向代理的後端時獲取到真實的用戶 ip。 如果沒有 realip 模塊，Nginx 中的 $remote_addr 可能就不是客戶端的真實 ip 了，而是代理主機的 ip。
realip模塊的配置實例如下:
set_real_ip_from 是指定我們信任的後端代理伺服器，real_ip_header 是告訴 nginx 真正的用戶 ip 是存在 X-Forwarded-For 請求頭中的。
當 real_ip_recursive 設置為 off 時，nginx 會把 real_ip_header 指定的 Http頭中的最後一個 ip 當成真實 ip;
而當 real_ip_recursive 為 on 時，nginx 會把 real_ip_header 指定的 Http頭中的最後一個不是信任伺服器的 ip (前面設置的set_real_ip_from)當成真實 ip。通過這樣的手段，最後拿到用戶的真實 ip。
rewrite 模塊可以看到它在 SERVER_REWRITE 和 REWRITE 階段都有介入。rewrite 模塊的主要功能是改寫請求的 uri。它是 Nginx 默認安裝的模塊。rewrite 模塊會根據正則匹配重寫 uri，然後發起內部跳轉再匹配 location, 或者直接做30x重定向返回客戶端。rewrite 模塊的指令有 break, if, return, rewrite, set 等，這些都是我們常用到的。
return 指令返回後，Http 請求將在 return 的階段終止，後續階段將無法進行，所以許多模塊得不到執行。
1、將 regex 指定的 url 替換成 replacement 這個新的 url,可以使用正則表達式及變數提取。
2、當 replacement 以 http:// 或者 https:// 或者 $schema 開頭，則直接返回 302 重定向
3、替換後的 url 根據 flag 指定的方式進行處理
if 指令的條件表達式:
location 匹配是在 FIND_CONFIG 階段進行的，我們需要掌握 location 的匹配規則和匹配順序。
有一個簡單總結如下：
即：
realip 模塊默認沒有被編譯進 Nginx 的，我們需要在源碼編譯階段使用–with-http_realip_mole，將 realip 模塊編譯進來後方可使用。接下來，我們做個簡單測試，首先准備一個 server 塊如下：
首先，我們將 real_ip_recursive 設置為 off，然後做一次請求:
這里返回的是頭部參數 X-Forwarded-For 中最後一個 ip，如果將 real_ip_recursive 設置為 on，此時，由於 set_real_ip_from 中設置218.19.206.164為信任的方向代理 ip，那麼 Nginx 會往前找一位，認為 1.1.1.1 是用戶的真實ip。
我們寫一個簡單配置如下：
先測試if指令，當請求方法為 POST 時，我們能得到 『post request!』 這樣的字元串輸出。GET 請求時候，針對 404 情況，會跳轉到/403.html，我們准備一個 403.html 頁面，裡面寫上』403, forbidden!』 這一行內容，開始下面的 Http 請求:
如果我們打開 return 405 這行指令，則 error_page 將不會生效，連同後面的 location 匹配也不會生效。無論我們發送如何請求，都會返回405的錯誤信息。這是因為 server 中的 return 指令是在 SERVER_REWRITE中執行的，而 location 匹配則是在下一個階段 FIND_CONFIG 中執行的，所以上一個階段在 return 後，根本不會進入後面的階段執行。
首先，我們准備環境，首先是新建一個目錄 third（全路徑為/root/test/third），再該目錄下新建一個文件 3.txt, 裡面只有一行內容 『hello, world』。接下來，我們准備一個 server 塊，加到 Http 指令塊中:
上述配置中，要打開 rewrite_log指令，這樣我們可以看到 rewrite 指令的相應日誌，方便查看結果。
當我們在 /second 配置中，使用 break 時，請求命令:
如果是不使用 break 標識，則請求結果如下:
首先是 /first/3.txt 請求在 /first 中匹配，並被替換為 /second/3.txt， last 標識表示將繼續進行匹配，在 /second 中，uri 又被 rewrite 成 /third/3.txt, 如果後面跟了 break 標識，表示 rewrite 到此結束，不會執行後面的 return 指令，直接請求靜態資源 /third/3.txt,得到其內容』hello, world』;如果是沒有 break 標識，則會在執行 return 指令後直接返回，並不會繼續執行下去，最後返回』second!'字元串。
我們按照這樣的 location 規則，進行匹配實驗，結果如下：
這里介紹了 Nginx 處理 Http 請求的 11 個階段，並重點介紹了 前三個階段POST_READ、REWRITE以及FIND_CONFIG以及這些階段中涉及到的模塊和指令。前面講到的指令都是 Nginx 中的高頻指令，必須要熟練掌握。
④ 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/
⑤ linux系統中編譯安裝Nginx伺服器，看了還不會你來打我
使用yum安裝方式安裝PCRE：
yum安裝後檢查安裝結果：
使用yum安裝openssl-devel：
檢查yum安裝結果：
在確保Nginx編譯安裝所依賴的pcre-devel和openssl-devel已經安裝好了後，可以下載Nginx源碼進行編譯安裝。 Nginx源碼可以從Nginx官方網站（http://nginx.org）找到相應版本源碼的下載地址： http://nginx.org/download/nginx-1.16.0.tar.gz
下載Nginx源碼：
添加nginx用戶，服務於Nginx：
解壓軟體包：
編譯Ngixn源碼並安裝：
建立nginx應用程序軟鏈接：
啟動前為了避免報錯，先檢查配置文件語法：
啟動Nginx服務：
查看Nginx服務是否啟動成功：
說明已經啟動成功，打開瀏覽器輸入http://127.0.0.1/就可以看到nginx網頁信息。
⑥ linux系統怎麼安裝nginx
這里以CentOS6.6系統（32位）中安裝nginx的源碼包，進行講解。
1. nginx源碼包的下載
nginx官方下載地址：http://nginx.org/
選擇你要安裝的nginx版本，這里，我選擇的是 nginx-1.10.2 。
具體的下載鏈接為：http://nginx.org/download/nginx-1.10.2.tar.gz
可以在其他電腦下載好，通過ftp軟體傳給要安裝的linux電腦。也可以直接在linux電腦上使用wget命令下載。這里我們使用後一種方式。
在linux的根目錄，創建一個多級空目錄 /my_package/source，用來存放下載的源碼包。
mkdir -p /my_package/sourcecd /my_package/source12
執行下載命令：
wget http://nginx.org/download/nginx-1.10.2.tar.gz1
下載完成後，在 /my_package/source 目錄中，就有了 nginx-1.10.2.tar.gz 源碼包壓縮文件。
2. nginx的安裝與配置
2.1 准備工作
安裝nginx之前，需要先安裝pcre庫。如果你的linux系統中沒有pcre，需要先進行安裝。
這里，我們使用yum工具，在線快速安裝pcre：
yum -y install pcre
yum -y install pcre-devel12
可以通過下面的命令，找到已安裝的pcre和pcre-devel的位置：
rpm -ql pcre
rpm -ql pcre-devel或
find / -name "*pcre*"1234
2.2 nginx的安裝
配置nginx安裝的參數，比如：安裝路徑，指定依賴庫的具體位置等。
這里我們使用默認安裝配置：
tar -zxvf nginx-1.10.2.tar.gzcd nginx-1.10.2./configure123
如果這一步執行正確，在提示信息中會告知nginx將要安裝的位置、可執行文件的位置等，如下：
nginx path prefix: "/usr/local/nginx"nginx binary file: "/usr/local/nginx/sbin/nginx"nginx moles path: "/usr/local/nginx/moles"nginx configuration prefix: "/usr/local/nginx/conf"nginx configuration file: "/usr/local/nginx/conf/nginx.conf"nginx pid file: "/usr/local/nginx/logs/nginx.pid"nginx error log file: "/usr/local/nginx/logs/error.log"nginx http access log file: "/usr/local/nginx/logs/access.log"nginx http client request body temporary files: "client_body_temp"nginx http proxy temporary files: "proxy_temp"nginx http fastcgi temporary files: "fastcgi_temp"nginx http uwsgi temporary files: "uwsgi_temp"nginx http scgi temporary files: "scgi_temp"12345678910111213
如果這一步出錯了，根據錯誤提示信息解決問題後，使用 make clean 命令，清除產生的臨時文件，再來重新執行 ./configure
如果想查看具體可以配置哪些安裝參數，可以使用下面的命令查看：
./configure --help1
編譯和安裝
makemake install12
到此，nginx的源碼包就安裝完畢了。
2.3 nginx的配置
如果想修改nginx的配置文件，可使用下面的命令：
vi /usr/local/nginx/conf/nginx.conf1
3. nginx的常用命令
檢查測試nginx的配置信息是否正確
/usr/local/nginx/sbin/nginx -t1
啟動nginx
/usr/local/nginx/sbin/nginx1
啟動nginx伺服器後，可以使用下面的命令檢測nginx是否啟動成功，並查看nginx的埠、主進程號、進程名稱等信息。
netstat -tlunp1
也可以使用下面的命令檢測nginx是否啟動成功，並查看nginx的主進程和子進程的詳細信息。
ps aux | grep nginx1
ps aux 命令（a代表前台進程，x代表後台進程，u代表進程的發起者）列出的進程信息中，主要包含以下信息：USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND 。這里，簡單說明一下：
USER：表示進程的發起者，也就是說，進程是哪個用戶產生的。
PID：表示進程的id，也稱作，進程號。%CPU：表示進程佔用的CPU資源的百分比。%MEM：表示進程佔用的物理內存的百分比。
VSZ：表示進程佔用的虛擬內存的大小，單位KB。
RSS：表示進程佔用的實際物理內存的大小，單位KB。
TTY：表示進程是在哪個終端中運行的。其中tty1到tty7代表本地控制台終端，tty1到tty6是本地的字元界面終端，tty7是圖形終端。pts/0-255代表虛擬終端（即遠程登錄終端）。
STAT：表示進程的狀態。常見的狀態有：R 運行；S 睡眠；T 停止；s 包含子進程；+ 位於後台。
START：表示進程是在什麼時間啟動的。
TIME：表示進程佔用CPU的運算時間，值越大，越耗費資源。
COMMAND：表示產生該進程的命令（通過它可以識別正在運行的進程名）。1234567891011
成功啟動nginx後，就可以在本地電腦或其他電腦中訪問你的nginx伺服器中的網站了。
本地電腦（即nginx所在的電腦）的訪問方式：curl 127.0.0.1
其他電腦（區域網內）的訪問方式：打開瀏覽器，輸入nginx伺服器的區域網IP即可。12
為了更方便的使用 /usr/local/nginx/sbin 中的命令，
我們將其加入linux系統的環境變數，即修改文件 /etc/profile，在最後加入下面的代碼：
export PATH="/usr/local/nginx/sbin:$PATH"1
保存退出後，執行命令：source /etc/profile 可使該配置文件立即生效。
關閉nginx
nginx -s stop 快速關閉nginx
nginx -s quit 平滑關閉nginx
kill -s QUIT 11247 通過linux的kill命令殺死nginx進程，11247為nginx的主進程號123
重新載入nginx的配置文件
nginx -s reload 修改了nginx的配置文件後，可以使用該命令讓新的配置立即生效，而不用重啟整個nginx伺服器
希望我的方法能夠幫助到你