Nginx配置負載均衡和會話保持
1、準備工作
首先準備兩臺服務器，這里我們準備了兩臺虛擬機，ip 地址分別為 192.168.32.128 和 192.168.32.129，以此模擬兩臺服務器。
在這兩臺服務器上分別啟動了 tomcat 服務器， 并且都在 tomcat 的 webapps 目錄下新建 mySystem 目錄，在該目錄下新建 a.html，以此模擬在多臺服務器上都部署了同一個項目。不過我們在不同服務器上的 a.html 文件的顯示內容上做了一些不同修改，以便做負載均衡時能區分出來是不是請求發送到了不同服務器上（當然，實際生產時多臺服務器上的資源應該是保持一致的）。
在 192.168.32.128 服務器上啟動 Nginx，并在該服務器上的 Nginx 做負載均衡。
Nginx的安裝可參考：http://www.rzrgm.cn/wenxuehai/p/14966724.html#autoid-h2-2-3-0
在Linux上安裝啟動tomcat可參考：http://www.rzrgm.cn/wenxuehai/p/14974657.html#_label0
2、配置負載均衡
我們需要實現的效果如下：
也就是通過 Nginx 將請求轉發至兩臺服務器上。
打開 192.168.32.128 服務器的 Nginx 配置文件，即 /usr/local/nginx/conf/nginx.conf 文件，配置負載均衡。
修改內容如下：
配置完成后，啟動兩臺服務器的 tomcat ，并且啟動 192.168.32.128 服務器的 Nginx。我們通過瀏覽器訪問 http://192.168.32.128/mySystem/a.html ，多次刷新可以看到效果如下：
可以看到請求被平均分發到兩臺服務器上，也就是這一次請求的是 192.168.32.128 上的資源，下一次請求的就是 192.168.32.129 服務器上的資源。由此，我們就實現了負載均衡。
2.1、完整的Nginx配置文件
完整的 nginx.conf 配置文件如下：
#user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; upstream myServerSetting { server 192.168.32.128:8080; server 192.168.32.129:8080; } server { listen 80; server_name 192.168.32.128; #charset koi8-r; #access_log logs/host.access.log main; location / { proxy_pass http://myServerSetting; root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ \.php$ { # root html; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } # another virtual host using mix of IP-, name-, and port-based configuration # #server { # listen 8000; # listen somename:8080; # server_name somename alias another.alias; # location / { # root html; # index index.html index.htm; # } #} # HTTPS server # #server { # listen 443 ssl; # server_name localhost; # ssl_certificate cert.pem; # ssl_certificate_key cert.key; # ssl_session_cache shared:SSL:1m; # ssl_session_timeout 5m; # ssl_ciphers HIGH:!aNULL:!MD5; # ssl_prefer_server_ciphers on; # location / { # root html; # index index.html index.htm; # } #} }
3、Nginx負載均衡策略
3.1、輪詢（默認）
輪詢方式是 Nginx 負載均衡默認的方式。顧名思義，所有請求都按照時間順序分配到不同的服務上。如果某個服務器 Down 掉，可以自動將該服務器剔除，不再分發請求到該服務器上。
我們上面的配置就是使用的默認即輪詢策略進行分發：
upstream myServerSetting { server 192.168.32.128:8080; server 192.168.32.129:8080; }
3.2、權重（weight）
可以用 weight 關鍵字來指定每個服務器的權重比例，默認權重為 1，weight和訪問比率成正比，權重越高被分發到的請求越多。通常用于后端服務機器性能不統一，將性能好的分配權重高來發揮服務器最大性能。
如下配置后10002服務的訪問比率會是10001服務的二倍：
upstream dalaoyang-server { server localhost:10001 weight=1; server localhost:10002 weight=2; }
3.3、ip_hash（一個客戶端訪問固定服務器）
每個請求都根據訪問 ip 的 hash 結果分配，經過這樣的處理，每個訪客固定訪問一個后端服務，可以解決 session 的問題。
如下配置（ip_hash 可以和 weight 配合使用）。
upstream dalaoyang-server { ip_hash; server localhost:10001 weight=1; server localhost:10002 weight=2; }
3.4、fair（服務器響應快的優先分配）
按后端服務器的響應時間來分配請求，響應時間短的優先分配。
upstream dalaoyang-server { server localhost:10001 weight=1; server localhost:10002 weight=2; fair; }
4、Nginx 實現后端會話保持
會話保持（Session Affinity）是一種負載均衡技術，也稱為會話粘滯（Session Stickiness），它確保客戶端的一系列請求在整個會話期間都被發送到同一臺后端服務器上。通常，HTTP 是一種無狀態協議，即每個請求都是獨立的，服務器不會記住前一個請求的狀態，在這種情況下，如果用戶的請求被發送到不同的服務器，則可能出現用戶雖然登錄了但是因為下次請求被發送到了另一臺服務器，服務器查詢不到用戶登錄信息導致用戶需不斷重新登錄。為了解決這個問題，會話保持技術被引入，確?？蛻舳嗽谡麄€會話期間與同一臺服務器通信。
4.1、基于ip_hash的會話保持
在做Nginx的負載均衡時，可以在upstream里設置ip_hash，每個請求按訪問ip的hash結果分配，映射到固定某一臺的服務器。
缺點：
- 由于同一個IP客戶端都固定訪問一個后端服務器，這就可能會導致負載不均衡。特別是跟固定的上游服務器交互的情況下，負載會很不均衡。
配置示例：
upstream dalaoyang-server { ip_hash; server localhost:10001 weight=1; server localhost:10002 weight=2; }
4.2、基于cookie的會話保持
Sticky是基于cookie的一種負載均衡解決方案，根據服務器給客戶端的cookie，客戶端再次請求時會帶上此 cookie，nginx 會把有此 cookie 的請求轉發到對應的服務器上。即實現同個會話內的請求（即cookie未過期前的請求）都會被發送到同一臺后端服務器。
基于 cookie 的會話保持可以使用 nginx-sticky-module 模塊實現（需安裝使用），nginx-sticky-module是一個用于Nginx的模塊，它能夠在后端服務器之間保持（"sticky"）用戶會話。這意味著一旦用戶被定向到一臺特定的后端服務器，他們的后續請求將被自動定向到同一臺服務器，除非后端服務器宕機或者有其他理由導致負載均衡器需要將用戶轉移到另一臺服務器。在 nginx-sticky-module 模塊中默認此 cookie 的 key 名為route。
（Nginx sticky模塊不能與ip_hash同時使用）（注意，基于 cookie 的會話保持并不是用的登錄信息的 session，雖然也是存在服務器中，但不是同一個東西）
原理：
- 客戶端首次發起訪問請求，nginx接收后，發現請求頭沒有cookie，則以輪詢方式將請求分發給后端服務器。
- 后端服務器處理完請求，將響應數據返回給nginx。
- 此時 nginx 生成帶 route 的cookie（例如：Cookie：route=19c3afb04a79d36869450dfe7dca8512，route的值與后端服務器對應，可能是明文，也可能是md5、sha1等Hash值），返回給客戶端。
- 客戶端接收請求，并保存帶 route 的 cookie。
- 當客戶端下一次發送請求時，會帶上route。nginx 根據接收到的 cookie 中的 route 值，轉發給對應的后端服務器。
配置示例：
upstream backend { sticky expires=6h domain=devops.cn path=/; server 192.168.31.240:8080 weight=3 max_fails=3 fail_timeout=10s; server 192.168.31.241:8080 weight=3 max_fails=3 fail_timeout=10s; server 192.168.31.242:8080 weight=6 max_fails=3 fail_timeout=10s; server 192.168.31.243:8080; server 192.168.31.244:8080 down; }
配置說明：
- expires=1h 表示設置 Cookie 的過期時間為 1 小時，
- domain=devops.cn 表示 Cookie 在整個域名下都有效。
- path=/ 表示 Cookie 在整個網站路徑下都有效。
第一次訪問的時候是沒有Cookie的，第一次訪問完成后NGINX才會把Cookie包含在返回的數據中，在下次請求數據的時候就會出現Cookie。 所以刷新一下后才能看到Cookie。
參考：https://zhuanlan.zhihu.com/p/636707965
浙公網安備 33010602011771號