Nginx 는 '놀 라 움' 현상 을 어떻게 해결 합 니까?

먼저 '놀 라 움' 현상 이 무엇 인지 설명 한다. 만약 에 여러 작업 프로 세 스 가 특정한 감청 세트 인 터 페 이 스 를 동시에 가지 고 있다 면 이 인터페이스 에 특정한 클 라 이언 트 요청 이 나타 나 면 이 인 터 페 이 스 를 가 진 모든 작업 프로 세 스 가 이 요 구 를 쟁탈 하 게 될 것 이다. 뺏 을 수 있 는 것 은 특정한 작업 프로 세 스 만 있 고 다른 작업 프로 세 스 는 반드시 공 을 세우 지 못 하고 돌아 갈 것 이다.이런 현상 은 바로 '놀 라 움' 이다.
Nginx 가 이러한 '놀 라 움' 현상 을 해결 하 는 데 사용 하 는 것 은 부하 균형 전략 이다. 그 다음 에 Nginx 의 소스 코드 와 결합 하여 Nginx 의 이러한 부하 균형 전략 을 상세 하 게 소개 한다.
우선 Nginx 가 부하 균형 정책 을 어떻게 시작 하 는 지 입 니 다. 물론 실행 중인 Nginx 가 다 중 프로 세 스 모델 이 라면 작업 프로 세 스 수가 1 보다 많 습 니 다.여러 작업 프로 세 스 가 하나의 인 터 페 이 스 를 다 툴 때 만 놀 라 움 과 균형 잡 힌 전략 이 필요 하 다 는 것 은 이해 하기 쉽다.

if (ccf->master && ccf->worker_processes > 1 && ecf->accept_mutex) {
        ngx_use_accept_mutex = 1;
        ngx_accept_mutex_held = 0;
        ngx_accept_mutex_delay = ecf->accept_mutex_delay;

    } else {
        ngx_use_accept_mutex = 0;
    }

그 중 변수 ngxuse_accept_mutex 는 부하 균형 정책 을 열 었 는 지 여 부 를 표시 하 는 데 사 용 됩 니 다.이곳 의 부하 균형 전략 은 '
전단 부하 균형 "클 라 이언 트 요청 을 작업 프로 세 스에 합 리 적 으로 분배 하 는 방법 에 사용 되 기 때 문 입 니 다.그리고 "
백 엔 드 부하 균형 '은 클 라 이언 트 요청 을 처리 하기 위해 백 엔 드 서버 를 합 리 적 으로 선택 하 는 정책 입 니 다.
다음은 부하 균형 전략 이 어떻게 '합 리 적' 으로 작업 프로 세 스에 분 배 될 것 인 지 를 소개 합 니 다. ngxprocess_events_and_timers () 는 다음 과 같은 코드 가 있 습 니 다.

 if (ngx_use_accept_mutex) {
        if (ngx_accept_disabled > 0) {
            ngx_accept_disabled--;

        } else {
            if (ngx_trylock_accept_mutex(cycle) == NGX_ERROR) {
                return;
            }

            if (ngx_accept_mutex_held) {
                flags |= NGX_POST_EVENTS;

            } else {
                if (timer == NGX_TIMER_INFINITE
                    || timer > ngx_accept_mutex_delay)
                {
                    timer = ngx_accept_mutex_delay;
                }
            }
        }
    }

이 코드 는 부하 균형 (즉, ngx use accept mutex = 1) 을 켜 야만 유효 합 니 다.이 논리 에서 우선 변수 ngx 검출 을 통 해accept_diabled 값 은 0 이상 으로 현재 프로 세 스 가 과부하 되 었 는 지 판단 할 수 있 습 니 다. 왜 이렇게 판단 할 수 있 습 니까? 변 수 를 이해 해 야 합 니 다 ngxaccept_diabled 값 의 의미, accept () 에서 새로운 연결 요청 을 받 아들 이 는 처리 함수 ngxevent_accept () 에서 볼 수 있 습 니 다.

 ngx_accept_disabled = ngx_cycle->connection_n / 8
                              - ngx_cycle->free_connection_n;

그 중 ngxcycle->connection_n. 작업 프로 세 스 의 최대 연결 수 를 표시 합 니 다. worker 를 통 해connections 명령 설정, 기본 값 512. 다른 변수 ngxcycle->free_connection_n 은 현재 사용 가능 한 연결 수 를 표시 합 니 다. 현재 활동 연결 수가 X 라 고 가정 하면 이 값 은 ngx 입 니 다.cycle->connection_n - X；그러므로 ngxaccept_diabled 의 값 은:

ngx_accept_diabled = X - ngx_cycle->connection_n * 7 / 8; 

즉, 현재 이벤트 연결 수 (X) 가 최대 연결 수 를 감당 할 수 있 는 7 / 8 을 초과 하면 과부하, 변수 ngxaccept_diabled 의 값 은 0 보다 크 고 이 값 이 클 수록 과부하 가 클 수록 현재 프로 세 스 의 부하 가 무 거 워 집 니 다.
돌아 가서 함수 ngxprocess_events_and_timers () 내 코드 입 니 다. 프로 세 스 가 과부하 상태 에 있 을 때 하 는 일 은 변수 ngx 에 불과 합 니 다.accept_diabled 자체 감소 1. 이것 은 한 차례 의 사건 처 리 를 거 친 이상 부하 가 줄 어 들 것 임 을 나타 내 므 로 해당 하 는 조정 변수 ngxaccept_diabled 의 값.일정 시간 경과, ngxaccept_diabled 는 0 이하 로 내 려 가 새로운 요청 연결 을 얻 을 수 있 습 니 다.따라서 연결 수 를 최대 로 감당 할 수 있 는 7 / 8 은 부하 균형 점 임 을 알 수 있다. 특정한 작업 프로 세 스 의 부하 가 이 임계 점 에 이 르 렀 을 때 상호 배척 자 물 쇠 를 가 져 와 다른 작업 프로 세 스에 부하 균형 을 맞 추 려 고 하지 않 는 다.
만약 에 프로 세 스 가 과부하 상태 에 있 지 않 으 면 자 물 쇠 를 다 투 게 됩 니 다. 물론 실제 적 으로 감청 세트 인터페이스의 감시 권 을 다 투 는 것 입 니 다. 자 물 쇠 를 다 투 는 데 성공 하면 모든 감청 세트 인 터 페 이 스 를 자신의 사건 감시 체제 에 넣 을 것 입 니 다 (원래 없 었 다 면).잠 금 경쟁 에 실패 하면 감청 세트 인 터 페 이 스 를 자신의 사건 감시 체제 에서 삭제 합 니 다 (원래 있 었 다 면).
변수 ngxaccept_mutex_held 의 값 은 현재 자물쇠 가 있 는 지 여 부 를 표시 하 는 데 사 용 됩 니 다. 이 점 을 주의 하 는 것 이 중요 합 니 다. 현재 자물쇠 가 있 으 면 flags 변수 가 NGX 를 치기 때 문 입 니 다.POST_EVENTS 태그, 이 는 발생 하 는 모든 사건 을 뒤로 미 루 겠 다 는 뜻 입 니 다.이것 은 모든 구조 디자인 이 반드시 지 켜 야 할 약속 이다. 즉, 자 물 쇠 를 가 진 사람 은 반드시 자신 이 자 물 쇠 를 가 지 는 시간 을 최대한 단축 시 켜 야 한 다 는 것 이다.그래서 대부분의 사건 을 자 물 쇠 를 풀 어 준 후에 처리 하고 자 물 쇠 를 빨리 풀 어 주 며 자 물 쇠 를 가 진 시간 을 단축 시 켜 다른 프로 세 스 가 가능 한 한 자 물 쇠 를 가 져 올 수 있 도록 합 니 다.만약 에 현재 프로 세 스 가 자 물 쇠 를 가지 고 있 지 않 으 면 사건 감시 체제 의 차단 점 (예 를 들 어 epoll wait () 의 시간 초과 시간 을 비교적 짧 은 범위 로 제한 하고 시간 초과 가 빠 를 수록 차단 에서 자주 튀 어 나 오 며 서로 배척 하 는 자 물 쇠 를 빼 앗 을 수 있 는 기회 가 더 많 습 니 다.
앞에서 말 했 듯 이 사건 이 발생 했 을 때 바로 처리 하지 않 고 지연 처 리 된 표지 (NGX POST EVENTS) 를 설정 합 니 다.지연 처리 의 원 리 는 하나의 사건 이 발생 할 때 사건 을 링크 형식 으로 캐 시 하 는 것 이다.
놀 라 움 을 해결 하 는 것 과 는 상 관 없 는 것 처럼 이 야 기 를 많이 했 는데 사실은 위 에서 말 한 내용 은 대체적으로 Nginx 가 놀 라 움 을 피 하 는 원 리 를 설명 했다.다음 두 가 지 를 요약 한다.
첫째, 새 연결 이 벤트 를 처리 하 는 과정 에서 감청 소켓 인터페이스 에 또 새로운 요청 이 들 어 오 면 어떻게 될 까?이것 은 괜 찮 습 니 다. 현재 프로 세 스 는 캐 시 된 이벤트 만 처리 합 니 다. 새로운 요청 은 감청 소켓 인터페이스 에 막 히 고 감청 소켓 인 터 페 이 스 는 수평 방식 으로 이벤트 모니터링 체제 에 들 어 갑 니 다. 따라서 다음 라운드 에 어떤 프로 세 스 가 잠 금 을 얻 고 사건 모니터링 체제 에 추 가 될 때 까지 기 다 려 야 작 동 되 어 캡 처 됩 니 다.
둘째, 프로 세 스 가 사건 을 처리 할 때 자 물 쇠 를 풀 었 을 뿐 감청 소켓 인 터 페 이 스 를 사건 감시 체제 에서 삭제 하지 않 았 기 때문에 캐 시 사건 을 처리 하 는 과정 에서 상호 배척 자 물 쇠 는 다른 프로 세 스 에 의 해 뺏 기 고 모든 감청 소켓 인 터 페 이 스 를 사건 감시 체제 에 추가 할 수 있 습 니 다.따라서 엄 밀 히 말 하면 같은 시간 에 감청 소켓 은 여러 프로 세 스 가 가 질 수 있 습 니 다. 그러나 같은 시간 에 감청 소켓 인 터 페 이 스 는 하나의 프로 세 스 에 의 해 감 시 될 수 있 습 니 다. 따라서 프로 세 스 가 캐 시 사건 을 처리 한 후에 자 물 쇠 를 빼 앗 으 려 고 노력 합 니 다. 자물쇠 가 다른 프로 세 스 에 의 해 점용 되 어 다 투 는 데 실패 하고 모든 감청 세트 인 터 페 이 스 를 자신의 사건 모니터링 체제 에서 삭제 합 니 다.그리고 사건 감 시 를 했 습 니 다.같은 시각 에 감청 세트 인 터 페 이 스 는 하나의 프로 세 스 에 의 해 감 시 될 수 있 습 니 다. 이것 은 Nginx 가 놀 라 운 영향 을 받 지 않 는 다 는 것 을 의미 합 니 다.