Nginx負載均衡

Nginx(反向代理服務器)

正向代理

場景：在國內是無法正常使用google.com。如果想要訪問google.com，可以購買一台國外的服務器A，此時你和服務器A的網絡是相通的。而服務器A又跟google.com相通， 此時可以由服務器A代理你（客戶端），去訪問google.com。這個過程稱之為正向代理，服務端（google.com）只需要知道代理服務器的ip，不需要知道客戶端的ip。

示例1：

示例2：

 

結論：正向代理，是用於代理客戶端的。

反向代理

場景：當一個服務器接受過多來自客戶端的請求時，服務器難以處理和響應這些請求，會使得整個系統性能下降。為了解決這個難題，可以提供多台部署相同應用的服務器，讓客戶端的請求分別發送到不同的服務器上，這樣單機服務器的壓力就會降低很多，整體性能便會提升。但是有一個問題，每個服務器ip都是不同的，也就是說客戶端的請求要發送到多個不同的ip上。讓客戶手動指定ip進行請求，這種方式很不明智。首先是客戶的隨機性，不知道會訪問哪台服務器，其次，會造成一部分服務器壓力大，一部分服務器幾乎沒有使用，浪費資源。因此，這里就需要一個角色去代理服務器，讓客戶端的請求直接發送到這個角色上，由這個角色去分發請求到不同的服務器上。
這個角色就是反向代理服務器。

 

結論：反向代理，是用於代理服務端的。

負載均衡

場景：反向代理過程中，每台服務器處理來自客戶端的請求都應該是均衡的。
原理：使用一個反向代理服務器指向多台部署相同應用的服務器，客戶端請求直接向反向代理服務器發起，反向代理服務器根據負載均衡機制，將請求轉發到不同的應用服務器上。
負載均衡機制：

nginx提供了一下三種方法：
1）round-robin：請求以循環、輪轉的方式分發到服務器
2）least-connected：下一個請求被分配到擁有最少活動連接數的服務器
3）ip-hash：使用一個哈希函數，基於客戶端ip地址判斷下一個請求應該被分發到哪台服務器

相關配置說明
1）循環、輪轉負載均衡
round-robin：默認情況下，使用循環、輪轉的方式分發請求到服務器
配置示例：

http{
    upstream myapp{
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }
    server{
        listen 80;
        location / {
            proxy_pass http://myapp;
        }
    }
}

 

當不指定負載均衡方式時，默認以round-robin方式實現。所有請求都會被代理到myapp服務器，根據負載均衡機制分發請求。 

2）最少連接負載均衡
least-connected：當一些請求處理的時間比較長時，最少連接負載均衡能夠爭取到更大的公平。
配置示例：

upstream myapp{
    least-conn;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

 

3）基於ip地址的負載均衡 

ip-hash：采用目標地址散列調度（Destination Hashing Scheduling）算法，根據請求的目標ip地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器可用且未超載，則將請求發送帶服務器，否則返回空。

upstream myapp{
    ip-hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

 

Nginx和Zookeeper協同使用場景：https://blog.csdn.net/xiangjai/article/details/56844400 

1.單純使用Nginx，會造成配置維護成本變高。
2.單點故障率增加，因為熱點服務的訪問量很高，如果這個服務的負載均衡服務出現問題，整個服務都會掛點