Nginx 에서 놀 라 운 문제 와 부하 균형 문 제 를 해결 합 니 다.

Nginx 의 놀 라 운 문제: master 프로 세 스 가 웹 포트 를 감청 하기 시 작 했 습 니 다. fork 에서 여러 개의 키 프로 세 스 를 내 보 냅 니 다. 이 하위 프로 세 스 는 같은 웹 포트 를 동시에 감청 하기 시작 합 니 다.사용자 가 서버 에 연결 되 어 있 지 않 으 면 어느 순간 모든 워 커 서브 프로 세 스 가 휴면 하고 새로운 연결 시스템 호출 을 기다 리 고 있 습 니 다.이때 한 사용자 가 서버 에 연결 을 시 작 했 습 니 다. 커 널 은 TCP 의 SYN 패 키 지 를 받 았 을 때 모든 휴면 worker 서브 프로 세 스 를 활성화 합 니 다.accept 를 가장 먼저 실행 하 는 하위 프로 세 스 는 새 연결 을 만 드 는 데 성공 할 수 있 으 며, 다른 worker 하위 프로 세 스 는 accept 에 실패 하고 휴면 을 계속 합 니 다.이 accept 에 실패 한 하위 프로 세 스 가 커 널 에 깨 어 나 는 것 은 불필요 합 니 다. 이 순간 에 필요 하지 않 은 시스템 자원 을 점용 하여 불필요 한 프로 세 스 컨 텍스트 전환 을 일 으 켜 시스템 비용 을 증가 시 켰 습 니 다.
 
       Nginx 가 놀 라 운 문 제 를 해결 하 는 방법 은 같은 시간 에 유일한 워 커 서브 프로 세 스 만 웹 포트 를 감청 할 수 있 도록 규정 한 것 이다.따라서 새 연결 이 벤트 는 유일 하 게 감청 포트 에 있 는 워 커 서브 프로 세 스 만 깨 울 수 있 습 니 다.
       이 프로젝트 를 실현 하려 면 accept 를 열 어야 합 니 다.mutex 자물쇠, 그리고 ngx 호출trylock_accept_mutex () 함수 accept 획득 시도mutex 잠 금, 잠 금 이 성공 해 야 웹 포트 를 감청 할 수 있 습 니 다.

ngx_int_t
ngx_trylock_accept_mutex(ngx_cycle_t *cycle)
{
	//         ，    ngx_accept_mutex 
    if (ngx_shmtx_trylock(&ngx_accept_mutex)) 
	{

        ngx_log_debug0(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
                       "accept mutex locked");
		//    ngx_accept_mutex ， ngx_accept_mutex_held 1， 
		//    。ngx_accept_mutex_held 1              。
        if (ngx_accept_mutex_held
            && ngx_accept_events == 0
            && !(ngx_event_flags & NGX_USE_RTSIG_EVENT))
        {
            return NGX_OK;
        }

		//                  epoll        
        if (ngx_enable_accept_events(cycle) == NGX_ERROR) 
		{
            ngx_shmtx_unlock(&ngx_accept_mutex); //    ，    ngx_accept_mutex 
            return NGX_ERROR;
        }

        ngx_accept_events = 0;
        ngx_accept_mutex_held = 1; //            

        return NGX_OK;
    }

    ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
                   "accept mutex lock failed: %ui", ngx_accept_mutex_held);

    //ngx_accept_mutex    ngx_accept_mutex   
    //ngx_accept_mutex 1               ，    
    if (ngx_accept_mutex)
	{
		//                   
        if (ngx_disable_accept_events(cycle) == NGX_ERROR)
		{
            return NGX_ERROR;
        }

        ngx_accept_mutex_held = 0;
    }

    return NGX_OK;
}

        하면, 만약, 만약...trylock_accept_mutex () 함수 가 잠 금 을 얻 지 못 했 습 니 다. 이벤트 구동 모듈 의 process 를 호출 합 니 다.이벤트 방법 은 연 결 된 이벤트 만 처리 할 수 있 습 니 다.자 물 쇠 를 얻 으 면 process 호출이벤트 방법 은 연 결 된 이벤트 도 처리 하고 새로운 연 결 된 이벤트 도 처리 합 니 다.
       획득 ngxaccept_mutex 잠 금 프로 세 스 는 ngx 를 우선 처리 합 니 다.posted_accept_이벤트 대기 열 에 있 는 이벤트 입 니 다. 처리 가 끝나 면 바로 이 자 물 쇠 를 풀 어야 합 니 다. 잠 금 의 사용 시간 을 줄 이 고 다른 프로 세 스 는 이 자 물 쇠 를 가 져 와 새로운 연결 이 벤트 를 처리 할 수 있 습 니 다.
 
 
 
    Nginx 의 부하 균형 문제 방식:
       부하 균형 한도 값 ngx 이용accept_disabled 가 관리 합 니 다.이 한도 값 은 프로 세 스 가 허용 하 는 총 연결 수의 1 / 8 에서 남 은 연결 수 를 뺀 것 입 니 다.즉, 한도 값 이 정수 일 때 현재 프로 세 스 는 새로운 연결 이 벤트 를 처리 하지 않 고 대신 한도 값 만 1 감소 합 니 다.       한도 값 의 초기 값 이 마이너스 이기 때 문 입 니 다. N (총 연결 수) / 8 - N (초기 에 남 은 값 은 프로 세 스 총 허용 연결 수) = - (7 / 8) N 입 니 다.따라서 Nginx 각 worker 하위 프로 세 스 간 의 부하 균형 은 특정한 worker 하위 프로 세 스 가 처리 하 는 연결 수가 최대 처리 총수 의 7 / 8 에 이 를 때 만 실 행 됩 니 다. 이 때 이 worker 프로 세 스 는 새로운 연결 을 처리 할 기 회 를 줄 이 고 다른 남 은 worker 프로 세 스 는 더 많은 새로운 연결 을 처리 할 수 있 습 니 다.
       잠 금 체 제 를 이용 하여 상호 배척 과 동기 화 를 해 야 한다. 감청 세트 인터페이스 가 여러 프로 세 스 의 사건 감시 체제 에 동시에 가입 되 는 것 을 피 할 뿐만 아니 라 감청 세트 인터페이스 가 어느 순간 에 어떠한 프로 세 스 에 의 해 감시 되 지 않도록 해 야 한다.        프로 세 스 가 과부하 상태 에 있 지 않 으 면 자 물 쇠 를 다 투 며 자 물 쇠 를 다 투 는 데 성공 하면 모든 감청 세트 인 터 페 이 스 를 자신의 사건 모니터링 체제 에 추가 합 니 다.잠 금 경쟁 에 실패 하면 감청 세트 인 터 페 이 스 를 자신의 사건 감시 체제 에서 삭제 할 것 이다.