nginx 부하 균형 상용 정책

글 목록

1. 부하 균형 이 무엇 입 니까

2. 부하 균형 전략

1. 폴 링 (기본 값)

2. 가중치

3、ip_hash (IP 귀속)

4. fair (제3자 플러그 인)

5、url_hash (제3자 플러그 인)

3. 매개 변수 설명

4. 인 스 턴 스 설정:

부하 균형
한 서버 의 단위 시간 내 방 문 량 이 많 을 수록 서버 의 압력 이 커지 고 자신 이 감당 할 수 있 는 능력 을 초과 할 때 서버 가 붕 괴 됩 니 다.서버 붕 괴 를 피하 고 사용자 가 더 좋 은 경험 을 할 수 있 도록 부하 균형 을 통 해 서버 압력 을 분담 합 니 다.우 리 는 많은 서버 를 구축 하여 서버 클 러 스 터 를 구성 할 수 있 습 니 다. 사용자 가 사 이 트 를 방문 할 때 먼저 중간 서버 를 방문 하여 이 중간 서버 가 서버 클 러 스 터 에서 압력 이 적은 서버 를 선택 한 다음 에 이 방문 요청 을 이 서버 에 도입 할 수 있 습 니 다.이렇게 되면 사용자 의 매번 방문 은 서버 클 러 스 터 의 모든 서버 압력 이 균형 을 이 루 고 서버 압력 을 분담 하여 서버 붕 괴 를 피 할 수 있 습 니 다.
부하 균형 은 역방향 대리 의 원리 로 이 루어 진다.
2. 부하 균형 전략
1. 폴 링 (기본 값)
모든 요청 은 시간 순서에 따라 서로 다른 백 엔 드 서버 에 하나씩 배정 되 며, 백 엔 드 서버 다운 이 떨 어 지면 자동 으로 제거 할 수 있 습 니 다.

upstream backserver {
    server 192.168.0.14;
    server 192.168.0.15;
}

2. 가중치
폴 링 확률 을 지정 합 니 다. weight 와 방문 비율 은 정비례 하여 백 엔 드 서버 의 성능 이 고 르 지 않 습 니 다.정황

upstream backserver {
    server 192.168.0.14 weight=3;
    server 192.168.0.15 weight=7;
}

가중치 가 높 을 수록 방문 할 확률 이 높다. 예 를 들 어 상기 와 같이 각각 30%, 70% 이다.
3、ip_hash (IP 바 인 딩)
상기 방식 에 문제 가 있 습 니 다. 부하 균형 시스템 에서 사용자 가 특정한 서버 에 로그 인 하면 이 사용자 가 두 번 째 로 요청 할 때 저 희 는 부하 균형 시스템 이기 때문에 요청 할 때마다 서버 클 러 스 터 의 한 서버 로 다시 찾 습 니 다. 그러면 이미 한 서버 에 로그 인 한 사용 자 는 다른 서버 로 다시 찾 습 니 다.로그 인 정 보 를 잃 어 버 리 는 것 은 분명 타당 하지 않다.
우 리 는 ip 를 사용 할 수 있다.hash 명령 으로 이 문 제 를 해결 합 니 다. 만약 에 고객 이 특정한 서버 에 방문 했다 면 사용자 가 다시 방문 할 때 이 요청 을 해시 알고리즘 을 통 해 서버 로 자동 으로 찾 습 니 다.
모든 요청 은 ip 에 접근 하 는 hash 결과 에 따라 분 배 됩 니 다. 모든 방문객 이 백 엔 드 서버 에 고정 적 으로 접근 하면 session 문 제 를 해결 할 수 있 습 니 다.

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

4. fair (제3자 플러그 인)
백 엔 드 서버 의 응답 시간 에 따라 요청 을 분배 하고 응답 시간 이 짧 은 우선 분 배 를 합 니 다.

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

어느 서버 의 응답 속도 가 빠 르 면 그 서버 에 요청 을 할당 합 니까?
5、url_hash (제3자 플러그 인)
url 에 접근 한 hash 결과 에 따라 요청 을 할당 합 니 다. 모든 url 을 같은 백 엔 드 서버 로 지정 하고 백 엔 드 서버 가 캐 시 일 때 유효 합 니 다.

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

장면: 만약 에 지금 우리 전자상거래 프로젝트 에 폭발 품 이 생 긴 다 면 이 폭발 품 을 방문 하 라 는 요구 가 많아 질 것 이다.이 때 url hash 를 사용 하면 요청 이 같은 서버 에 눌 릴 수 있 습 니 다. 이것 은 분명 합 리 적 이지 않 습 니 다.
3. 매개 변수 설명

down: 현재 server 가 부하 에 잠시 참여 하지 않 음 을 나타 낸다

weight: 기본 값 은 1 입 니 다.weight 가 클 수록 부하 의 가중치 가 커진다.

max_fails: 요청 실패 횟수 를 기본 으로 1. 최대 횟수 를 초과 하면 proxy 로 되 돌려 줍 니 다.next_upstream 모듈 정의 오류

fail_timeout ：max_fails 회 실패 후 일시 정지 시간 입 니 다.

backup: 다른 모든 비 backup 기기 다운 이나 바 쁠 때 backup 기 계 를 요청 합 니 다.그래서 이 기계 의 압력 이 가장 가 벼 울 것 이다.

4. 인 스 턴 스 설정:

#user  nobody;
worker_processes  4;

events {
    #      
    worker_connections  1024;
}

http{

    #        
    upstream myproject{
        # ip_hash  ，            。
        ip_hash;
        server 125.219.42.4 fail_timeout=60s;
        server 172.31.2.183;
    }

    server{
        #     
        listen 80;
        #     
        location / {
            #          
            proxy_pass http://myproject;
        }
    }
    
}