10. Nginx負載均衡

時間 2020-03-30

標籤 nginx 負載均衡欄目 Nginx 简体版

原文原文鏈接

請求分發詳解

配置負載均衡服務器集羣php

upstream backend {
  server x.x.x.x:1023;
  server x.x.x.x:1024;
  server x.x.x.x:1025;
}

對特定請求進行分發html

server {
  listen 1111;
  server_name www.siguoya.name;
  location / {
    proxy_pass http://backend;
  }
}

nginx負載均衡在分發請求的時候，默認會採用輪詢的方式。即：nginx

請求順序	請求分發
第一次訪問：http://www.siguoya.name:1111/	x.x.x.x:1023
第二次訪問：http://www.siguoya.name:1111/	x.x.x.x:1024
第三次訪問：http://www.siguoya.name:1111/	x.x.x.x:1025

假如Nginx原本要將請求分發到 x.x.x.x:1024 這臺服務器的，結果這臺服務器掛掉了，那麼Nginx就會將這次請求再分發到x.x.x.x:1025，避免影響到用戶訪問。git

Nginx負載均衡判斷後端服務器掛了的依據：github

首先，Nginx默認檢測後端服務的方式是基於通訊的，如：鏈接超時或者後端服務refuse都會標記爲服務有問題。
而後，若是Nginx須要作到基於狀態碼來判斷，你們能夠了解下這個模塊 proxy_next_upstream，能夠對後端響應40四、50二、50三、50四、500等狀態碼進行備用處理。
最後，若是還想要更好的完善後端的檢測機制，須要經過第三方模塊來作了，ngx_http_upstream_check_module

若是咱們想要測試某個服務器down掉，負載均衡會怎樣處理，能夠登陸到特定的後端服務器，執行以下命令，僞裝該服務器已經down掉：redis

iptables -A INPUT -p tcp --dport 1024 -j DROP

服務器配置詳解

upstream backend {
  #down表示當前的服務器暫時不可用，不參與負載均衡
  server www.aaa.com down;
  #max_conns=100表示此服務器的最大鏈接數爲100
  server www.bbb.com:1234 max_conns=100;
  #weight表示權重，權重越大，被分配到的次數就越多
  server www.ccc.com weight=3;
  #backup表示這是預留的備份服務器，只在其餘的節點都不可用的時候才啓用
  server www.ddd.com backup;
  #max_fails在連續超過3次失敗後，30秒內不要再分發請求到此服務器，默認fail_timeout爲10秒
  server x.x.x.x:8080 max_fails=3 fail_timeout=30s;
}

服務器調度詳解

方式	說明
輪詢	按時間順序逐一分配
加權輪詢	權重值越大，被分配到的次數就越多
ip_hash	請求按訪問IP的hash結果來分配，同一個IP固定的訪問某臺後端服務器
least_conn	哪臺服務器鏈接數少，就分發給哪臺服務器
url_hash	按照訪問URL的hash結果來分配，同一URL固定的訪問某臺後端服務器
hash關鍵數值	hash自定義的key

通過實際測試，ip_hash並不能徹底保持cookies的連續性，最好仍是將cookies存放在redis等內存型數據庫中

upstream heartide {
  ip_hash;
  server x.x.x.x:1023;
  server x.x.x.x:1024;
  server x.x.x.x:1025;
}

後端服務器定位

能夠經過以下方法，定位負載均衡到底將請求分配給了哪臺服務器，這有助於咱們針對後端集羣中特定的某臺服務器進行調試。shell

add_header Backend-Server $upstream_addr;

負載均衡服務搭建注意事項

採購後端集羣服務器時，最好都是購買同一地區的，例如阿里雲華南A區，省得跨區域，沒法直連Redis、RDS等
檢查後端集羣服務器的鏡像源，nginx.conf 中的 worker_processes、php.ini 中的 pm 參數等是否設置爲auto。若是都是 auto，則能夠買不一樣配置的服務器。若是不是，則須要修改相關配置文件，避免性能參數設置與機器硬件不相匹配
檢查後端集羣服務器的IP，是否全都放進了RDS、Redis、微信公衆平臺等各類服務的白名單。有條件的公司，能夠經過阿里雲 專有網絡+EIP+NAT 的解決方案，統一後端集羣服務器的出口IP
後端集羣服務器的各類日誌文件，儘可能放到阿里雲的 OSS 中，便於統一存儲、分析
若是須要保持用戶訪問的連續性，例如 cookies、用戶上傳的文件，這些數據都務必要存放到 Redis、OSS 等位置進行集中存儲
若是基於PHP之Laravel框架來開發，後端集羣服務器的鏡像源儘可能不要配置涉及具體業務代碼的任務調度，否則會致使代碼在不一樣機器間的重複執行，例如定時將Redis數據寫入到RDS數據庫中

參考文檔

使用阿里雲發佈分佈式網站，開發時候應該注意什麼？ https://www.opengps.cn/Blog/V...
阿里雲ECS，使用VPC網絡統一集羣網絡出口 https://www.jianshu.com/p/804...
阿里雲彈性伸縮 https://essnew.console.aliyun...
如何選擇公網類產品？ https://help.aliyun.com/docum...
關於access token 後端分佈式部署的中控服務器的問題 https://github.com/overtrue/w...

專題閱讀

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。