前言 想必在linux上寫過程式的同學都有分析進程占用多少記憶體的經歷，或者被問到這樣的問題——你的程式在運行時占用了多少記憶體（物理記憶體）？ 通常我們可以通過top命令查看進程占用了多少記憶體。這裡我們可以看到VIRT、RES和SHR三個重要的指標，他們分別代表什麼意思呢？ 這是本文需要跟大家一起探討的 ...
Nginx幾種負載均衡方式介紹
前言
負載均衡就是Nginx將請求分攤到不同的伺服器中，保證服務的可用性，緩解服務壓力，保證服務的響應速度，即使某一個應用服務不可用，也可以保證業務的正常進行，並且方便對伺服器進行擴容縮容。負載均衡軟體有很多，例如LVS、HAProxy等，今天我們僅講解Nginx負載均衡常見的幾種策略。
負載均衡策略
輪詢（Nginx自帶、預設）
該策略是Nginx預設的負載均衡策略，每一個客戶端請求按時間順序輪流分配到不同的伺服器上，如果後端服務不可以用，會自動過濾掉。
upstream my_test_server {
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
weight 權重（Nginx自帶）
weight代表權重的意思，用於指定輪詢的幾率，預設權重都是1，可以手動設置調整，權重越高，被分配的次數越多，weight權重和訪問比例是成正比的，用於解決後端伺服器性能不均衡時，調整訪問比例。
upstream my_test_server {
server 192.168.0.100:8080 weight=1;
server 192.168.0.101:8080 weight=2;
server 192.168.0.102:8080 weight=3;
}
ip_hash（Nginx自帶）
ip_hash是將每個請求按照訪問ip的hash結果進行分配，這種方式可以保證同一個用戶會固定訪問一個後端伺服器。優點：可以保證session會話，解決伺服器之間session不能共用的問題。
upstream my_test_server {
ip_hash;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
least_conn（Nginx自帶）
將請求轉發給連接數較少的後端伺服器。每個後端伺服器配置可能不同，處理的請求也有可能不同，對於處理的請求有快有慢，least_conn是根據後端伺服器的連接情況，動態的選擇連接數量較少的一臺伺服器來處理當前的請求。
upstream my_test_server {
least_conn;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
fair（第三方）
fair是按照伺服器端的響應時間來分配請求，響應時間短的伺服器優先分配。第三方的負載均衡策略需要安裝第三方的插件。
upstream my_test_server {
fair;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
url_hash（第三方）
url_hash是根據url的hash結果進行分配請求，每一個url會固定到同一個伺服器上，配合緩存使用，可以減少不必要的下載和資源時間的浪費。每次同一個url請求到達同一個伺服器上，第一次載入後放入緩存，後面再次請求，直接取緩存資源。如果不採用url_hash，可能會導致請求到達不同的伺服器，資源出現重新載入的情況。第三方的負載均衡策略需要安裝第三方的插件。
upstream my_test_server {
hash $request_uri;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
配置
在conf文件中配置上述負載均衡配置後，需要在server塊中進行配置使用。
upstream my_test_server {
ip_hash;
server 192.168.0.100:8080;
server 192.168.0.101:8080;
}
server {
listen 80;
server_name localhost;
location / {
proxy_pass htttp://my_test_server;
proxy_set_header Host $proxy_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
如有侵權請立即與我們聯繫，我們將及時處理，聯繫郵箱:[email protected]。
原文鏈接:https://monkey.blog.xpyvip.top/archives/nginx-fu-zai-jun-heng
