nginx 로드 밸런싱 전략 및 구성

이 글은 주로 참고할만한 가치가 있는 nginx 로드 밸런싱 전략과 구성을 소개합니다. 이제 모든 사람들과 공유하겠습니다. 도움이 필요한 친구들이 참고할 수 있습니다.

서문

먼저 로드 밸런싱이 무엇인지 간략하게 알아보겠습니다. , 문자 그대로의 의미로 이해하면 N 서버가 부하를 균등하게 공유하며, 특정 서버의 부하가 높아 특정 서버가 유휴 상태가 되지 않는다는 의미로 설명할 수 있습니다. 그러면 로드 밸런싱의 전제는 여러 서버에서 달성할 수 있다는 것입니다. 즉, 두 대 이상의 서버이면 충분합니다. 로드 밸런싱은 동시성, 트래픽이 많은 웹사이트에 구현해야 하는 기술입니다.

환경

두 머신 로드 밸런싱 배포 사용

테스트 도메인 이름 : a.com

AServerIP: 10.1 .108.31 A 서버가 기본 서버 역할을 하며 도메인 이름은 로 직접 확인됩니다. A 서버(

10.1.108.31 )에서 A 서버는 자체적으로 로드 밸런싱됩니다. (

10.1.108.31 ) 및 B

서버( 192.168.112.128)가 우수합니다. 로드 밸런싱이 필요한 프로젝트nodejs web 프로젝트, 프로젝트 이름social, 포트 6602.

A 서버와 B

서버에서 각각 social 프로젝트를 시작합니다(여기에서는 nodejs 프로젝트 시작 방법을 소개하지 않습니다). A 서버 설치

nginx

(설치 방법은 여기서 소개하지 않습니다. B서버는 설치가 필요하지 않습니다.) Deployment도메인 이름 확인실제 환경이 아니므로 테스트용으로 도메인 이름 a.com을 사용하므로 해상도는 a.com 는 hosts

파일 설정에서만 가능합니다.

열기:

C:WindowsSystem32driversetchosts

끝에

10.1.108.31 a.com을 추가하세요.

저장하고 종료한 다음 명령 모드를 시작하세요. ping 설정이 성공했는지 확인하세요

스크린샷에서 a.com이 성공적으로 로 확인되었음을 알 수 있습니다. 10.1.108.31

구성 nginx.conf

nginx 설치 디렉토리의 conf 디렉토리에서 nginx.conf 파일

httpsection Join 다음 코드

upstream a.com {

            server 127.0.0.1:6602;

            server 192.168.112.128:6602;

        }

server {

        listen       80;

        location / {

            proxy_pass http://a.com;      #设置反向代理的地址

            proxy_connect_timeout 2;      #代理服务器超时时间，秒

참고:

2 노드 중 하나가 다운되었습니다. nginx는 여전히 요청을 It에 배포합니다. 시간이 초과될 때까지 응답이 없으면 다른 노드로 보냅니다. 기본적으로 1분 이내에는 더 이상 요청이 전송되지 않으며, 1분 후에 위 작업이 반복됩니다. 결과적으로 웹사이트는 때로는 빠르기도 하고 때로는 느려지기도 합니다. 구성을 저장하고, nginx을 시작하고,

a.com

을 방문하세요.                                                                        사진 2위 사진과 같이 a.com

을 각각 2번씩 방문하였습니다.

A

server 및

Bserver에서는 반환됩니다. nginx 로드 밸런싱 구성이 성공했음을 나타냅니다. nginx 구성 세부 정보

        }

user    www-data;                        #运行用户worker_processes  4;                   #启动进程,通常设置成和cpu的核数相等

worker_cpu_affinity 0001 0010 0100 1000;   #为每个进程绑定cpu内核，参考下面注解1

error_log  /var/log/nginx/error.log;   #全局错误日志pid        /var/run/nginx.pid;          #PID文件

#events模块中包含nginx中所有处理连接的设置

events {                            
   use   epoll;  #连接处理方式，参考注解2

  worker_connections  1024;    #单个后台worker process进程的最大并发链接数，不能超过最大文件打开数，最大文件打开数可以通过worker_rlimit_nofile修改。  multi_accept on;   #on:worker process一次接受所有新连接, off: 一次接受一个新的连接

}

#设定http服务器，利用它的反向代理功能提供负载均衡支持

http {
     
    include       /etc/nginx/mime.types;       #设定mime类型,类型由mime.type文件定义

   include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;

    default_type  application/octet-stream;  #默认文件类型

   #charset utf-8; #默认编码

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  logs/access.log  main;       #设定日志格式

    
    sendfile        on;   #开启高效文件传输模式，sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，对于普通应用，必须设为 on,如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，以平衡磁盘与网络I/O处理速度，降低系统的负载.注意：如果图片显示不正常把这个改成off。

   #防止网络阻塞，两者区别参考注解3    tcp_nopush     on;

   tcp_nodelay        on;

autoindex on; #开启目录列表访问，合适下载服务器，默认关闭。    keepalive_timeout  30;                 #连接超时时间，单位秒

nginx 구성 주석

1.worker_cpu_affinity

annotation

Nginx

사용률은 기본 CPU에 의해 활성화되지 않습니다.우리는 할 수 있습니다 멀티 코어 CPU를 최대한 활용하려면 매개변수를 구성하여 작업자_cpu_affinity를 늘립니다. CPU는 작업 처리 및 계산에 가장 중요한 리소스입니다. CPU 코어가 많을수록 성능이 향상됩니다. Nginx 멀티 코어 CPU, 작업자_cpu_affinity 사용 방법 및 예제 구성

2

core CPU
, 시작

2

프로세스 worker_processes 2;worker_ c pu_affinity 01 10;

01은 첫 번째 CPU 코어 활성화를 의미하고, 10은 두 번째 CPU 코어 활성화를 의미합니다.
worker_cpu_affinity 01 10은 두 프로세스 시작을 의미하며, 첫 번째 프로세스는 첫 번째 CPU 코어에 해당하고 두 번째 프로세스는 두 번째 CPU에 해당합니다. 핵심.

2코어 CPU,4개 프로세스 열기
worker_processes 4;
worker_cpu_affinity 01 10 01 10;

4개 프로세스를 열면 각각 2번 열기에 해당합니다. CPU 코어

4코어 CPU, 계정 4 프로세스
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

000 1은 첫 번째 CPU 활성화를 의미합니다. 0010은 처음 2개의 CPU 코어를 활성화한다는 의미입니다. 등등

4코어 CPU, 2개 프로세스 열기
worker_processes 2;
worker_cpu_affinity 0101 1010;

0101 은 열기를 의미합니다. 첫 번째와 세 번째 세 개의 코어, 1010은 개방을 의미합니다. 두 번째 및 네 번째 코어
2 프로세스는 4개의 코어
에 해당합니다.worker_cpu_affinity 구성은 /etc/nginx/nginx.conf에 작성됩니다.
2코어는 01, 4코어는 0001, 8코어는 00000001입니다. 코어 수에 따라 여러 자리가 있습니다. 1은 코어가 켜져 있음을 의미하고, 0은 코어가 꺼져 있음을 의미합니다.

8코어 CPU, 8개 프로세스를 담당
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 0001000 0 0 010000001000000 10000000;

0001은 첫 번째 CPU 코어 활성화를 의미하고, 0010은 두 번째 CPU 코어를 활성화하는 등
worker_processes는 최대 8개까지 열 수 있습니다. 8개 이상의 성능 향상은 개선되지 않고 안정성도 떨어지므로 프로세스 8개이면 충분합니다.

2.연결 처리 방법

nginx 은 여러 연결 처리 방법을 지원하며, 사용 방법은 사용되는 시스템에 따라 다릅니다. 시스템이 여러 방법을 지원하는 경우 nginx는 가장 효율적인 방법을 자동으로 선택합니다. 필요한 경우 use 지시문을 통해 사용할 방법을 지정할 수 있습니다.

select:

1.SocketQuantitylimit:이 모드가 작동할 수 있는 Socket 개수는 FD_SETSIZE에 의해 결정됩니다. ,커널 default 30
Socket예 활성 , 이 모두 통과됩니다 .

poll:

1.Socket수는 거의 무제한입니다:이 모드에서 fd에 해당하는 Socket 다음 사람이 목록을 저장합니다. 배열 ,크기 제한 없음(default4k)
2.작업 제한:과 동일을 선택합니다. epoll:

Linux 2.6 버전 이상

1.Socket

수량 무제한: Poll 2.작동 무제한과 동일:
에서 제공하는 반사 모드를 기반으로 kernel , 이 활성 상태일 때 Socket, 커널은 Socket의 콜백에 액세스합니다. 은 폴링을 통과할 필요가 없습니다. . kque ue

：

은 epoll

과 크게 다르지 않습니다. 원칙은 동일하며 운영 체제에서 사용됩니다: FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 및 맥OS X

select 모드가 비효율적인 이유
select 모드 비효율성은 select의 정의에 의해 결정되며 운영 체제 구현과 관련이 없습니다. select CPU를 소모하는 socket의 상태를 확인하려면 라운드 로빈을 수행해야 합니다. 또한 socket의 큰 컬렉션이 있는 경우 socket 중 일부만 "active" 상태인 경우에도 다음을 수행할 수 없습니다. 모든 소켓을 하나의 FD_SET으로 채우지 마세요. 그러면 일부 cpu도 소모되며, select가 반환되면 비즈니스를 처리할 때 작업을 수행해야 할 수도 있습니다 " 컨텍스트 매핑"도 성능에 어느 정도 영향을 미치므로 select는 epoll보다 상대적으로 비효율적입니다.
epoll은 소켓이 많지만 활동량이 그리 높지 않은 경우에 적용할 수 있습니다.

3. tcp_nodelay과 tcp_nopush

tcp_nodelay

Nginx의 차이점 TCP_NODELAY 옵션은 새 소켓을 열 때 추가됩니다. TCP_NODELAY 옵션.

그러나 이로 인해 상황이 발생합니다.

터미널 응용 프로그램은 작업이 발생할 때마다 패킷을 보내며 일반적으로 패킷에는 1바이트의 데이터와 40바이트 길이의 패킷 헤더가 있습니다. 4000%의 과부하가 발생하여 네트워크 정체가 쉽게 발생할 수 있습니다.

이를 방지하기 위해 TCP스택은 데이터 0.2초 대기를 구현하므로 작업 후에는 패킷을 보내지 않지만 이 기간 내의 데이터는 큰 가방이 됩니다.

이 메커니즘은 Nagle 알고리즘에 의해 보장됩니다.

Nagle화는 나중에 표준이 되었고 인터넷에서 즉시 구현되었습니다. 이제는 기본 구성이지만 이 옵션을 끄는 것이 바람직한 상황이 있습니다.

이제 애플리케이션이 요청을 하고 작은 데이터 덩어리를 전송하려고 한다고 상상해 보세요. 즉시 데이터를 보내거나 더 많은 데이터가 생성될 때까지 기다렸다가 다시 보내도록 선택할 수 있습니다.

대화형 및 클라이언트 /서버 기반 애플리케이션은 데이터를 즉시 전송하면 큰 이점을 얻을 수 있습니다. 요청이 즉시 이루어지면 응답 시간이 더 빨라집니다.

위 작업은 소켓의 TCP_NODELAY = on 옵션을 설정하여 Nagle 알고리즘을 비활성화하여 완료할 수 있습니다.  

모든 데이터를 네트워크를 통해 한 번에 전송하기 전에 데이터 양이 최대치에 도달할 때까지 기다려야 하는 경우도 있습니다. 이 데이터 전송 방법은 대용량 데이터의 통신 성능에 유리합니다. 파일 서버입니다.

Nginx 는 keepalive 와 연결하여 TCP_NODELAY 을 사용합니다. keepalive 데이터가 전송된 후에도 연결이 유지되며 이를 통해 더 많은 데이터를 전송할 수 있습니다.

이 방법으로 더 적은 소켓 연결과 각 연결에 대한 3방향 핸드셰이크 프로세스를 인스턴스화할 수 있습니다.

tcp_nopush

nginx , tcp_nopush 구성 및 tcp_nodelay . 한 번에 전송되는 데이터의 패킷 크기를 구성할 수 있습니다.

즉, 누적된 시간을 기준으로 0.2 초 이후에는 패킷을 보내지 않고, 일정 크기만큼 패킷이 쌓이면 보내게 됩니다.

In nginx , tcp_nopush 은 sendfile 과 함께 사용해야 합니다.

4.로드 밸런싱

nginx은 다음 로드 밸런싱 메커니즘을 지원합니다:

1)round-robin: 폴링. 폴링 방식으로 요청을 다른 서버에 배포합니다. 기본값은 폴링입니다.

2）least-connected：最少连接数。将下一个请求分配到连接数最少的那台服务器上。

3）ip-hash ：基于客户端的IP地址。散列函数被用于确定下一个请求分配到哪台服务器上。

在一些要求需要更长的时间才能完成的应用情况下，最少连接可以更公平地控制应用程序实例的负载。使用最少连接负载均衡，nginx不会向负载繁忙的服务器上分发请求，而是将请求分发到负载低的服务器上。配置如下：

upstream mysvr {

   least-connected
  server 192.168.8.1:3128
  server 192.168.8.2:80
  server 192.168.8.3:80
}

위 내용은 nginx 로드 밸런싱 전략 및 구성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!