Nginx 의 실현 원리

9987 단어 Apache
144 저자 해 피 강 유 청 주목 2015.10.26 17:23*글자 수 2536 읽 기 1753 평론 2 좋아 8 본 고 는 주로 Nginx 의 프로 세 스 모듈,사건 모듈,http 네트워크 모듈 세 가지 측면 에서 Nginx 의 밑바닥 실현 원 리 를 소 개 했 고 본 고 를 통 해 Nginx 의 기본 적 인 실현 에 대해 어느 정도 이해 가 되 기 를 바란다.
프로 세 스 모듈
Nginx 는 기본적으로 데 몬 모드 로 시작 합 니 다.데 몬 모드 는 master 프로 세 스 를 시작 한 후 배경 에서 실행 되 며 창 에 걸 리 지 않 습 니 다.
Nginx 가 시작 되면 Master 프로 세 스 와 여러 Worker 프로 세 스 가 있 습 니 다.Master 프로 세 스 는 주로 Worker 프로 세 스 를 관리 하고 네트워크 이벤트 프로 세 스 를 수집 하고 배포 합 니 다.CPU 자원 을 차지 할 수 있 는 모듈 을 예약 하여 요청 을 처리 합 니 다.일반적으로 Worker 프로 세 스 의 개 수 를 기계 cpu 갯 수 와 일치 시 켜 cpu 자원 의 최대 화 이용 을 하고 프로 세 스 자원 배분 으로 인 한 추가 비용 도 피 합 니 다.
프로 세 스 아이콘
네트워크
마스터 프로 세 스 작업 원리
Master 프로 세 스 작업 포함
외부 로부터 의 신 호 를 받다
각 worker 프로 세 스에 신 호 를 보 냅 니 다.
워 커 프로 세 스 의 실행 상 태 를 감시 합 니 다.워 커 프로 세 스 가 종료 되면(이상 한 경우)새 워 커 프로 세 스 를 자동 으로 다시 시작 합 니 다.
군중 을 놀 라 게 하 는 현상
놀 라 움 현상 은 요청 이 올 때 accept 에 성공 할 수 있 는 프로 세 스 만 놀 라 깨 고 다른 프로 세 스 는 계속 막 히 는 것 을 말한다.nginx 는 accept-mutex 를 사용 하여 놀 라 운 문 제 를 해결 합 니 다.요청 이 도 착 했 을 때 잠 금 된 worker 프로 세 스 만 요청 을 처리 할 수 있 습 니 다.다른 프로 세 스 는 timer 와 결합 합 니 다.solution 설정 의 최대 시간 초과,감청 자 물 쇠 를 가 져 와 원본 코드 를 봅 니 다.
void ngx_process_events_and_timers(ngx_cycle_t *cycle) { ngx_uint_t flags; ngx_msec_t timer, delta; if (ngx_timer_resolution) { timer = NGX_TIMER_INFINITE; flags = 0; } else { timer = ngx_event_find_timer(); flags = NGX_UPDATE_TIME;
if (NGX_THREADS)
if (timer == NGX_TIMER_INFINITE || timer > 500) {
    timer = 500;
}

endif
}
/*       mutex, worker          */
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) {
            /*         flag */
            flags |= NGX_POST_EVENTS;
        } else {
            /*            timer             */
            if (timer == NGX_TIMER_INFINITE
                || timer > ngx_accept_mutex_delay)
            {
                timer = ngx_accept_mutex_delay;
            }
        }
    }
}
delta = ngx_current_msec;

/*   epoll       */
(void) ngx_process_events(cycle, timer, flags);

/* delta  epoll_wait       */
delta = ngx_current_msec - delta;

ngx_log_debug1(NGX_LOG_DEBUG_EVENT, cycle->log, 0,
               "timer delta: %M", delta);
/* accept                       */
ngx_event_process_posted(cycle, &ngx_posted_accept_events);

/* accept          accept ,               ,          */
if (ngx_accept_mutex_held) {
    ngx_shmtx_unlock(&ngx_accept_mutex);
}
if (delta) {
    ngx_event_expire_timers();
}

/*               */
ngx_event_process_posted(cycle, &ngx_posted_events);

}Worker 프로 세 스 작업 원리
워 커 프로 세 스 가 accept 이 연결 을 한 후에 요청 을 읽 고 요청 을 해석 하 며 요청 을 처리 하고 데 이 터 를 만 든 후에 클 라 이언 트 에 게 되 돌아 가 마지막 에 연결 을 끊 는 완전한 요청 이 바로 이 렇 습 니 다.하나의 요청 은 완전히 워 커 프로 세 스 가 처리 하고 하나의 워 커 프로 세 스 에서 만 처리 하 는 것 을 볼 수 있 습 니 다.
이런 방식 의 장점 을 채택 하 다.
자물쇠 가 가 져 온 비용 을 절약 하 다.모든 워 커 프로 세 스에 있어 서 독립 된 프로 세 스 는 자 물 쇠 를 추가 할 필요 가 없 기 때문에 자물쇠 가 가 져 오 는 비용 을 절약 하 는 동시에 프로 그래 밍 과 문 제 를 조사 할 때 많은 독립 프로 세 스 를 편리 하 게 하고 위험 을 줄 일 수 있 습 니 다.독립 된 프로 세 스 를 사용 하면 서로 영향 을 주지 않 습 니 다.한 프로 세 스 가 종 료 된 후에 도 다른 프로 세 스 가 작업 을 하고 있 습 니 다.서 비 스 는 중단 되 지 않 습 니 다.master 프로 세 스 는 곧 새로운 worker 프로 세 스 를 다시 시작 합 니 다.요청 에서 프로 세 스 전환 이 필요 없습니다.
user nobody nobody; worker_processes 8; worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000; worker_rlimit_nofile 65535; error_log logs/error.log info; 이벤트 모듈
기본 적 인 WEB 서버 에 있어 서 사건 은 보통 세 가지 유형 이 있 는데 그것 이 바로 네트워크 이벤트,신호 와 타이머 이다.
요청 의 기본 과정:연결 구축-연결 수용-데 이 터 를 보 내 고 시스템 밑 에 있 는 읽 기와 쓰기 이벤트 입 니 다.
Epol 모델
Epol 이 linux 2.6 에 나타 난 후에 Nginx 는 Epol 과 같은 비동기 적 이 고 막 히 지 않 는 사건 처리 체 제 를 사용 합 니 다.이러한 메커니즘 의 원 리 는 하나의 완전한 요 구 를 여러 개의 사건 으로 나 누 는 것 이다.예 를 들 어 accept(),recv(),디스크 I/O,send(),모든 사건 은 서로 다른 모듈 로 처리 하 는 것 이다.하나의 요청 은 워 커 프로 세 스 가 처리 합 니 다.요청 이 많 을 때 프로 세 스 를 자주 전환 할 필요 가 없습니다.
이벤트 모듈 아이콘
네트워크
master 프로 세 스 는 listen 이 필요 한 socket 을 만 든 다음 에 fork 에서 여러 woker 프로 세 스 를 만 듭 니 다.모든 work 프로 세 스 는 accept 라 는 socket 을 만 들 수 있 습 니 다.하나의 client 연결 이 올 때 모든 accept 의 work 프로 세 스 는 알림 을 받 지만 하나의 프로 세 스 만 accept 에 성공 할 수 있 습 니 다.다른 프로 세 스 는 accept 에 실 패 했 습 니 다.Nginx 는 공유 잠 금 accept 를 제공 합 니 다.mutex 는 같은 시각 에 하나의 work 프로 세 스 만 accept 에 연결 되 어 놀 라 운 문 제 를 해결 합 니 다.워 커 프로 세 스 accept 라 는 연결 이 있 으 면 요청 을 읽 고 요청 을 분석 하 며 요청 을 처리 하고 데 이 터 를 만 든 후에 클 라 이언 트 에 게 돌아 갑 니 다.마지막 으로 연결 을 끊 으 면 끝 납 니 다.Epol 은 하나의 프로 세 스 를 바탕 으로 여러 개의 연결 을 처리 합 니 다.IO 를 막 지 않 는 정책 입 니 다.Nginx 는 이 정책 을 많이 사용 합 니 다.모델 선택
Select 모델 은 시작 할 때 여러 프로 세 스 를 만 들 고 하나의 프로 세 스 풀 에 놓 으 며 프로 세 스 풀 의 프로 세 스 수 는 요청 수량 이 증가 함 에 따라 증가 합 니 다.모든 연결 은 하나의 프로 세 스 내 에서 처 리 됩 니 다.따라서 Select 모델 이 받 아들 일 수 있 는 병발 량 은 열 수 있 는 프로 세 스 수의 영향 을 받 아 프로 세 스 간 에 서로 막 히 고 잦 은 전환 프로 세 스 로 인해 많은 비용 이 듭 니 다.
Select 는 요청 한 비 차단 IO 를 스 레 드 로 처리 하 는 정책 입 니 다.아파 치 는 이 정책 을 사용 합 니 다.관련 설정
events { use epoll; worker_connections 1024; } 네트워크 모듈
최대 연결 수
http 서버 일 때:
max_clients = worker_processes * worker_connections; 역방향 에이전트 로 서:
max_clients = worker_processes * worker_connections/4 부하 균형
nginx 의 upstream 이 현재 지원 하 는 5 가지 방식 의 배분
폴 링(기본 값)모든 요청 은 시간 순서에 따라 서로 다른 백 엔 드 서버 에 할당 되 며,백 엔 드 서버 다운 이 떨 어 지면 자동 으로 제거 할 수 있 습 니 다.
upstream backserver { server host:port; server host:port; } weight 는 폴 링 확률 을 지정 하고 weight 와 방문 비율 이 정비례 하여 백 엔 드 서버 의 성능 이 고 르 지 않 은 경우 에 사용 합 니 다.
upstream backserver { server host:port weight=10; server host:port weight=10; } ip_hash 모든 요청 은 ip 에 접근 하 는 hash 결과 에 따라 분 배 됩 니 다.그러면 모든 방문객 이 백 엔 드 서버 에 고정 적 으로 접근 하면 session 문 제 를 해결 할 수 있 습 니 다.
upstream backserver { ip_hash; server host:port; server host:port; } fair(제3자)는 백 엔 드 서버 의 응답 시간 에 따라 요청 을 분배 하고 응답 시간 이 짧 은 우선 분 배 를 합 니 다.
upstream backserver { server server1; server server2; fair; } url_hash(제3자)는 url 에 접근 한 hash 결과 에 따라 요청 을 할당 하여 모든 url 을 같은 백 엔 드 서버 로 지정 합 니 다.백 엔 드 서버 가 캐 시 일 때 유효 합 니 다.
upstream backserver { server squid1:3128; server squid2:3128; hash $request_uri; hash_method crc32; } 부하 균형 을 사용 해 야 하 는 server 에 추가
proxy_pass http://backserver/ ; upstream backserver{ ip_hash; server host:port down; (down 은 단일 이전의 server 가 부하 에 잠시 참여 하지 않 음 을 표시 합 니 다)server host:port weight=2;(weight 기본 값 은 1.weight 가 클 수록 부하 가중치 가 큽 니 다)server host:port server host:port backup;(다른 모든 비 backup 기기 down 또는 바 쁠 때 backup 기기 요청)}프 록 시 캐 시
프 록 시 버퍼 관련 설정
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;

#                  
limit_req_zone  $http_x_forwarded_for zone=req_one:10m rate=30r/s;

#  Web      cache_web,         300MB,1             ,      
#   3GB。
proxy_temp_path   /xxx/proxy_temp_dir 1 2;
proxy_cache_path  /xxx/proxy_cache_dir levels=1:2 keys_zone=cache_web:300m inactive=1d max_size=1g;

액세스 제어
location ~ /.ht { deny all; } 관련 설정
http 명령 에 따라 여러 개의 server 명령 블록 을 설정 할 수 있 습 니 다.하나의 server 명령 블록 에 서 는 서로 다른 url 에 따라 설정 할 수 있 습 니 다.
http { include /xxx/nginx/conf/mime.types; default_type application/octet-stream;
log_format    main  '$remote_addr^A $remote_user^A [$time_local]^A $request^A '
                    '$status^A $body_bytes_sent^A $http_referer^A '
                    '$http_user_agent^A $http_x_forwarded_for^A '
        '$request_body^A $http_X_Cache^A $upstream_http_X_Cache^A '
        '$upstream_cache_status^A $http_x_accel_expires^A $dna_device';

access_log    /xxx/nginx/logs/access.log  main;

sendfile      on;
tcp_nopush    on;

#server_names_hash_bucket_size 128;
#client_header_buffer_size 8k;
open_file_cache max=10240 inactive=20s;// max          ,inactive             
open_file_cache_valid 30s; // 30s           
open_file_cache_min_uses 1;//       ,        ,         
keepalive_timeout  60;

#          
proxy_buffer_size   128k;
proxy_buffers   4 256k;
proxy_busy_buffers_size   256k;

#                  
limit_req_zone  $http_x_forwarded_for zone=req_one:10m rate=30r/s;

#  Web      cache_web,         300MB,1             ,      
#   3GB。
proxy_temp_path   /xxx/proxy_temp_dir 1 2;
proxy_cache_path  /xxx/proxy_cache_dir levels=1:2 keys_zone=cache_web:300m inactive=1d max_size=1g;

upstream www_backend_server {
    server   host:port;
}
 upstream m_backend_server {
    server   host:port;
}

server {
    listen          80;
    server_name     www.xxx.com;
    access_log      logs/xxx.access.log main;
    location ~ \.php {
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_index /index.php;
        include /xxx/nginx/conf/fastcgi_params;

        fastcgi_buffer_size 128k;
        fastcgi_buffers 4 256k;
        fastcgi_busy_buffers_size 256k;

        fastcgi_split_path_info       ^(.+\.php)(/.+)$;
        fastcgi_param PATH_INFO       $fastcgi_path_info;
        fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~ /\.ht {
        deny all;
        }
}

server {
    listen          80;
    server_name     www.xxx.com;
    access_log      logs/xxx.access.log main;
    location / {
        index index.html;
        root  /xxx/htdocs;
    }
}

}기타
시작 프로 세 스
시간,정규,오류 로그,ssl 등 읽 기 명령 행 인자 초기 화
fastcgi 모듈 을 통 해 상호작용 을 하고 상호작용 모드 는 두 가지 가 있 습 니 다.
fastcgi_pass unix:/xxx/php/var/php-cgi.sock;
fastcgi_pass 127.0.0.1:9000; Mail 설정
mail { auth_http 127.0.0.1:80/auth.php; pop3_capabilities “TOP” “USER”; imap_capabilities “IMAP4rev1” “UIDPLUS”;
server {
    listen     110;
    protocol   pop3;
    proxy      on;
}
server {
    listen      25;
    protocol    smtp;
    proxy       on;
    smtp_auth   login plain;
    xclient     off;
}

}다음 예고:Nginx 확장 모듈 개발

좋은 웹페이지 즐겨찾기