文章目錄
- 一. Nginx 負載均衡策略
- 1. 輪詢(默認策略)
- 2. 加權輪詢 (默認是 1)
- 3. ip_hash
- `注意1: 在使用ip_hash時, 如果一臺服務器宕機, 我們在配置中不能直接洗掉, 而是要標記為down.`
- `注意2: 使用ip_hash可以會有惡意的用戶進行大量的高并發訪問, 這樣就會導致處理該請求的服務器的性能急劇下降, 甚至宕機.`
- ip_hash演算法原理(addr.length=3, 表示處理IPv4的前三個部分值)
- 原始碼分析:
- 直觀解釋:
- 使用配置如下:
- 通過設定的 server_name 的 ip 進行訪問
- 4. url_hash
- 進行配置
- 簡單專案進行測驗:
- 注意: 路徑`http://www.tomcats.com/nginx-url-hash/hello` 與`http://www.tomcats.com/nginx-url-hash/hello/` 經過url_hash演算法, 會處理到不同的服務器上, 原因是后者多了一個`/`, 導致了hash值不同.
- 5. least_conn (根據哪一臺服務器的連接數少, 就去優先訪問該上游服務器)
- 進行配置
- 二. upstream 指令引數
- 1. max_conns(表示設定最大的連接數)
- 2. slow_start (緩慢啟動)`不適用于hash 和 隨機的負載均衡方式`
- (`該引數是在付費商業版使用的, 開源的會報錯~~`)
- 3. down (標記的服務器使之無法訪問)
- 4. backup(標記后, 表示該服務器是一臺備用機, 即開始時候不會使用, 只有服務器宕機之后, 才會啟用該標記的上游服務器)
- 5. max_fails(設定最大的失敗次數. 默認為1)
- 6. fail_timeout(設定失敗的時間時長. 默認為 10秒)
- 使用JMeter 進行測驗
一. Nginx 負載均衡策略
1. 輪詢(默認策略)
服務器平均的將瀏覽器請求進行一個個分配, 他會默認的將一個一個請求進行分配, 如下, 按照特定的順序平均分配服務器資源.
我們修改 兩臺tomcat的 首頁(ROOT/index.jsp), 如下, 重繪后, tomcat1 和 tomcat2 輪流分配.
2. 加權輪詢 (默認是 1)
直接在 server配置之后添加 weight 權重: weight=? , ? 越大, 權重越高, 默認是1
3. ip_hash
將ip進行hash處理, 即每個用戶在上游服務器都正常運轉的情況下(即運作期間沒有宕機和新添的上游服務器), 總是會找到一臺固定的服務器來處理自己的請求, 以此來提高自己的訪問效率.
因為總是自己的請求打在穩定的特定的服務器上, 所以這樣就會保證用戶的會話 session 就不會跑到其他的服務器中了, 如果該用戶的ip動態的發送變化, 就會導致請求會話跑到其他的服務器中了.
注意1: 在使用ip_hash時, 如果一臺服務器宕機, 我們在配置中不能直接洗掉, 而是要標記為down.
注意2: 使用ip_hash可以會有惡意的用戶進行大量的高并發訪問, 這樣就會導致處理該請求的服務器的性能急劇下降, 甚至宕機.
===============================================================
ip_hash演算法原理(addr.length=3, 表示處理IPv4的前三個部分值)
ip_hash是根據上游服務器的ip值的ipv4的前三部分進行判斷的, 即下面的案例訪問到的服務器都是一臺.
只有Ipv4地址的前三部分的值不同, 才會進行hasp匹配, 打到不同的服務器上.
原始碼分析:
直觀解釋:
使用配置如下:
通過設定的 server_name 的 ip 進行訪問
4. url_hash
相比較于 ip_hash, ip_hash是根據用戶的ip地址進行的分配, 那么 url_hash就是根據用戶請求的url鏈接進行的分配, 其原理就是根據所請求的控制器不同(不同業務對應的不同url鏈接)來進行url的hash處理, 從而分配到不同的上游服務器中.
進行配置
簡單專案進行測驗:
注意: 路徑http://www.tomcats.com/nginx-url-hash/hello 與http://www.tomcats.com/nginx-url-hash/hello/ 經過url_hash演算法, 會處理到不同的服務器上, 原因是后者多了一個/, 導致了hash值不同.
5. least_conn (根據哪一臺服務器的連接數少, 就去優先訪問該上游服務器)
進行配置
====================================================================
二. upstream 指令引數
(官方檔案)
1. max_conns(表示設定最大的連接數)
用于限制一臺上游服務器的最大連接數, 默認是 0, 不做任何限制
注意: 如果是使用到了多個 works 行程的時候, 會涉及到 共享記憶體, 連接總數一定會超過這個 max_conns.
- 配置 beyond.conf
- 配置好 nginx.conf, 將 worker 設定為1 即可
- 使用JMeter 進行測驗
測驗配置如下:
我的服務器不太行…, 意思到了即可哈, 可以觀察觀察結果樹, 應該正常是 沒兩次成功請求, 然后失敗, 這樣往復
2. slow_start (緩慢啟動)不適用于hash 和 隨機的負載均衡方式
(該引數是在付費商業版使用的, 開源的會報錯~~)
slow_start=time, 默認是0, 即表示關閉慢啟動
3. down (標記的服務器使之無法訪問)
4. backup(標記后, 表示該服務器是一臺備用機, 即開始時候不會使用, 只有服務器宕機之后, 才會啟用該標記的上游服務器)
對不起, 服務器不夠, 土豪可以無視, 繼續玩下去
5. max_fails(設定最大的失敗次數. 默認為1)
如果該服務器接收到的請求總是失敗, 且失敗的次數達到了我們設定的最大失敗次數, 那么這臺服務器就會被標記為宕機狀態, 其他后續的請求就不會再訪問這臺上游服務器了.
6. fail_timeout(設定失敗的時間時長. 默認為 10秒)
在我們設定了max_fails=2 后, 若設定 fail_timeout=15s , 則表示請求到達該上游服務器的失敗次數最大為二, 當失敗請求達到2的時候, 服務器并不會宕機, 而是會再等待15秒(我們設定的fail_timeout), 在這15秒內不會有請求到達該服務器, 而是去找正常的服務器. 當這15秒過后, 會有新的請求繼續嘗試訪問該服務器, 如果失敗, 繼續找正常運作的服務器…就這樣回圈, 直到該服務器被修復.
使用JMeter 進行測驗
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/271299.html
標籤：其他