nginx의 부하를 분산하는 방법

1. Nginx 역방향 프록시

nginx 로드 밸런싱을 소개하기 전에 먼저 nginx 역방향 프록시를 소개하겠습니다. 역방향 프록시가 더 자주 사용되기 때문입니다. 따라서 앞으로는 소개하지 않겠습니다. 여기 요원.

nginx의 프록시 프로세스는 요청을 nginx로 보낸 다음 백엔드 서버로 요청을 전달하는 것입니다. 백엔드 서버가 처리를 완료한 후 결과를 nginx로 보냅니다. 그런 다음 nginx는 결과를 클라이언트로 보냅니다. 백엔드 서버는 원격 또는 로컬일 수도 있고 nginx 서버 내에 정의된 다른 가상 호스트일 수도 있습니다. nginx 전달을 받는 이러한 서버를 upstream

이라고 합니다. nginx를 프록시로 사용하는 목적 중 하나는 인프라 규모를 확장하는 것입니다. nginx는 많은 수의 동시 연결을 처리할 수 있습니다. 요청이 도착하면 nginx는 이를 처리를 위해 원하는 수의 백그라운드 서버로 전달할 수 있습니다. 이는 전체 클러스터에 로드 밸런싱을 분산하는 것과 같습니다.

구문: ​​Proxy_pass URL

설명: URL은 http://location:8000/uri/ 등의 형식일 수 있으며 위치에서 구성할 수 있습니다.

예: 간단한 역방향 프록시를 작성해 보겠습니다.

포트 80에서 수신하는 디렉터리에는 test_proxy 파일이 없지만 포트 8080에서 수신하는 디렉터리에는 test_proxy 파일이 있습니다. 저는 서버에 있습니다. 포트 80에서 다음을 추가합니다:

location ~ /test_proxy.html$ {proxy_pass http://127.0.0.1:8080;}

그런 다음 브라우저에 http://IP 주소/test_proxy.html을 입력하면 요청된 정보가 표시됩니다. 실제로 포트 80이 포트 8080으로 전달되고 데이터가 다시 요청됩니다.

2. 버퍼링

nginx는 성능 향상을 위해 버퍼링 메커니즘도 제공합니다. 버퍼링 없이 데이터는 백엔드 서버에서 클라이언트로 직접 전송됩니다. 버퍼링의 기능은 백엔드 서버의 처리 결과를 nginx에 임시로 저장하여 nginx에서 백엔드로의 연결을 조기에 종료하고 IO 손실을 줄일 수 있도록 하는 것입니다. 일반적으로 콘텐츠는 메모리에 저장되지만, 콘텐츠가 너무 많아 메모리가 부족한 경우 해당 콘텐츠는 임시 파일 디렉터리에 저장됩니다. 다음은 일반적으로 사용되는 버퍼링 구성 항목 중 일부이며 http, 서버 및 위치 콘텐츠 블록에서 찾을 수 있습니다.

proxy_buffering: 이 콘텐츠 블록에서 버퍼링을 활성화할지 여부를 제어합니다. 기본값은 "on"입니다.

proxy_buffers: 두 개의 매개변수가 있습니다. 첫 번째 매개변수는 버퍼 요청 수를 제어하고 두 번째 매개변수는 버퍼 크기를 제어합니다. 기본값은 8, 한 페이지(일반적으로 4k 또는 8k)입니다. 값이 클수록 더 많은 콘텐츠가 버퍼링됩니다.

proxy_buffer_size: 백엔드 응답 결과의 첫 번째 세그먼트(헤더가 포함된 부분)를 별도로 버퍼링하는 구성입니다. 이 값의 기본값은 proxy_buffer와 동일한 값입니다. 일반적으로 헤더 내용이 적기 때문에 더 작게 설정할 수 있습니다.

proxy_busy_buffers_size: "클라이언트 준비"로 표시된 버퍼의 크기를 설정합니다. 클라이언트는 한 번에 하나의 버퍼에서만 데이터를 읽을 수 있으며 버퍼는 대기열 순서에 따라 일괄적으로 클라이언트에 전송됩니다. 이 구문은 이 대기열의 크기를 구성합니다.

proxy_temp_path: nginx 저장소 임시 파일 경로를 정의합니다.

proxy_max_temp_file_size: 요청당 임시 파일을 저장할 수 있는 디렉터리의 크기입니다. 업스트림에서 보낸 결과가 너무 커서 버퍼에 맞지 않으면 nginx는 이를 위한 임시 파일을 만듭니다.

3. 로드 밸런싱

구성 구문: 업스트림 이름 {.....}

설명: name은 사용자 정의 이름이고, {}는 정의되어야 합니다. 콘텐츠는 정의만 가능합니다. 서버 블록이 아닌 http 블록에 있습니다. 이를 정의한 후 위치 블록 아래에 http://name이라는 코드를 작성하여 호출할 수 있습니다.

예: 서버 수의 제한으로 인해 여기서는 한 서버의 서로 다른 포트를 사용하여 로드 밸런싱을 시뮬레이션합니다. 물론 여러 서버의 구성은 유사합니다.

서버 블록에 다음 코드를 추가하세요:

upstream test {#ip_hashserver IP:8001;server IP:8002; 서버 IP:8003 ; }

그런 다음 http 블록의 위치에 다음 콘텐츠를 추가합니다.

#호스트 헤더 및 클라이언트 실제 설정 서버가 클라이언트의 실제 IP를 얻을 수 있도록 proxy_set_header 호스트 $http_host; proxy_set_header proxy_read_timeout 60; Proxy_buffer_size 32k; #버퍼 크기 설정 proxy_buffering on; proxy_buffers 4 128k; #버퍼 수 및 크기 설정 Proxy_busy_buffers_size 256k; #클라이언트 준비 버퍼 크기 설정 proxy_max_temp_file_size 256k;proxy_pass #위에서 설정한 로드 밸런싱 호출 }물론, 우리가 설정한 IP 포트는 구성 파일에 미리 구성되어 있다는 점을 기억해두셔야 합니다. 예를 들어 다음과 같은 구성이 있습니다.

그런 다음 호스트 주소를 방문하고 계속 새로 고치면 각 포트에서 나오는 페이지 정보를 찾을 수 있습니다. 기본 로드 밸런싱은 폴링을 사용합니다.

로드 밸런싱을 위해 다른 서버를 사용하는 경우 다음 구성과 같이 약간만 변경하면 됩니다.

upstream mydomain.com{server 47.95.242.167:80;server 47.95.242.168:80;server 47.95.242.169:80;}

구성하고 나면 무엇이 남나요? http의 코드는 위와 유사하며 나머지 세 서버는 다음과 같이 구성합니다. 물론, 세 서버에도 방화벽을 설정해야 합니다.

server{listen 80;server_name www.mydomain.com; index index.html index.html;루트 디렉터리 경로;

①로드 밸런싱 스케줄링 시 백엔드 서버 상태

dowm: 현재 서버는 일시적으로 로드 밸런싱에 참여하지 않습니다.

백업: 예약된 백업 서버.

max_fails: 허용된 요청 실패 횟수입니다.

fail_timeout: max_fails 실패 후 서버가 일시 중지되는 시간입니다.

max_conns: 최대 연결 수신 수를 제한합니다.

참고: 위 구성은 업스트림 중에 구성됩니다. 예를 들어, {}에 추가된 서버 IP: 8001 dowm은 이 서비스가 로드 밸런싱에 참여하지 않고 백업에 사용된다는 의미입니다. 서비스 뒤에.

②스케줄링 알고리즘

폴링: 시간순으로 하나씩 다른 백엔드 서버에 할당됩니다.

가중 폴링: 구성된 서버 뒤에 가중치=숫자를 추가할 수 있습니다. 숫자 값이 높을수록 할당 확률이 높아집니다.

ip_hash: 각 요청은 액세스 IP의 해시에 따라 할당되므로 동일한 IP에서 백엔드 서버로의 액세스가 고정됩니다.

least_hash: 최소 링크 수, 연결 수가 가장 적은 머신이 해당 머신에 배포됩니다.

url_hash: 방문한 URL의 해시 결과에 따라 요청을 배포하여 각 URL이 동일한 백엔드 서버로 연결되도록 합니다.

해시 키 값: 해시 사용자 정의 키.

참고: 예약 알고리즘은 업스트림 설정에서 구성됩니다. 예를 들어 중괄호 안에 ip_hash를 쓰면 ip_hash 할당을 사용한다는 의미입니다.

더 많은 Nginx 관련 기술 문서를 보려면 Nginx 튜토리얼을 방문하세요. 학습을 위한 칼럼!

위 내용은 nginx의 부하를 분산하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!