① Nginx相關知識點
Nginx是lgor Sysoev為俄羅斯訪問量第二的rambler.ru站點設計開發的。從2004年發布至今，憑借開源的力量，已經接近成熟與完善。
Nginx功能豐富，可作為HTTP伺服器，也可作為反向代理伺服器，郵件伺服器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gzip等功能。並且支持很多第三方的模塊擴展。
Nginx的穩定性、功能集、示例配置文件和低系統資源的消耗讓他後來居上，在全球活躍的網站中有12.18%的使用比率，大約為2220萬個網站。
自行安裝
正向代理: 代理伺服器站在客戶端那邊就是正向代理;
反向代理: 代理伺服器站在原始伺服器那邊就是反向代理;
詳解參考點擊 Nginx正向代理與反向代理
Nginx在做反向代理時，提供性能穩定，並且能夠提供配置靈活的轉發功能。
Nginx可以根據不同的正則匹配，採取不同的轉發策略，比如圖片文件結尾的走文件伺服器，動態頁面走web伺服器，只要你正則寫的沒問題，又有相對應的伺服器解決方案，你就可以隨心所欲的玩。
並且Nginx對返回結果進行錯誤頁跳轉，異常判斷等。如果被分發的伺服器存在異常，他可以將請求重新轉發給另外一台伺服器，然後自動去除異常伺服器。
如果你的nginx伺服器給2台web伺服器做代理，負載均衡演算法採用輪詢，那麼當你的一台機器web程序iis關閉，也就是說web不能訪問，那麼nginx伺服器分發請求還是會給這台不能訪問的web伺服器，如果這里的響應連接時間過長，就會導致客戶端的頁面一直在等待響應，對用戶來說體驗就打打折扣，這里我們怎麼避免這樣的情況發生呢。這里我配張圖來說明下問題。
如果負載均衡中其中web2發生這樣的情況，nginx首先會去web1請求，但是nginx在配置不當的情況下會繼續分發請求道web2，然後等待web2響應，直到我們的響應時間超時，才會把請求重新分發給web1，這里的響應時間如果過長，用戶等待的時間就會越長。
下面的配置是解決方案之一:
如果使用upstream指令配置了一組伺服器作為被代理伺服器，伺服器中的訪問演算法遵循配置的負載均衡規則，同時可以使用該指令配置在發生哪些異常情況時，將請求順次交由下一組伺服器處理。
狀態值可以是：error|timeout|invalid_header|http_500|http_502|http_503|http_504|http_404|off
Nginx提供的負載均衡策略有2種：內置策略和擴展策略。
內置策略: 1.輪詢;2.加權輪詢;3.Ip hash;
擴展策略: 就天馬行空，只有你想不到的沒有他做不到的啦，你可以參照所有的負載均衡演算法，給他一一找出來做下實現。
Ip hash演算法，對客戶端請求的ip進行hash操作，然後根據hash結果將同一個客戶端ip的請求分發給同一台伺服器進行處理，可以解決session不共享的問題。
eg:
開啟簡單的緩存配置，只需要兩個指令：proxy_cache_path和proxy_cache。
proxy_cache_path: 配置緩存的存放地址和其他的一些常用配置;
proxy_cache:指令是為了啟動緩存;
相關配置說明:
該指令用於定義滿足條件的響應不會被保存到緩存中。在條件字元串中至少有一個條件不為空或者0，符合這樣條件的響應才不會被緩存。
舉例如下
其中，cookie_nocache、arg_nocache...皆為變數，可以根據你訪問的匹配策略來設置，其值只有2類，0和非0;
訪問匹配策略例如：
如果在此鏈式配置中，只要有一個值不為0，則不會cache；例如：
則不會被cache.
註：一般會配合proxy_cache_bypass共同使用；
該指令用於定義哪些情況不從cache讀取，直接從backend獲取資源；配置方式同proxy_no_cache。
給緩存數據定義一個鍵，例如
該指令用於設置緩存哪些HTTP方法,默認緩存HTTP GET/HEAD方法,不緩存HTTP POST 方法.。
設置不同響應碼的緩存時間，當不指定響應碼的時候，例如
只對響應碼為200，301，302的訪問請求資源設置緩存時間，此外可以個性化定製，例如：
此外，還可以在相應header里設置優先順序更高的緩存有效時間：
不緩存包含在field的響應header，可以設置的值有：「X-Accel-Redirect」, 「X-Accel-Expires」, 「X-Accel-Limit-Rate」，「X-Accel-Buffering」, 「X-Accel-Charset」, 「Expires」, 「Cache-Control」, 「Set-Cookie」 (0.8.44), and 「Vary」。
如果上述的header field沒有設置為忽略，則header filed中有「X-Accel-Expires」, 「Expires」, 「Cache-Control」, 「Set-Cookie」, and 「Vary」的話，響應會被緩存。
該指令用於設置緩存的最小使用次數,默認值為1
源站有問題時，nginx可以通過proxy_cache_use_stale指令開啟容錯能力，即使用緩存內容來響應客戶端的請求。舉例如下：
如上配置表示，當作為cache的NGINX收到源站返回error、timeout或者其他指定的5XX錯誤，並且在其緩存中有請求文件的陳舊版本，則會將這些陳舊版本的文件而不是錯誤信息發送給客戶端。
使用NGINX，不需要建立一個RAID（磁碟陣列）。如果有多個硬碟，NGINX可以用來在多個硬碟之間分割緩存。舉例如下：
在這份配置中，使用了3個獨立的緩存，每個緩存專用一塊硬碟，另外，3個獨立的線程池也各自專用一塊硬碟。
緩存之間（其結果就是磁碟之間）的負載均衡使用split_clients模塊，split_clients非常適用於這個任務。
在 proxy_cache_path指令中設置 use_temp_path=off ，表示NGINX會將臨時文件保存在緩存數據的同一目錄中。這是為了避免在更新緩存時，磁碟之間互相復制響應數據。
通過訪問日誌，你可以得到用戶地域來源、跳轉來源、使用終端、某個URL訪問量等相關信息；
通過錯誤日誌，你可以得到系統某個服務或server的性能瓶頸等。
因此，將日誌好好利用，你可以得到很多有價值的信息。
打開nginx.conf配置文件：vim /usr/local/nginx/conf/nginx.conf
日誌部分內容：
#access_log logs/access.log main;
日誌生成的到Nginx根目錄logs/access.log文件，默認使用「main」日誌格式，也可以自定義格式。
默認「main」日誌格式：
參數明細表：
查看日誌命令tail -f /usr/local/nginx/logs/access.log
打開nginx.conf配置文件去掉#注釋見下圖：
自定義某一個server配置的日誌，使用「main」日誌格式。
日誌生成的到Nginx根目錄logs/access.log文件，默認使用「main」日誌格式，也可以自定義格式。
重新讀取載入Nginx配置文件：
執行命令：nginx-s reload
網上一位老師寫的log文件分解的腳本
此腳本執行時間根據自己公司情況來定,可以設置默認一天執行一次;
創建crontab設置作業
設置日誌文件存放目錄crontab -e
*/1 * * * * sh /usr/local/software/nginx/nginx_log.sh
此設置的為一分鍾,如果設置一天自行修改;
默認的 nginx 配置文件 nginx.conf 內容如下
示例
幾個常見配置項：
注意:
驚群現象：一個網路連接到來，多個睡眠的進程被同事叫醒，但只有一個進程能獲得鏈接，這樣會影響系統性能
每個指令必須有分號結束。
進入安裝目錄下的sbin
② 多個nginx如何分發，達到負載均衡。國內大型網站一般如何實現的
這方面的資料，基本都是一塊一塊不完整的。我大概跟你說一個基本架構：
1、DNS伺服器，如果資金充足的話，建議使用BGP機房，2-3台DNS伺服器均衡，通常使用bind軟體。如果資金緊的話，可以購買專業的dns服務，比如國內的dnspod。
2、CDN伺服器，一開始如果想省事，可以買專業公司的服務，如chinacache，但隨著發展成本會越來越高。自建的話，可能分別搭建，放電信、聯通、移動等不同機房的伺服器，通過dns做動態解析。超大網站的話，可以用Squid，普通中至大型用nginx，內部玩玩用varnish。
3、前端均衡，資金充足的話，可以使用硬體設備，幾十萬一台。自已有技術隊伍的話，就用nginx/haproxy+keepalived等自已組建前端。均衡的方式都比較靈活，隨機、權重、ip、url都有。
4、同步的問題要看同步什麼東西，普通的可以實時文件同步。但資料庫的話，要看具體類型選擇同步方式了。
5、後端的應用伺服器和資料庫集群，要看流量規劃了。
③ 負載均衡——LVS，HAProxy和Nginx對比分析
負載均衡（Load Balance）是應用於互聯網後台系統架構顫孝設計中的各層，它將請求均勻分攤到多個操作單元上執行。
目前，在線上環境中應用較多的負載均衡器硬體有F5 BIG-IP，但是硬體設備昂貴，不如軟體適應互聯網公司的快速發展。最常用的負載均衡軟體有LVS、HAProxy和Nginx，結合高可用軟體有Heartbeat、Keepalived，可以搭建出承載海量請求的成熟架構如LVS+Keepalived、HAProxy+keepalived等.
三種負載均衡軟體LVS、HAProxy和Nginx的優缺點說明如下：
LVS的優點：
LVS的缺點：
HAProxy的優點：
Nginx的優點輪宴：
Nginx的缺點：
簡單地不負責任地說，性能上LVS>HA>Nginx，功能性和便利性上Nginx>HA>LVS。
對於一個大型後台系統來說，LVS、HAProxy和Nginx常常可以配合使用在不同的層級，LVS用在接入層的最前端，承擔最大規模的流量分發；HAProxy負責按域名分流；而Nginx只需要作為Web伺服器負責單機內多實例的負載均衡，或負責目錄結構分流和靜態資源緩存等需求。
所謂的四層與七層負載均衡，就是在對後台伺服器進行負載均衡時，依茄桐稿據OSI四層的信息或七層的信息來決定怎麼樣轉發流量。比如四層負載均衡通過報文中的目標IP地址和埠，七層負載均衡通過報文中的應用層信息(URL、HTTP頭部等信息)，選擇到達目的的內部伺服器。四層負載均衡在解包上的消耗更少，可以達到更高的性能。而七層負載演算法可以通過更多的應用層信息分發請求，功能性上更強大。
七層負載均衡軟體可以通過URL、Cookie和HTTP head等信息，而不僅僅是IP埠分發流量，還可以修改客戶端的請求和伺服器的響應（例如HTTP請求中的Header的重寫），極大提升了應用系統在網路層的靈活性。
在網路中常見的SYN Flood攻擊中，黑客會對同一目標大量發送SYN報文，耗盡伺服器上的相關資源，以達到Denial of Service(DoS)的目的。四層模式下這些SYN攻擊都會被轉發到後端的伺服器上；而在七層模式下這些SYN攻擊在負載均衡設備上就截止，不會影響後台伺服器的正常運營。另外負載均衡設備可以在七層層面設定多種策略，過濾sql Injection等應用層面的特定攻擊手段，進一步提高系統整體安全。
④ Nginx多台伺服器實現負載均衡
Nginx負載均衡伺服器： IP：192.168.0.4（Nginx-Server）
Web伺服器列表：
Web1: 192.168.0.5（Nginx-Node1/Nginx-Web1）
Web2:192.168.0.7（Nginx-Node2/Nginx-Web2）
實簡困讓現目的：用戶訪問Nginx-Server時，通過Nginx負載均衡到Web1和Web2伺服器。
配置注釋如下：尺槐
創建文件夾准備存放配置文件
啟動負載均衡伺服器192.168.0.4（Nginx-Server）
創建文件夾用於存放web頁面
編輯內容如下：
啟動192.168.0.5（Nginx-Node1/Nginx-Web1）
創建文件夾用於存放web頁面
編輯攔局內容如下：
啟動192.168.0.7（Nginx-Node2/Nginx-Web2）
⑤ 負載均衡：F5，Haproxy，lvs, nginx
閱讀本文前，需熟悉OSI七層參考模型。
常見的負載均衡設備，有F5，Haproxy，lvs, nginx等。
F5是商用硬體負載均衡，性能很好，但是價格昂貴，除了負載均衡，還有應用交換、會話交換、狀態監控等眾多功能。
F5一般做四層負載均衡，但也支持七層負載均衡。
Haproxy(以下簡稱ha)是軟嘩唯歲件負載均衡，開源，一般做七層負載均衡，但也支持四層負載均衡。
Linux Virtual Server(以下簡稱lvs)是軟體負載均衡，開源，二層或四層負載均衡，已集成到linux內核，自身有完備的熱備方案（keepalived+lvs），穩定性極強。
nginx也是軟體負載均衡，開源，通過反向代理實現負載均衡，是七層負載均衡，性能不如上面的幾個。
tips1
有些公司，測試環境用ha/lvs/nginx，生產環境用F5。
tips2
nginx做web伺服器時，一般做靜態資源伺服器和php的web伺服器，所以很多公司，會採用F5+nginx或者ha+nginx的架構
tips3
微服務中的ribbon屬於客戶端負載均衡，上面的幾種都是服務端負載均衡
二層負載均衡
在數據鏈路層通過修改mac地址實現，如lvs的DR模式（直接路由模式）
三層負載均衡
在網路層通過DNAT協議修改目標地址實現
四層負載均衡
用ip+埠實現請求轉發
備註：tcp報文里並沒有ip，但是四層負載均衡可以用ip+埠，是因為server可以拿到ip
七層負載均衡
通過重新發起http請求實現，即client把請求發給lb，lb把請求代發給server，再把server的響應返回給client，因此七層負載均衡也經常被稱為代理，七層負載均衡設備也被稱為代理設備。
七層負載均衡常用於內網與外網的通信，比如內網無法直接訪問外網，需要通過代理設備代發http請求，這種情況下，代理設備需要配置雙網卡，以同時與內外網路通信。
由於山寬需要重發http請求，七層負載均衡性能較差，但是更智能和安全，因為應用層可以獲取甚至修改請求的真實內容（即應用數據），比如cookie、url等，可以做一些智能的操作，比如根據cookie/url轉發請求，也可以做一些安全操作，比如過濾特定報文、防止SYN Flood攻擊等。
使用七層負載均衡時，服務的性能受限於代理設備的網卡帶寬。
常見的負載均衡策略，有輪詢、加權輪詢、ip_hash、cookie、url_hash，根據伺服器響應時間轉發、根據最少連接轉發等等。
備註：nginx可以安裝第三方插件，使用第三方實現的策略
輪詢：按伺服器列表順序轉發請求，輪詢是nginx默認的策略，本策略適合伺服器配置相當、請求無狀態（即不依賴session）的場景
加權輪詢：如果不同伺服器配置不同，可以為配亂睜置高的伺服器增加權重
ip_hash：根據ip哈希結果轉發，可以實現同一用戶持續請求同一伺服器（即會話保持），適合有狀態（即依賴session）的場景，對png、jpg、js、css等靜態資源的請求，不適合使用本策略
cookie：根據特定cookie轉發請求，一般也是用於實現會話保持，比如為伺服器A、B分別增加service-flag=a、service-flag=b的cookie，後續請求根據cookie轉發
可以參考 haproxy實現會話保持
url_hash：根據url哈希結果轉發，同一個介面始終請求同一台伺服器，一般配合緩存使用，緩存介面返回結果
根據伺服器響應時間轉發：優先轉發到響應時間較快的伺服器
根據最少連接轉發：優先轉發到連接數較少的伺服器
F5有一些特有的負載均衡策略：利用從應用程序和伺服器收集到的各項性能指標，分析並轉發
負載均衡有兩個步驟：
1.根據什麼演算法選擇真實服務端，即負載均衡策略，如輪詢、加權輪詢、ip_hash、cookie、url_hash等；
2.把請求轉發到真實伺服器，轉發方式有二層到七層負載均衡
keepalived軟體一開始是專為lvs設計的，後來加入了可以實現高可用的VRRP (Virtual Router Rendancy Protocol ,虛擬路由器冗餘協議）功能，因此，keepalived還可以作為nginx、haproxy、mysql等服務的高可用解決方案。
以nginx為例，為了防止nginx本身由於宕機等原因導致網站不可用，一般會搭兩套nginx反向代理，用keepalived提供一個VIP。
一般情況下，VIP只在nginx主節點上工作，如果nginx主節點不可用了，VIP會自動漂移到從節點，自動漂移的原理即VRRP協議。
VIP漂移到從節點後，如果主節點恢復正常了，VIP是否漂移回主節點，取決於當前模式是搶占模式還是非搶占模式。
下圖是一張簡單的架構圖，解釋如下：
以上觀點純屬個人意見，如果錯誤，歡迎指出，有些地方寫的很簡單，是因為我也不懂~
⑥ nginx在做負載均衡時如何配置
1、下面的架構就是我們今天的演示結構，後端有兩台伺服器，分別是node1和node2，前端是一台web伺服器，然後在web伺服器上做負載均衡，將前端的訪問流量導到後端的兩個節點伺服器上。三個伺服器的IP地址分別是：web：192.168.1.210node1：192.168.1.211node2：192.168.1.212
2、按照這樣的架構，在後端的node1和node2節點上分配配置好需要訪問的網站，然後為了方便測試，我們將兩個網站的主頁分別改成下面的內容。便於區分訪問的節點。
3、後端兩個節點配置好以後，我們再來配置web伺服器里的負載均衡配置，首先使用默認配置，先打開/etc/nginx/nginx.conf配置文件，在http區塊里添加upstream塊內容，及配置了兩個後端伺服器，後端負載均衡集群的名稱是backend，記下這個名稱。
4、然後再打開/etc/nginx/conf.d/default.conf這個配置文件，在server區塊里，把location裡面的內容改成圖中所示內容。即將所有訪問192.168.1.210的流量代理到後端的backend集群里。
5、配置文件配置好以後，使用nginx-t命令測試一下配置文件，保證配置文件是ok狀態，然後執行nginx命令啟動nginx伺服器。
6、啟動後在瀏覽器上輸入前端web伺服器的ip地址192.168.1.210，然後可以看到第一次是node1響應的，然後刷新一下以後，又變成了node2響應的。就這樣實現了負載均衡的效果。由兩個伺服器分別響應，是因為默認的負載均衡演算法是輪詢演算法，即兩個節點輪流來。
7、然後我們還可以嘗試一下加權輪詢演算法，即給不同的節點配置不同的權重，權重高一點的伺服器，響應的多一些，權重第一點的響應少一些。加權輪詢演算法配置，在後端伺服器後面加上權重值weight即可。配置好以後，執行nginx-t命令檢測配置文件，確認無誤後，執行nginx-sreload命令重新載入配置文件。
8、通過加權輪詢的方式，我們無法通過手動一次次點擊，最後來統計次數。但是我們可以使用自動化工具來統計。使用的工具是一款叫做httpd-tools的軟體，安裝好以後，提供了一個ab命令
9、然後我們來執行ab命令進行測試，常用的格式是：ab-n1000-c50http://localhost這個命令是在210伺服器上執行的。表示一共執行1000次訪問，每次發送50個請求。
10、然後我們登錄到後端的node1伺服器上，打開nginx的訪問日誌，從中可以看到ab命令測試的訪問信息里，訪問來源都是ApacheBench，因此可以通過可以來源來統計nginx響應的次數。命令是：grepApacheBenchaccess.log|wcnode1和node2節點上的統計結果分別是714和286，如下面圖中所示，雖然沒有達到5:2的權重比例，但是也非常接近了。說明這個配置生效了。
⑦ 如何在一台pc上做nginx負載均衡
一、實驗環境
閱讀本文前，假定讀者對nginx安裝、虛擬機的安裝有了解，並未對這些內容作詳細介紹。
一台pc
pc安裝的操作系統為win7，使用vmware虛擬兩台linux，pc 連接到了一台交換機，IP為： 192.168.1.100
nginx版本為1.05，其中win7為負載均衡代理機器，虛擬的linux為web伺服器
vmware配置時，在網路連接一項選： bridged，兩台虛擬機的ip分別為： 192.168.1.102,192.168.1.103
二、配置文件
1 win7用於負載均衡的nginx的配置文件如下(nginx.conf)，修改完後可再控制台輸入： nginx -t，來測試修改的配置文件是否正確。
upstream test {
server 192.168.1.102;
server 192.168.1.103;
}
server {
listen 80;
server_name localhost;
charset gbk;
#access_log logs/host.access.log main;
location / {
proxy_next_upstream error timeout invalid_header http_500
http_502 http_503 http_504 http_404;
proxy_connect_timeout 10s;
proxy_read_timeout 2s;
#proxy_send_timeout 10s;
proxy_pass http://test;
}
2 linux上作為web伺服器的nginx的配置文件可為默認，沒有變化
3 修改作為web伺服器的nginx，html目錄下的index.html，在Welcome to nginx!後面加上描述： i am server x!,這一步是為了區分服務是否生效。
三、運行服務
1.win7:直接在控制台輸入：nginx即可
2.linux:nginx -c ./conf/nginx.conf
如果運行成功，這時在你win7的瀏覽器中輸入http://192.168.1.100 ，這時會有i am server 2顯示，按f5刷新，server名字每次都會變化！
四、結論
本文只是在一台機器上簡單對輪詢試負載均衡做了簡單的測試。
後續的實驗，將全部在此機器上做測試了
⑧ 我用nginx配置webservice負載均衡，怎麼弄
簡單的宏戚負載均衡配衡絕判置 upstream backend { server backend1.example.com weight=5;#weight權重，權重越高發送咐改到此台伺服器的請求概率越大 server backend2.example.com:8080; server backup1.example.com:8080 backup;#backup備份伺服器，只有在非backup伺服器都不能訪問時才會向此伺服器分流
⑨ Nginx，一看就會
Nginx("engine x") 是一個高性能的 HTTP 和反向代理伺服器,特點是佔有內存少，並發能力強，事實上 nginx 的並發能力確實在同類型的網頁伺服器中表現較好，中國大陸使用 nginx 網站用戶有：雀改網路、京東、新浪、網易、騰訊、 淘寶等。
1.1 WEB 伺服器
Nginx 可以作為靜態頁面的 web 伺服器，同時還支持 CGI 協議的動態語言，比如 perl、php
等。但是不支持 java。Java 程序只能通過與 tomcat 配合完成。Nginx 專為性能優化而開發，性能是其最重要的考量,實現上非常注重效率 ，能經受高負載的考驗,有報告表明能支持高達 50000個並發連接數。
1.2 反向代理
1.正向代理，代理客戶端，客戶端需要配置代理
2.反向代理，代理服務端，客戶端無感知
1.3 負載均衡
Nginx 的非同步框架可以處理很大的並發請求，把這些並發請求 hold 住之後就可以分發給後台服務端(backend servers，也叫做服務池， 後面簡稱 backend)來做復雜的計算、處理和響應，這種模式的好處是相當多的：隱藏業務主機更安全，節約了公網 IP 地址，並且在業務量增加的時候可以方頃碧判便地擴容後台伺服器。
這時候集群的概念產生了，我們增加伺服器的數量，然後將請求分發到各個伺服器上，將原先請求集中到單個伺服器上的情況改為將請求分發到多個伺服器上，將負載分發到不同的服器，也就是我們所說的負載均衡。
1.4 動靜分離
為了加快網站的解析速度，可以把動態頁面和靜態頁面由不同的伺服器來解析，加快解析速度。降低原來單個伺服器的壓力。
Nginx官網
2.1 相關安裝包
pcre-8.37.tar.gz openssl-1.0.1t.tar.gz zlib-1.2.8.tar.gz nginx-1.11.1.tar.gz
2.2 安裝流程
2.1.1.安裝 pcre 解壓縮 pcre-xx.tar.gz 包
進入解壓縮目錄，執行./configure
如果提示，需要提前安裝 gcc++，進入安裝光碟目錄的軟體包(/media/CentOSXX/Package)執行
rpm -ivh libstdc+ devel-4.4.7-17.el6.x86_64.rpm
rpm -ivh gcc-c+ 4.4.7-17.el6.x86_64.rpm
./configure 完成後，回到 pcre 目錄下執行 make，再執行 make install
2.2.2.安裝 openssl
解壓縮 openssl-xx.tar.gz 包。
進入解壓縮目錄，執行./config
make && make install
2.2.3.安裝 zlib 解壓縮 zlib-xx.tar.gz 包。
進入解壓縮目錄，執行./configure。
make && make install
2.2.4.安裝 nginx
解壓縮 nginx-xx.tar.gz 包。
進入解壓縮目錄，執行./configure。
make && make install
查看開放的埠號
firewall-cmd --list-all
設置開放的埠號
firewall-cmd --add-service=http –permanent
sudo firewall-cmd --add-port=80/tcp --permanent
重啟防火牆
firewall-cmd –reload
2.3 Nginx 啟動
命令
啟動命令：在/usr/local/nginx/sbin 目錄下執行 ./nginx
關閉命令: 在/usr/local/nginx/sbin 目錄下執行 ./nginx -s stop
重新載入命令: 在/usr/local/nginx/sbin 目錄下執行 ./nginx -s reload·
設置 nginx 為自啟動服務
修改慧差 linux 啟動腳本/etc/rc.d/rc
加入 :/usr/local/nginx/sbin/nginx
nginx 安裝目錄下，其默認的配置文件都放在conf 目錄下，而主配置文件nginx.conf 也在其中，後續對 nginx 的使用基本上都是對此配置文件進行相應的修改。
根據上述文件，我們可以很明顯的將 nginx.conf 配置文件分為三部分
第一部分：全局塊
從配置文件開始到 events 塊之間的內容，主要會設置一些影響 nginx 伺服器整體運行的配置指令，主要包括配置運行 Nginx 伺服器的用戶（組）、允許生成的 worker process 數，進程 PID 存放路徑、日誌存放路徑和類型以及配置文件的引入等。
比如上面第一行配置的：worker_processes 1;
這是 Nginx 伺服器並發處理服務的關鍵配置，worker_processes 值越大，可以支持的並發處理量也越多，但是會受到硬體、軟體等設備的制約。
第二部分：events 塊
events 塊涉及的指令主要影響 Nginx 伺服器與用戶的網路連接，常用的設置包括是否開啟對多 work process 下的網路連接進行序列化，是否允許同時接收多個網路連接，選取哪種事件驅動模型來處理連接請求，每個 word process 可以同時支持的最大連接數等。
上述例子就表示每個 work process 支持的最大連接數為 1024.
這部分的配置對 Nginx 的性能影響較大，在實際中應該靈活配置。
第三部分：http 塊
這算是 Nginx 伺服器配置中最頻繁的部分，代理、緩存和日誌定義等絕大多數功能和第三方模塊的配置都在這里。
需要注意的是：http 塊也可以包括 http 全局塊、server 塊。
http 全局塊
http 全局塊配置的指令包括文件引入、MIME-TYPE 定義、日誌自定義、連接超時時間、單鏈接請求數上限等。
server 塊
這塊和虛擬主機有密切關系，虛擬主機從用戶角度看，和一台獨立的硬體主機是完全一樣的，該技術的產生是為了節省互聯網伺服器硬體成本。
每個 http 塊可以包括多個 server 塊，而每個 server 塊就相當於一個虛擬主機。
而每個 server 塊也分為全局 server 塊，以及可以同時包含多個 locaton 塊。
全局 server 塊
最常見的配置是本虛擬機主機的監聽配置和本虛擬主機的名稱或 IP 配置。
location 塊
一個 server 塊可以配置多個 location 塊。
這塊的主要作用是基於 Nginx 伺服器接收到的請求字元串（例如 server_name/uri-string），對虛擬主機名稱（也可以是 IP 別名）之外的字元串（例如 前面的 /uri-string）進行匹配，對特定的請求進行處理。地址定向、數據緩存和應答控制等功能，還有許多第三方模塊的配置也在這里進行。
案例配置如下：
location 指令說明
該指令用於匹配 URL，語法如下：
= ：用於不含正則表達式的 uri 前，要求請求字元串與 uri 嚴格匹配，如果匹配
成功，就停止繼續向下搜索並立即處理該請求。
~：用於表示 uri 包含正則表達式，並且區分大小寫。
~*：用於表示 uri 包含正則表達式，並且不區分大小寫。
^~：用於不含正則表達式的 uri 前，要求 Nginx 伺服器找到標識 uri 和請求字
符串匹配度最高的 location 後，立即使用此 location 處理請求，而不再使用 location
塊中的正則 uri 和請求字元串做匹配。
注意：如果 uri 包含正則表達式，則必須要有 ~ 或者 ~* 標識。
案例配置如下：
在 linux 下有 Nginx、LVS、Haproxy 等等服務可以提供負載均衡服務，而且 Nginx 提供了幾種分配方式(策略)：
輪詢（默認）
每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器 down 掉，能自動剔除。
weight
weight 代表權重，默認為 1，權重越高被分配的客戶端越多指定輪詢幾率，weight 和訪問比率成正比，用於後端伺服器性能不均的情況。
ip_hash
每個請求按訪問 ip 的 hash 結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決 session 的問題。
fair（第三方）
按後端伺服器的響應時間來分配請求，響應時間短的優先分配。
動靜分離從目前實現角度來講大致分為兩種：
1.一種是純粹把靜態文件獨立成單獨的域名，放在獨立的伺服器上，也是目前主流推崇的方案；
2.另外一種方法就是動態跟靜態文件混合在一起發布，通過 nginx 來分開。
通過 location 指定不同的後綴名實現不同的請求轉發。通過 expires 參數設置，可以使瀏覽器緩存過期時間，減少與伺服器之前的請求和流量。具體 Expires 定義：是給一個資源設定一個過期時間，也就是說無需去服務端驗證，直接通過瀏覽器自身確認是否過期即可，所以不會產生額外的流量。此種方法非常適合不經常變動的資源。（如果經常更新的文件，不建議使用 Expires 來緩存），我這里設置 3d，表示在這 3 天之內訪問這個 URL，發送一個請求，比對伺服器該文件最後更新時間沒有變化，則不會從伺服器抓取，返回狀態碼304，如果有修改，則直接從伺服器重新下載，返回狀態碼 200。
master-workers 的機制的好處
首先，對於每個 worker 進程來說，獨立的進程，不需要加鎖，所以省掉了鎖帶來的開銷，
同時在編程以及問題查找時，也會方便很多。其次，採用獨立的進程，可以讓互相之間不會
影響，一個進程退出後，其它進程還在工作，服務不會中斷，master 進程則很快啟動新的
worker 進程。當然，worker 進程的異常退出，肯定是程序有 bug 了，異常退出，會導致當
前 worker 上的所有請求失敗，不過不會影響到所有請求，所以降低了風險。
需要設置多少個 worker
Nginx 同 redis 類似都採用了 io 多路復用機制，每個 worker 都是一個獨立的進程，但每個進
程里只有一個主線程，通過非同步非阻塞的方式來處理請求， 即使是千上萬個請求也不在話
下。每個 worker 的線程可以把一個 cpu 的性能發揮到極致。所以 worker 數和伺服器的 cpu
數相等是最為適宜的。設少了會浪費 cpu，設多了會造成 cpu 頻繁切換上下文帶來的損耗。
連接數 worker_connection
這個值是表示每個 worker 進程所能建立連接的最大值，所以，一個 nginx 能建立的最大連接數，應該是 worker_connections * worker_processes。當然，這里說的是最大連接數，對於HTTP 請 求 本 地 資 源 來 說 ， 能 夠 支 持 的 最 大 並 發 數 量 是 worker_connections * worker_processes，如果是支持 http1.1 的瀏覽器每次訪問要佔兩個連接，所以普通的靜態訪問最大並發數是： worker_connections * worker_processes /2，而如果是 HTTP 作 為反向代理來說，最大並發數量應該是 worker_connections *
worker_processes/4。因為作為反向代理伺服器，每個並發會建立與客戶端的連接和與後端服務的連接，會佔用兩個連接。
注意：此部分屬於高級技術，近幾日會將下面的知識點補充完畢。
8.1 Keepalived+Nginx 高可用集群（主從模式）
8.2 Keepalived+Nginx 高可用集群（雙主模式）