目錄
- 一、Nginx介紹
- 二、Nginx特點
- 三、Nginx負載均衡
- 3.1 認識 upstream 模塊
- 3.2 Nginx負載均衡策略
- 3.3 Nginx負載均衡實體
- 總結
一、Nginx介紹
Nginx是一款高性能的Http和反向代理服務器,也是一個IMAP/POP3/SMTP服務器(電子郵件代理),最早開發這個產品的目的之一也是作為郵件代理服務器,因它的穩定性、豐富的功能集、示例組態檔和低系統資源的消耗及其高并發性能強而廣泛應用于各種生產部署之中,而且nginx是基于事件驅動模型(epoll)實作的I/O多路復用,并通過異步、非阻塞的方式處理請求,在高連接并發的情況下,Nginx是Apache服務器不錯的替代品,而我們為什么要選擇Nginx呢?
二、Nginx特點
- 高并發、高性能;
- 高可靠(可以7*24小時不間斷運行);
- 可擴展性強(高度模塊化設計,添加模塊平穩);
- 作為 Web 服務器:相比 Apache,Nginx 使用更少的資源,支持更多的并發連接;
- 作為負載均衡服務器:可以進行自定義配置,支持虛擬主機、支持URL重定向、支持網路監控等,
- Nginx 安裝非常的簡單,組態檔 非常簡潔(還能夠支持perl語法),Bugs少;
- 處理靜態檔案,索引檔案以及自動索引;
- 反向代理加速(無快取),簡單的負載均衡和容錯;
- 支持熱部署(可在不停止服務器的情況下升級nginx),
這就是為什么要選擇Nginx的原因,而且Nginx的功能特點還不止這些,上面只是簡單列舉了幾點常見功能,
三、Nginx負載均衡
在我們實際生產中,一臺服務器的處理能力、存盤空間是有限的, 不要企圖去換更強大的服務器,對大型網站而言,不管多么強大的服務器,都滿足不了網站持續增長的業務需求,這種情況下,更恰當的做法是增加一臺服務器來分擔原有服務器的訪問及存盤壓力,實際上這就是我們所謂的負載均衡,Nginx作為負載均衡服務器,它通過反向代理來對后端多臺服務器負載均衡,首先來說一下Nginx負載均衡策略及負載均衡演算法,
3.1 認識 upstream 模塊
upstream 這個模塊是寫一組被代理的服務器地址(即定義的后端服務器串列中選取一臺服務器接受用戶的請求 ),然后配置負載均衡的演算法, 來看一下最基本的負載均衡實體:
upstream test {
server 10.20.151.114:80;
server 10.20.151.115:80;
}
server {
....
location / {
proxy_pass http://test; --請求轉向 test 定義的服務器串列
}
3.2 Nginx負載均衡策略
(1)輪詢
最基本的配置方法,上面的例子就是輪詢的方式,它是upstream模塊默認的負載均衡默認策略,每個請求會按時間順序逐一分配到不同的后端服務器,
upstream test {
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}
(2)ip_hash
每個請求按訪問IP的hash結果分配,同一個IP客戶端固定訪問一個后端服務器,可以保證來自同一ip的請求被打到固定的機器上,可以解決session問題,
upstream test {
ip_hash; --同一個IP客戶端固定訪問一個后端服務器
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}
(3)url_hash
按訪問url的hash結果來分配請求,使每個url定向到同一個后端服務器,一旦快取住了資源,再此收到請求,就可以從快取中讀取,
upstream test {
hash $request_uri; --實作每個url定向到同一個后端服務器
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}
(4)least_conn
把請求轉發給連接數較少的后端服務器,輪詢演算法是把請求平均的轉發給各個后端,使它們的負載大致相同;但是,有些請求占用的時間很長,會導致其所在的后端負載較高,這種情況下,least_conn這種方式就可以達到更好的負載均衡效果,
upstream test {
least_conn; --把請求轉發給連接數較少的后端服務器
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}
(5)weight
權重方式,在輪詢策略的基礎上指定輪詢的幾率,
upstream test {
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2; --輪詢的幾率相對上一條要大
}
(6)fair
此種演算法可以依據頁面大小和加載時間長短智能地進行負載均衡,也就是根據后端服務器的回應時間來分配請求,回應時間短的優先分配,
upstream test {
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
fair; --實作回應時間短的優先分配
}
nginx負載均衡配置狀態引數
down:表示當前的server暫時不參與負載均衡,
backup:預留的備份機器,當其他所有的非backup機器出現故障或者忙的時候,才會請求backup機器,因此這臺機器的壓力最輕,
max_fails:允許請求失敗的次數,默認為1,當超過最大次數時,回傳proxy_next_upstream 模塊定義的錯誤,
fail_timeout:在經歷了max_fails次失敗后,暫停服務的時間單位秒,max_fails可以和fail_timeout一起使用,
Nginx可分為二層、三層、四層、七層負載均衡, 所謂的二層就是基于MAC地址的負載均衡, 三層就是基于IP地址的負載均衡,四層就是基于IP+埠的負載均衡,七層就是基于URL等應用層資訊的負載均衡,因篇幅較長這里不再做具體的介紹,有興趣的可自行百度,這里以七層負載均衡來做實體,
3.3 Nginx負載均衡實體
環境準備:準備3臺Nginx服務器,一臺作為負載均衡服務器,其它兩臺作為后端服務器,
10.20.151.240 ----proxy_server(負載均衡服務器)
10.20.151.112 ----server1(后端服務器1)
10.20.151.113 ----server2(后端服務器2)
(1)負載均衡服務器配置
vim /etc/nginx/nginx.conf --配置主組態檔
vim /etc/nginx/conf.d/test.conf --配置子組態檔


(2)后端服務器配置
vim /usr/local/nginx/conf/nginx.conf --修改組態檔
vim /usr/local/nginx/html/index.html --添加測驗資料


(3)負載均衡測驗
在瀏覽器端訪問http://10.20.151.240/,在實際生產中,這兩個頁面回傳的結果是一樣的,這里是為了測驗效果,所以回傳了不同的內容,而為什么重繪后又會回傳不同結果呢?那是因為負載均衡默認的均衡策略(或演算法)是輪詢,所以每重繪一次就會從不同的后端服務器回傳不同的請求結果,減輕單個后端服務器的訪問量,提升客戶端的訪問效率,從而達到負載均衡的效果,


-
當我添加權重(weight)時

-
再次訪問http://10.20.151.240/


加權重和沒加權重有什么區別呢?在實際生產中,我們一般會將配置較高的服務器的權重設定高一點,其實就是客戶端在訪問時,權重較高的服務器會被多次請求,這樣能減輕配置較低的服務器的請求量,從而更好的實作負載均衡,
-
-
當我添加backup狀態引數時

-
再次訪問http://10.20.151.240/

-
此時我故意停掉第一臺后端服務器,繼續訪問http://10.20.151.240/

當我給113這臺后端服務器添加backup后,它就會作為熱備服務器,添加的主要目的就是當我其他后端服務器都宕機的情況下,我的熱備服務器還能繼續提供同樣的服務(注意:在其他后端服務器還未宕機之前,該熱備服務器是不作業的),因此負載均衡不僅能達到各個后端服務器負載的均衡,同時通過配置相關轉態引數還能保證客戶端請求時不造成服務器宕機的情況,保證了后端服務器的穩定性,其他狀態引數這里我不再做演示(因為配置方式都一樣),
-
總結
通過上述簡單案例不難看出負載均衡的重要性,不管是大中小型企業,都會用到負載均衡,尤其是某些大型購物網站,如果不做負載均衡,估計剛上線幾分鐘后端服務器就會被客戶端的請求給弄癱瘓了,因此Nginx負載均衡實作的就是后端服務器的平均分攤客戶端的訪問壓力,同時借助Nginx的高并發、高性能、高可靠性等特點,對我們的實際生產提供了最大化服務和性能保障,
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/26595.html
標籤:其他
上一篇:【求助】在學Python編程從入門到實踐,繼承這章添加Battery類后原來的子類跑不了了
下一篇:急救急救
