要理解負載均衡,必須先搞清楚正向代理和反向代理。算法
負載均衡的幾種經常使用方式後端
每一個請求按時間順序逐一分配到不一樣的後端服務器,若是後端服務器down掉,能自動剔除。緩存
upstream backserver { server 192.168.0.14; server 192.168.0.15; }
指定輪詢概率,weight和訪問比率成正比,用於後端服務器性能不均的
狀況。服務器
upstream backserver { server 192.168.0.14 weight=3; server 192.168.0.15 weight=7; }
權重越高,在被訪問的機率越大,如上例,分別是30%,70%。session
上述方式存在一個問題就是說,在負載均衡系統中,假如用戶在某臺服務器上登陸了,那麼該用戶第二次請求的時候,由於咱們是負載均衡系統,每次請求都會從新定位到服務器集羣中的某一個,那麼已經登陸某一個服務器的用戶再從新定位到另外一個服務器,其登陸信息將會丟失,這樣顯然是不妥的。
咱們能夠採用ip_hash指令解決這個問題,若是客戶已經訪問了某個服務器,當用戶再次訪問時,會將該請求經過哈希算法,自動定位到該服務器。
每一個請求按訪問ip的hash結果分配,這樣每一個訪客固定訪問一個後端服務器,能夠解決session的問題。併發
upstream backserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; }
按後端服務器的響應時間來分配請求,響應時間短的優先分配。負載均衡
upstream backserver { server server1; server server2; fair; }
按訪問url的hash結果來分配請求,使每一個url定向到同一個(對應的)後端服務器,後端服務器爲緩存時比較有效。性能
upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; }
在須要使用負載均衡的server中增長ui
proxy_pass http://backserver/; upstream backserver{ ip_hash; server 127.0.0.1:9090 down; (down 表示單前的server暫時不參與負載) server 127.0.0.1:8080 weight=2; (weight 默認爲1.weight越大,負載的權重就越大) server 127.0.0.1:6060; server 127.0.0.1:7070 backup; (其它全部的非backup機器down或者忙的時候,請求backup機器) }
max_fails :容許請求失敗的次數默認爲1.當超過最大次數時,返回proxy_next_upstream 模塊定義的錯誤 url
fail_timeout:max_fails次失敗後,暫停的時間
配置實例:
#user nobody; worker_processes 4; events { # 最大併發數 worker_connections 1024; } http{ # 待選服務器列表 upstream myproject{ # ip_hash指令,將同一用戶引入同一服務器。 ip_hash; server 125.219.42.4 fail_timeout=60s; server 172.31.2.183; } server{ # 監聽端口 listen 80; # 根目錄下 location / { # 選擇哪一個服務器列表 proxy_pass http://myproject; } } }