Nginx는 고성능 Http 및 역방향 프록시 서버이기도 하며, 이 제품을 개발한 초기 목적 중 하나입니다. 또한 메일 프록시 서버 역할도 합니다. 안정성, 풍부한 기능 세트, 샘플 구성 파일, 낮은 시스템 리소스 소비 및 높은 동시성 성능으로 인해 다양한 프로덕션 배포에 널리 사용됩니다. 또한 nginx는 이벤트 중심 모델(epoll)을 기반으로 I/O 다중화를 구현하고 비동기 및 비차단 방식으로 요청을 처리합니다. 연결 동시성이 높은 경우 Nginx는 Apache 서버의 좋은 대안입니다. 그리고 왜 Nginx를 선택해야 할까요?
높은 안정성(연중무휴 실행 가능)
강력한 확장성(고도의 모듈식 설계, 원활한 모듈 추가) 웹 서버로서: Apache에 비해 Nginx는 더 적은 리소스를 사용하고 더 많은 동시 연결을 지원합니다.
로드 밸런싱 서버로서: 가상 호스트 및 URL 재로딩, 지원 네트워크 모니터링 등을 지원하도록 사용자 정의 및 구성할 수 있습니다. .
Nginx는 설치가 매우 간단하고 구성 파일이 매우 간결하며(Perl 구문도 지원 가능) 버그가 거의 없습니다.
정적 파일, 인덱스 파일 및 자동 색인 생성을 처리합니다. 역방향 프록시 가속(캐시 없음), 간단한 로드 밸런싱 및 내결함성
핫 배포를 지원합니다(서버를 중지하지 않고도 nginx를 업그레이드할 수 있음).
3. Nginx 로드 밸런싱
이라고 합니다. Nginx는 로드 밸런싱 서버로서 역방향 프록시를 사용하여 여러 백엔드 서버의 로드 밸런싱을 수행합니다. 먼저 Nginx 로드 밸런싱 전략과 로드 밸런싱 알고리즘에 대해 이야기해 보겠습니다.
upstream 이 모듈은 프록시 서버 주소 집합을 작성한 후(즉, 정의된 백엔드 서버 목록에서 사용자 요청을 수락할 서버를 선택) 로드 밸런싱 알고리즘을 구성하는 모듈입니다. 가장 기본적인 로드 밸런싱 예시를 살펴보겠습니다.3.2 Nginx 로드 밸런싱 전략upstream test { server 10.20.151.114:80; server 10.20.151.115:80; } server { .... location / { proxy_pass http://test; --请求转向 test 定义的服务器列表 }로그인 후 복사
가장 기본적인 구성 방법, 위 예시는 기본 로드 밸런싱인 폴링 방법입니다. 업스트림 모듈 기본 정책. 각 요청은 시간순으로 하나씩 다른 백엔드 서버에 배포됩니다. upstream test {
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}
upstream test {
ip_hash; --同一个IP客户端固定访问一个后端服务器
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}(3) url_hash
upstream test {
hash $request_uri; --实现每个url定向到同一个后端服务器
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}(4) 최소_conn
은 연결 수가 적은 백엔드 서버로 요청을 전달합니다. 폴링 알고리즘은 각 백엔드에 요청을 균등하게 전달하여 로드가 거의 동일하게 만듭니다. 그러나 일부 요청은 시간이 오래 걸리므로 해당 요청이 위치한 백엔드의 로드가 더 높아집니다. 이 경우, less_conn은 더 나은 로드 밸런싱 효과를 얻을 수 있습니다.
upstream test {
least_conn; --把请求转发给连接数较少的后端服务器
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
}(5) Weight
가중치 방법은 폴링 전략에 따라 폴링 확률을 지정합니다.
upstream test {
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2; --轮询的几率相对上一条要大
}(6) fair
이 알고리즘은 페이지 크기와 로딩 시간을 기반으로 로드 밸런싱을 지능적으로 수행할 수 있습니다. 즉, 백엔드 서버의 응답 시간을 기반으로 요청을 할당하고 응답 시간이 짧은 요청의 우선 순위를 지정할 수 있습니다.
upstream test {
server 10.20.151.114:80; weight=1;
server 10.20.151.115:80; weight=2;
fair; --实现响应时间短的优先分配
}max_fails: 허용되는 요청 실패 횟수, 기본값은 1입니다. 최대 횟수를 초과하면 Proxy_next_upstream 모듈에서 정의한 오류가 반환됩니다.
fail_timeout: max_fails 실패가 발생한 후 서비스를 일시 중지하는 시간 단위는 초입니다. max_fails는 failure_timeout과 함께 사용할 수 있습니다.
Nginx可分为二层、三层、四层、七层负载均衡。 所谓的二层就是基于MAC地址的负载均衡， 三层就是基于IP地址的负载均衡，四层就是基于IP+端口的负载均衡，七层就是基于URL等应用层信息的负载均衡。因篇幅较长这里不再做具体的介绍，有兴趣的可自行百度。这里以七层负载均衡来做实例。
环境准备：准备3台Nginx服务器，一台作为负载均衡服务器，其它两台作为后端服务器。
10.20.151.240 ----proxy_server（负载均衡服务器）
10.20.151.112 ----server1（后端服务器1）
10.20.151.113 ----server2（后端服务器2）
（1）负载均衡服务器配置
vim /etc/nginx/nginx.conf --配置主配置文件 vim /etc/nginx/conf.d/test.conf --配置子配置文件
（2）后端服务器配置
vim /usr/local/nginx/conf/nginx.conf --修改配置文件 vim /usr/local/nginx/html/index.html --添加测试数据
（3）负载均衡测试
在浏览器端访问http://10.20.151.240/，在实际生产中，这两个页面返回的结果是一样的，这里是为了测试效果，所以返回了不同的内容。而为什么刷新后又会返回不同结果呢？那是因为负载均衡默认的均衡策略（或算法）是轮询，所以每刷新一次就会从不同的后端服务器返回不同的请求结果，减轻单个后端服务器的访问量，提升客户端的访问效率，从而达到负载均衡的效果。
当我添加权重（weight）时
再次访问http://10.20.151.240/
加权重和没加权重有什么区别呢？在实际生产中，我们一般会将配置较高的服务器的权重设置高一点，其实就是客户端在访问时，权重较高的服务器会被多次请求，这样能减轻配置较低的服务器的请求量，从而更好的实现负载均衡。
当我添加backup状态参数时
再次访问http://10.20.151.240/
此时我故意停掉第一台后端服务器，继续访问http://10.20.151.240/
当我给113这台后端服务器添加backup后，它就会作为热备服务器，添加的主要目的就是当我其他后端服务器都宕机的情况下，我的热备服务器还能继续提供同样的服务（注意：在其他后端服务器还未宕机之前，该热备服务器是不工作的）。因此负载均衡不仅能达到各个后端服务器负载的均衡，同时通过配置相关转态参数还能保证客户端请求时不造成服务器宕机的情况，保证了后端服务器的稳定性。其他状态参数这里我不再做演示（因为配置方式都一样）。
위 내용은 Nginx가 로드 밸런싱을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
