要理解負載均衡，必須先搞清楚正向代理和反向代理。
注：
- 正向代理，代理的是用戶。
- 反向代理，代理的是服務器
什么是負載均衡
當一臺服務器的單位時間內(nèi)的訪問量越大時，服務器壓力就越大，大到超過自身承受能力時，服務器就會崩潰。為了避免服務器崩潰，讓用戶有更好的體驗，我們通過負載均衡的方式來分擔服務器壓力。
我們可以建立很多很多服務器，組成一個服務器集群，當用戶訪問網(wǎng)站時，先訪問一個中間服務器，在讓這個中間服務器在服務器集群中選擇一個壓力較小的服務器，然后將該訪問請求引入該服務器。如此以來，用戶的每次訪問，都會保證服務器集群中的每個服務器壓力趨于平衡，分擔了服務器壓力，避免了服務器崩潰的情況。
負載均衡是用反向代理的原理實現(xiàn)的。
負載均衡的幾種常用方式
1、輪詢（默認）
每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除。
upstream backserver {
server 192.168.0.14;
server 192.168.0.15;
}
2、weight
指定輪詢幾率，weight和訪問比率成正比，用于后端服務器性能不均的
情況。
upstream backserver {
server 192.168.0.14 weight=3;
server 192.168.0.15 weight=7;
}
權重越高，在被訪問的概率越大，如上例，分別是30%，70%。
3、上述方式存在一個問題就是說，在負載均衡系統(tǒng)中，假如用戶在某臺服務器上登錄了，那么該用戶第二次請求的時候，因為我們是負載均衡系統(tǒng)，每次請求都會重新定位到服務器集群中的某一個，那么已經(jīng)登錄某一個服務器的用戶再重新定位到另一個服務器，其登錄信息將會丟失，這樣顯然是不妥的。
我們可以采用ip_hash指令解決這個問題，如果客戶已經(jīng)訪問了某個服務器，當用戶再次訪問時，會將該請求通過哈希算法，自動定位到該服務器。
每個請求按訪問ip的hash結(jié)果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。
upstream backserver {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
4、fair（第三方）
按后端服務器的響應時間來分配請求，響應時間短的優(yōu)先分配。
upstream backserver {
server server1;
server server2;
fair;
}
5、url_hash（第三方）
按訪問url的hash結(jié)果來分配請求，使每個url定向到同一個后端服務器，后端服務器為緩存時比較有效。
upstream backserver {
server squid1:3128;
server squid2:3128;
hash $request_uri;
hash_method crc32;
}123456
每個設備的狀態(tài)設置為:
- down 表示單前的server暫時不參與負載
- weight 默認為1.weight越大，負載的權重就越大。
- max_fails：允許請求失敗的次數(shù)默認為1.當超過最大次數(shù)時，返回 proxy_next_upstream模塊定義的錯誤
- fail_timeout:max_fails次失敗后，暫停的時間。
- backup： 其它所有的非backup機器down或者忙的時候，請求backup機器。所以這臺機器壓力會最輕。
配置實例：
#user nobody;
worker_processes 4;
events {
# 最大并發(fā)數(shù)
worker_connections 1024;
}
http{
# 待選服務器列表
upstream myproject{
# ip_hash指令，將同一用戶引入同一服務器。
ip_hash;
server 125.219.42.4 fail_timeout=60s;
server 172.31.2.183;
}
server{
# 監(jiān)聽端口
listen 80;
# 根目錄下
location / {
# 選擇哪個服務器列表
proxy_pass http://myproject;
}
}
}
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。
