Nginx負載均衡

摘要： 為什麼選擇負載均衡 現有網路的各個核心部分隨著業務量的提高，訪問量和資料流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的伺服器裝置根本無法承擔。僅僅是升級硬體的話拋開成本不談，效果也不見得一定好，因為業務是不斷增長的，單純的升級硬體解決不了效能的問題 針對此情況...

為什麼選擇負載均衡

現有網路的各個核心部分隨著業務量的提高，訪問量和資料流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的伺服器裝置根本無法承擔。僅僅是升級硬體的話拋開成本不談，效果也不見得一定好，因為業務是不斷增長的，單純的升級硬體解決不了效能的問題

針對此情況而衍生出來的一種廉價有效透明的方法以擴充套件現有網路裝置和伺服器的頻寬、增加吞吐量、加強網路資料處理能力、提高網路的靈活性和可用性的技術就是負載均衡（Load Balance）。

負載均衡方式

• 輪詢（預設）

  每個請求按時間順序逐一分配到不同的後端伺服器，如果後端伺服器down掉，能自動剔除。

  upstream backserver {
  server 192.168.0.14;
  server 192.168.0.15;
  }

• 按權重weight分配

  指定輪詢機率，weight和訪問比率成正比，用於後端伺服器效能不均的情況。

  upstream backserver {
  server 192.168.0.14 weight=3;
  server 192.168.0.15 weight=7;
  }

• ip_hash

  每個請求按訪問ip的hash結果分配，這樣每個訪客固定訪問一個後端伺服器，可以解決session的問題。

  upstream backserver {
  ip_hash;
  server 192.168.0.14:88;
  server 192.168.0.15:80;
  }

• url_hash(第三方)

  upstream backserver {
  server squid1:3128;
  server squid2:3128;
  hash $request_uri;
  hash_method crc32;
  }

  下面我來用自己的電腦和伺服器做測試

  1.本地nginx http配置

  upstream timeMachine.com {
  server 49.100.142.92:8001weight=3;
  server 49.100.142.92:520weight=1;
  }

  timeMachine.com要與下面server配置中location下的proxy_pass一直
  49.100.142.92是我個人的伺服器 8001埠是eoliner文件專案 520是一個canvas專案
  

  2.本地nginx server配置

  server {
  listen 80;
  server_name api.upstream.com;
  
  location / {
  proxy_pass http://timeMachine.com;
  proxy_redirect default;
  }
  
  }

  這裡的域名server_nameapi.upstream.com只是在hosts檔案配置了一下

  我們在本地瀏覽器多次訪問api.upstream.com ，測試結果是出現不同的專案，其中8001端口出現的次數較520埠多