本文已收錄至Github，推薦閱讀 ?? Java隨想錄

微信公眾號：Java隨想錄

CSDN：碼農BookSea

DNS負載均衡
Nginx負載均衡
- 負載均衡演算法
- 負載均衡配置
- 超時配置
- 被動健康檢查與主動健康檢查
- LVS/F5+Nginx

當我們的應用單實體不能支撐用戶請求時，此時就需要擴容，從一臺服務器擴容到兩臺、幾十臺、幾百臺，此時我們就需要負載均衡，進行流量的轉發，下面介紹幾種負載均衡的方案，

DNS負載均衡

一種是使用DNS負載均衡，將域名映射多個IP，

用戶訪問時是通過如 https://www.baidu.com 的方式訪問，在請求時，瀏覽器首先會查詢DNS服務器獲取對應的IP，DNS服務器對每個查詢將以DNS檔案中主機記錄的IP地址按順序回傳不同的決議結果，將客戶端的訪問引導到不同的機器上去，使得不同的客戶端訪問不同的服務器，從而達到負載均衡的目的，

DNS還可以設定權重，我們可以將配置比較好的機器設定為高權重，

具體配置可以參考阿里云官方檔案：阿里云DNS負載均衡權重配置

優點：配置簡單，將負載均衡的作業交給了DNS服務器，省去了管理的麻煩，
缺點：DNS會有一定的快取時間，故障后切換時間長，

DNS存在一個問題，假設某臺服務器重啟或者出現故障，DNS會有一定的快取時間，故障后切換時間長，而且沒有對后端服務進行心跳檢查和失敗重試的機制，

例如：DNS快取了A記錄，假設我有一臺服務器壞了需要下線，即使修改了A記錄，要使其生效也需要較長的時間，這段時間，DNS仍然會將域名決議到已下線的服務器上，最終導致用戶訪問失敗，

關于DNS快取多久時間生效，可以參考阿里云的幫助檔案：決議生效時間FAQ

Nginx負載均衡

負載均衡演算法

一般用Nginx來做負載均衡比較多，

Nginx負載均衡是通過upstream模塊來實作的，內置實作了三種負載策略，配置還是比較簡單的，

輪循（默認）

Nginx根據請求次數，將每個請求均勻分配到每臺服務器，
最少連接

將請求分配給連接數最少的服務器，Nginx會統計哪些服務器的連接數最少，
IP Hash

每個請求按訪問IP的hash結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決session共享的問題，
fair（第三方模塊）

根據服務器的回應時間來分配請求，回應時間短的優先分配，即負載壓力小的優先會分配，

需要安裝nginx-upstream-fair模塊
url_hash（第三方模塊）

按訪問的URL的哈希結果來分配請求，使每個URL定向到一臺后端服務器，如果需要這種調度演算法，則需要安裝nginx_upstream_hash模塊，
一致性哈希（第三方模塊）

ip_hash演算法，在增加和服務器宕機時會導致會話和快取丟失，如果需要使用一致性哈希，則需要安裝ngx_http_consistent_hash模塊，

負載均衡配置

示例配置如下：

http {
    upstream myserve {
      # ip_hash; 表示使用ip hash負載均衡策略
        server 192.168.0.100:8080 weight=1 max_fails=2 fail_timeout=10;;
        server 192.168.0.101:8080 weight=2;
        server 192.168.0.102:8080 weight=3;
      # server 192.168.0.102:8080 backup; 
      # server 192.168.0.102:8080 down;
      # server 192.168.0.102:8080 max_conns=100;
    }
    
    server {
        listen 80;
        location / {
            proxy_pass http://myserve;
        }
    }
}

weight：weight是權重的意思，上例配置，表示6次請求中，分配1次，2次和3次，
max_fails：允許請求失敗的次數，默認為1，超過max_fails后，在fail_timeout時間內，新的請求將不會分配給這臺機器，
fail_timeout：默認為10秒，上訴代碼配置表示失敗2次之后，10秒內 192.168.0.100:8080不會處理新的請求，
backup：備份機，所有服務器掛了之后才會生效，如組態檔注釋部分，只有192.168.0.100和192.168.0.101都掛了，才會啟用192.168.0.102，
down：表示某一臺服務器不可用，不會將請求分配到這臺服務器上，該狀態的使用場景是某臺服務器需要停機維護時設定為down，或者發布新功能時，
max_conns：限制分配給某臺服務器處理的最大連接數量，超過這個數量，將不會分配新的連接給它，默認是0，表示不限制最大連接，它所起到的作用是防止服務器因連接過多而導致宕機，比如我給192.168.0.102分配100個連接請求，如果這臺服務器正在處理100個請求，nginx將不會分配新的請求給它，也就是同時處理的最大連接數量，

超時配置

proxy_connect_timeout：后端服務器連接的超時時間，默認是60秒，
proxy_read_timeout：連接成功后等候后端服務器回應時間，也可以說是后端服務器處理請求的時間，默認是60秒，
proxy_send_timeout：發送超時時間，默認是60S

被動健康檢查與主動健康檢查

Nginx負載均衡有個缺點，就是說Nginx的服務檢查是惰性的，Nginx只有當有訪問時后，才發起對后端節點探測，如果本次請求中，節點正好出現故障，Nginx依然將請求轉交給故障的節點，然后再轉交給健康的節點處理，所以不會影響到這次請求的正常進行，但是會影響效率，因為多了一次轉發，而且自帶模塊無法做到預警，

也就是說Nginx自帶的健康檢查是被動的，

如果我們想主動的去進行健康檢查，需要使用淘寶開源的第三方模塊：nginx_upstream_check_module，

Nginx會定時主動地去ping后端的服務串列，當發現某服務出現例外時，把該服務從健康串列中移除，當發現某服務恢復時，又能夠將該服務加回健康串列中，

示例配置如下：

upstream myserver {    
        server 192.168.0.100:8080;
        server 192.168.0.101:8080;
        check interval=5000 rise=2 fall=5 timeout=1000 type=http;    
        check_http_send"HEAD / HTTP/1.0\r\n\r\n";   check_http_expect_alive http_2xx http_3xx;
    }

interval間隔5s，連續失敗5次，連續成功2次，超時時間1s，使用http協議，發送一個請求頭，如果是2xx或者3xx狀態（比如200,302等）表示服務正常運行，

LVS/F5+Nginx

對于一般應用來說，有Nginx就可以了，但Nginx一般用于七層負載均衡，其吞吐量是有一定限制的，為了提升整體吞吐量，會在 DNS 和 Nginx之間引入接入層，如使用LVS（軟體負載均衡器)、F5（硬負載均衡器）可以做四層負載均衡，即首先 DNS決議到LVS/F5，然后LVS/F5轉發給Nginx，再由Nginx轉發給后端真實服務器，

比較理想的架構是這樣的：

對于一般業務開發人員來說，我們只需要關心到Nginx層面就夠了，LVS/F5一般由系統/運維工程師來維護，Nginx目前提供了HTTP (ngx_http_upstream_module）七層負載均衡，而1.9.0版本也開始支持TCP(ngx_stream_upstream_module)四層負載均衡，

一般用到F5的公司不多，大部分LVS+Nginx就可以搞定，

另外我抱著好奇心去谷歌了下F5設備的價格

╮(╯▽╰)╭ 這玩意要幾十萬一臺，看來不是一般人玩的起的，

本篇文章就到這里，感謝閱讀，如果本篇博客有任何錯誤和建議，歡迎給我留言指正，文章持續更新，可以關注公眾號第一時間閱讀，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/544425.html

標籤：其他

上一篇：C++學習-const

下一篇：類屬性和物件屬性