집 > 기사 > 백엔드 개발 > Nginx는 어떻게 로드 밸런싱을 수행합니까? nginx 로드 밸런싱 알고리즘 요약(코드 포함)

Nginx는 어떻게 로드 밸런싱을 수행합니까? nginx 로드 밸런싱 알고리즘 요약(코드 포함)

不言원래의: 2018-07-25 16:29:225666검색

Nginx 로드 밸런싱을 수행하는 방법은 무엇입니까? 실제로 Nginx 로드 밸런싱을 구현하는 방법은 여러 가지가 있습니다. 이제 Polling, Weight, ip_hash, Fair 및 url_hash의 5가지 알고리즘을 포함하여 Nginx 로드 밸런싱 알고리즘을 자세히 소개하겠습니다.

1. Nginx 로드 밸런싱 알고리즘

1. 폴링(기본값)

각 요청은 시간순으로 하나씩 다른 백엔드 서비스에 할당됩니다. 백엔드 서버가 충돌하면 결함이 있는 시스템이 발생합니다. 사용자 액세스가 영향을 받지 않도록 자동으로 제거됩니다.

2. 가중치(폴링 가중치)

가중치 값이 클수록 부여되는 접속 확률이 높아집니다. 백엔드 내 각 서버의 성능이 불균형할 때 주로 사용됩니다. 또는 호스트 리소스를 합리적이고 효과적으로 활용하기 위해 마스터-슬레이브 상황에서 서로 다른 가중치를 설정하세요.

3. ip_hash

각 요청은 접속 IP의 해시 결과에 따라 할당되므로 동일한 IP의 방문자는 백엔드 서버에 고정된 접속을 할 수 있으며 동적 웹의 세션 공유 문제를 효과적으로 해결할 수 있습니다. 페이지.

4. fair

가중치 및 ip_hash보다 더 지능적인 로드 밸런싱 알고리즘인 Fair 알고리즘은 페이지 크기와 로딩 시간에 따라 지능적으로 로드 밸런싱을 수행할 수 있습니다. 즉, 백엔드 서버의 응답 시간에 따라 요청을 할당합니다. , 짧은 응답 시간 우선 할당을 사용합니다. Nginx 자체는 fair를 지원하지 않습니다. 이 스케줄링 알고리즘이 필요한 경우 upstream_fair 모듈을 설치해야 합니다.

5. url_hash

접근한 URL의 해시 결과에 따라 요청을 할당하여 각 URL이 백엔드 서버로 연결되도록 하여 백엔드 캐시 서버의 효율성을 더욱 향상시킬 수 있습니다. Nginx 자체는 url_hash를 지원하지 않습니다. 이 예약 알고리즘이 필요한 경우 Nginx 해시 소프트웨어 패키지를 설치해야 합니다.

1. 폴링(기본값)

각 요청은 시간순으로 하나씩 다른 백엔드 서버에 할당되며, 백엔드 서버가 다운되면 자동으로 제거될 수 있습니다.

2.weight

폴링 확률을 지정하며 가중치는 액세스 비율에 비례하며 백엔드 서버 성능이 고르지 않을 때 사용됩니다.
예:

upstream bakend {  
server 192.168.0.14 weight=10;  
server 192.168.0.15 weight=10;  
}

3.ip_hash

각 요청은 액세스한 IP의 해시 결과에 따라 할당되므로 각 방문자는 백엔드 서버에 대한 고정 액세스 권한을 갖게 되어 세션 문제를 해결할 수 있습니다.
예:

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

4.fair (third party)

요청은 백엔드 서버의 응답 시간에 따라 할당되며, 응답 시간이 짧은 요청이 먼저 할당됩니다.

upstream backend {  
server server1;  
server server2;  
fair;  
}

5.url_hash (타사)

접속한 URL의 해시 결과에 따라 요청을 배포하여 각 URL이 동일한 백엔드 서버로 연결되도록 하는 것이 백엔드 서버를 캐시할 때 더욱 효과적입니다.
예: 업스트림에 해시 문을 추가합니다. 서버 문에는 hash_method가 사용되는 해시 알고리즘입니다.

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

2 Nginx 업스트림에서. 모듈을 사용하면 로드 밸런싱 스케줄링에서 각 백엔드 서버의 상태를 설정할 수 있습니다. 일반적으로 사용되는 상태는 다음과 같습니다.

1. 다운, 현재 서버가 당분간 로드 밸런싱에 참여하지 않음을 나타냅니다. 2. 백업, 예약된 백업 머신 . 백업이 아닌 다른 머신이 모두 실패하거나 바쁜 경우 백업 머신이 요청되므로 이 머신의 액세스 압력이 가장 낮습니다

3. max_fails, 허용되는 요청 실패 횟수, 최대 개수가 실패할 때 기본값은 1입니다. 초과되면, proxy_next_upstream 모듈에 의해 정의된 오류를 반환합니다.

4. failure_timeout, 요청 실패 시간 초과, max_fails 실패 후 서비스를 일시 중단하는 시간입니다. max_fails와 failure_timeout을 함께 사용할 수 있습니다.

Nginx가 하나의 서버만 프록시할 수 없다면 오늘날만큼 인기가 없을 것입니다. Nginx는 여러 서버를 프록시하도록 구성할 수 있으며, 하나의 서버가 다운되더라도 시스템을 계속 사용할 수 있습니다. 구체적인 구성 과정은 다음과 같습니다.

1. http 노드 아래에 업스트림 노드를 추가합니다.

upstream linuxidc { 
      server 10.0.6.108:7080; 
      server 10.0.0.85:8980; 
}

2. 서버 노드 아래 위치 노드의 Proxy_pass를 http:// + 업스트림 이름, 즉 "

http://linuxidc"로 구성합니다.

location / { 
            root  html; 
            index  index.html index.htm; 
            proxy_pass http://linuxidc; 
}

3. 이제 로드 밸런싱이 처음으로 완료되었습니다. . 업스트림은 폴링(기본) 방식에 따라 로드됩니다. 각 요청은 시간순으로 하나씩 다른 백엔드 서버에 할당되며, 백엔드 서버가 다운되면 자동으로 제거될 수 있습니다. 이 방법은 간단하고 비용이 저렴합니다. 그러나 단점은 신뢰성이 낮고 부하 분산이 고르지 않다는 것입니다. 이미지 서버 클러스터 및 순수 정적 페이지 서버 클러스터에 적용 가능합니다.

또한 업스트림에는 다음과 같은 다른 유통 전략이 있습니다.

무게(무게)

指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。如下所示，10.0.0.88的访问比率要比10.0.0.77的访问比率高一倍。

upstream linuxidc{ 
      server 10.0.0.77 weight=5; 
      server 10.0.0.88 weight=10; 
}

ip_hash（访问ip）

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。

upstream favresin{ 
      ip_hash; 
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
}

fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。与weight分配策略类似。

upstream favresin{      
      server 10.0.0.10:8080; 
      server 10.0.0.11:8080; 
      fair; 
}

url_hash（第三方）

按访问url的hash结果来分配请求，使每个url定向到同一个后端服务器，后端服务器为缓存时比较有效。

注意：在upstream中加入hash语句，server语句中不能写入weight等其他的参数，hash_method是使用的hash算法。

 upstream resinserver{ 
      server 10.0.0.10:7777; 
      server 10.0.0.11:8888; 
      hash $request_uri; 
      hash_method crc32; 
}

upstream还可以为每个设备设置状态值，这些状态值的含义分别如下：

down 表示单前的server暂时不参与负载.

weight 默认为1.weight越大，负载的权重就越大。

max_fails ：允许请求失败的次数默认为1.当超过最大次数时，返回proxy_next_upstream 模块定义的错误.

fail_timeout : max_fails次失败后，暂停的时间。

backup：其它所有的非backup机器down或者忙的时候，请求backup机器。所以这台机器压力会最轻。

upstream bakend{ #定义负载均衡设备的Ip及设备状态 
      ip_hash; 
      server 10.0.0.11:9090 down; 
      server 10.0.0.11:8080 weight=2; 
      server 10.0.0.11:6060; 
      server 10.0.0.11:7070 backup; 
}

如果Nginx没有仅仅只能代理一台服务器的话，那它也不可能像今天这么火，Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。具体配置过程如下：

1. 在http节点下，添加upstream节点。

upstream linuxidc { 
      server 10.0.6.108:7080; 
      server 10.0.0.85:8980; 
}

2. 将server节点下的location节点中的proxy_pass配置为：http:// + upstream名称，即“
http://linuxidc”.

location / { 
            root  html; 
            index  index.html index.htm; 
            proxy_pass http://linuxidc; 
}

3. 现在负载均衡初步完成了。upstream按照轮询（默认）方式进行负载，每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。虽然这种方式简便、成本低廉。但缺点是：可靠性低和负载分配不均衡。适用于图片服务器集群和纯静态页面服务器集群。

除此之外，upstream还有其它的分配策略，分别如下：

weight（权重）