Nginx 기술 요점 총화

6276 단어
Nginx (engine x) 는 현재 가장 광범 위 하 게 사용 되 는 웹 서버 이자 자주 사용 되 는 역방향 프 록 시 서버 이다.본 고 는 Nginx 의 기초 기능 에 대해 정 리 를 하고 자신 이 깊이 이해 하 는 동시에 필요 한 친구 에 게 도움 이 되 기 를 바란다.
1. Nginx 1. nginx 를 설치 하여 pcre 라 이브 러 리 에 의존 하려 면 먼저 pcre 를 설치 하고 다음 명령 을 실행 해 야 합 니 다.   yum install pcre pcre - devel 2. nginx 소스 패 키 지 를 다운로드 하고 압축 을 풀 고 다음 명령 을 수행 합 니 다.    ./configure --prefix=/usr/local/nginx     make & make install 3. 설치 디 렉 터 리, cd / ulsr / local / nginx 에 들 어가 면 다음 4 개의 디 렉 터 리 를 볼 수 있 습 니 다.    ....conf 프로필      ... html 페이지 파일    ...logs  로그 파일      ...sbin  주 바 이 너 리 프로그램    nginx 를 시작 하려 면 명령 을 실행 하 십시오. / sbin / nginx
2. Nginx 작업 모드     nginx 는 다 중 프로 세 스 / 다 중 스 레 드 고성능 웹 서버 입 니 다. Liux 시스템 에서 nginx 가 시작 되면 나중에 데 몬 (daemon) 방식 으로 실 행 됩 니 다. 배경 프로 세 스 는 master 프로 세 스 와 여러 워 커 프로 세 스 를 포함 합 니 다.nginx 작업 모델 은 다 중 프로 세 스 방식 으로 작 동 합 니 다. 물론 nginx 도 다 중 스 레 드 를 지원 하 는 방식 입 니 다. 다만 우리 의 주류 방식 은 다 중 프로 세 스 방식 이자 nginx 의 기본 방식 입 니 다.nginx 는 시작 후 master 프로 세 스 와 여러 워 커 프로 세 스 (기본 값 은 하나) 가 있 습 니 다. 여러 워 커 서브 프로 세 스 는 같은 포트 를 감청 하고 요청 을 병행 합 니 다.      master 메 인 프로 세 스 는 주로 worker 프로 세 스 를 관리 하 는 데 사 용 됩 니 다. 주요 역할 은 설정 정 보 를 읽 고 확인 하 는 것 입 니 다. 서 비 스 를 제공 하 는 worker 프로 세 스 를 관리 하고 각 worker 프로 세 스에 신 호 를 보 내 며 worker 프로 세 스 의 운행 상 태 를 감시 하 는 것 입 니 다. worker 프로 세 스 가 종료 되면 (이상 한 경우) 새로운 worker 프로 세 스 를 자동 으로 다시 시작 합 니 다.master 프로 세 스 는 사용자 요청 에 서 비 스 를 제공 하지 않 습 니 다. 사용자 의 요청 은 worker 프로 세 스 가 응답 합 니 다.      Worker 프로 세 스 수 는 CPU 와 같은 핵 수 (CPU 수 * 핵 수) 로 설정 해 야 합 니 다. 높 은 트 래 픽 병행 장소 에서 도 프로 세 스 수 를 CPU 핵 수 * 2 로 올 리 는 것 을 고려 할 수 있 습 니 다.
3. Nginx 의 신호 제어    nginx 는 Liux 시스템 의 신 호 량 을 통 해 제어 합 니 다.    Nginx 는 다음 과 같은 몇 가지 신호 옵션 을 지원 합 니 다.
    TERM,INT:       빠 른 닫 기                                                         QUIT: 여 유 롭 게 닫 기 (우아 한 닫 기 프로 세 스, 즉 요청 이 끝 난 후에 닫 기)         HUP: 부 드 럽 게 다시 시작 하고 설정 파일 을 다시 불 러 옵 니 다. (부 드 럽 게 다시 시작 하고 설정 파일 을 수정 한 후 서버 를 다시 시작 하지 않 아 도 됩 니 다. kill - PUT 프로 세 스 번 호 를 사용 하면 됩 니 다.)    USR 1: 로그 파일 을 다시 읽 습 니 다. 로 그 를 자 를 때 사용 하 는 용도 가 큽 니 다. (오래된 로그 파일 기록 을 중단 하고 새 로그 파일 을 여 는 것 은 오래된 로그 파일 이 수 정 된 파일 이름 이라도 inode 때문에 nginx 는 오래된 로그 파일 에 데 이 터 를 계속 기록 하기 때 문 입 니 다)      USR 2: 부 드 러 운 업그레이드 실행 프로그램 ,nginx 업그레이드 시 사용                                     WINCH: 작업 프로 세 스 를 여 유 롭 게 닫 습 니 다.            
     구체 적 인 문법:     kill - 신호 옵션 nginx 의 주 프로 세 스 번호     kill -HUP 4873
     nginx 의 메 인 프로 세 스 번 호 는 매번 조회 가 좀 번 거 롭 습 니 다.사실 nginx 는 nginx. pid 파일 을 통 해 메 인 프로 세 스 번 호 를 기록 합 니 다. 다음 과 같은 통 일 된 문법 으로 상기 작업 을 간소화 할 수 있 습 니 다.     kill - 신호 제어 ` cat / xxx / path / log / ngix. pid `
     nginx 도. / sbin / nginx - s 명령 옵션 을 사용 하여 신 호 량 을 보 낼 수 있 습 니 다.명령 방식 은 간단 하지만 직접 사용 하 는 신 호 량 이 풍부 하지 않다.     명령 옵션 은 stop, quit, reopen, reload 를 포함 합 니 다.
4. Nginx 로그 1. Nginx 는 서로 다른 가상 호스트 server 에 대해 다른 로 그 를 만 들 수 있 습 니 다.
2. nginx 로그 절단 및 백업     로 그 를 날짜 에 따라 자 르 고 백업 하 는 것 은 일반적인 운영 작업 이지 만 nginx 로 그 는 간단하게 복사 작업 을 할 수 없습니다.Liux 에서 하나의 파일 은 하나의 노드 에 대응 하 는 inode 라 고 합 니 다. inode 야 말로 파일 이 디스크 에 있 는 진정한 위치 이 고 파일 이름 은 이미지 일 뿐 입 니 다.Linux 시스템 은 여러 파일 이름 이 같은 inode 번 호 를 가리 킬 수 있 도록 합 니 다.이것 은 서로 다른 파일 이름 으로 같은 내용 에 접근 할 수 있다 는 것 을 의미한다.파일 내용 을 수정 하면 모든 파일 이름 에 영향 을 줄 수 있 습 니 다.단, 하나의 파일 이름 을 삭제 하면 다른 파일 이름 의 접근 에 영향 을 주지 않 습 니 다.이런 상황 을 '하 드 링크' (hard link) 라 고 부른다.
      로그 파일 이 nginx 프로 세 스 에 의 해 계속 열 려 있 기 때문에 뮤 직 비디오 명령 으로 이름 을 바 꾸 고 같은 이름 의 새 파일 을 새로 만 들 더 라 도 nginx 프로 세 스 는 원래 의 파일 설명 자 를 열 어 원래 의 디스크 공간 (node) 을 가리 키 며 원래 의 파일 에 기록 합 니 다.파일 삭제 명령 을 실행 하 더 라 도 원래 디스크 공간 에 기록 합 니 다.따라서 로그 백업, 절단 등 을 수행 하려 면 nginx 의 USR 1 신 호 량 을 사용 하여 작업 해 야 합 니 다.
      구체 적 인 스 크 립 트:
#!/bin/bash
base_path='/usr/local/nginx/logs'
log_path=$(date -d yesterday +"%Y%m")
day=$(date -d yesterday +"%d")
mkdir -p $base_path/$log_path
mv $base_path/access.log $base_path/$log_path/access_$day.log
#echo $base_path/$log_path/access_$day.log
kill -USR1 `cat /usr/local/nginx/logs/nginx.pid`

      여기 부 드 러 운 연결 도 말씀 드 리 겠 습 니 다.하 드 링크 외 에 도 특수 한 상황 이 있다.파일 A 와 파일 B 의 inode 번 호 는 다 르 지만 파일 A 의 내용 은 파일 B 의 경로 입 니 다.파일 A 를 읽 을 때 시스템 은 자동 으로 방문 자 가이드 파일 B 를 가 져 옵 니 다.따라서 어떤 파일 을 열 어도 최종 적 으로 읽 는 것 은 파일 B 입 니 다.이 때 파일 A 는 파일 B 의 "소프트 링크" (soft link) 또는 "심 볼 릭 링크 (symbolic link) 라 고 합 니 다. 이 는 파일 A 가 파일 B 에 의존 하여 존재 한 다 는 뜻 입 니 다. 파일 B 를 삭제 하면 파일 A 를 열 면 오류 가 발생 합 니 다." No such file or directory"。이것 은 소프트 링크 와 하 드 링크 의 가장 큰 차이 점 입 니 다. 파일 A 는 파일 B 의 inode 번호 가 아 닌 파일 B 의 inode '링크 수' 를 가리 키 며 이 로 인해 변 하지 않 습 니 다.
5. location 의 분석 과정 location 은 '포 지 셔 닝' 이라는 뜻 으로 Uri 에 따라 서로 다른 포 지 셔 닝 을 한다.location 의 문법 location [= | ~ | ~ * | ^ ~] patt {} 에 괄호 는 매개 변 수 를 쓰 지 않 아 도 됩 니 다. 이 때 는 일반 일치 라 고도 부 르 고 매개 변 수 를 쓸 수 있 습 니 다. 따라서 큰 유형 은 3 가지 location = patt {} [정확 한 일치] location patt {} 로 나 눌 수 있 습 니 다. [일반 일치] location ~ patt {} [정규 일치]
location 의 명중 과정 은 다음 과 같 습 니 다. 1. 정확 한 매 칭 을 판단 하고 명중 하면 즉시 결 과 를 되 돌려 주 고 분석 과정 을 끝 냅 니 다.2. 일반적인 매 칭 을 판단 하고 여러 개의 명중 이 있 으 면 최 장 일치 하 는 명중 결 과 를 기록 하고 기록 만 할 뿐 끝나 지 않 습 니 다.3. 정규 와 일치 하 는 분석 결 과 를 계속 판단 하고 설정 파일 의 우선 순위 에 따라 판단 합 니 다.위 에서 아래로 매 칭 을 시작 합 니 다. 매 칭 이 성공 하면 즉시 되 돌아 오고 분석 과정 을 끝 냅 니 다.명중 이 없 으 면 일반 일치 기록 의 명중 결 과 를 되 돌려 줍 니 다.
메모: 보통 일치 합 니 다. 순 서 는 상 관 없 이 일치 하 는 장단 점 에 따라 확인 합 니 다.정규 일치, 설정 의 우선 순위 에 따라 위 에서 아래로 일치 합 니 다.
6. rewrite 재 작성 rewrite 재 작성 기능 은 nginx 서비스의 매우 중요 한 기능 모듈 로 도 메 인 이름 을 다시 수정 하고 기업 에 동적 URL 주 소 를 정적 주소 로 위장 할 수 있 습 니 다. 
1. rewrite 문법 rewrite 정규 표현 식 이 정 해진 위치 모드: Goods - 3. html 페이지 를 id = 3 백 엔 드 프로그램 Goods. php? goods 로 다시 쓰기id=3 rewrite goods-([\d]+)\.html$ /ecshop/goods.php?id=$1;  메모: url 로 다시 쓸 때 정규 에 '{}' 이 있 으 면 따옴표 로 싸 야 합 니 다.
2. 서버 내부 의 rewrite 는 302 점프 와 다르다.302 점프 URL 은 http 요청 으로 바 뀌 었 고 내부 rewrite 는 문맥 이 변 하지 않 았 습 니 다.그 러 니까 fastcgiscript_name 은 여전히 원래 내용 입 니 다.따라서 순환 재 정립 문 제 를 고려 해 필요 한 곳 에 break 명령 을 사용 해 야 한다.
기타
1. 페이지 나 다른 정적 파일 이 변경 되면 클 라 이언 트 브 라 우 저 캐 시가 최신 코드 를 제때에 새로 고치 지 않 을 때 가 있 습 니 다.클 라 이언 트 브 라 우 저가 최신 코드 를 제때에 업데이트 할 수 있 도록 nginx 설정 을 통 해 캐 시 를 사용 하지 않 을 수 있 습 니 다.server 세그먼트 에 다음 설정 을 추가 합 니 다:
add_header Cache-Control no-cache;
 
지난번 에 서 류 를 쓴 것 이 뜻밖에도 1 년 여 전이 다.어느덧 시간 이 쏜살같이 지나 갔다.일이 너무 바 쁜 지, 아니면 스스로 게 으 름 을 피 웠 는 지 모르겠다.전염병 발생 기간 에 생활 리듬 이 약간 느 려 졌 고 중국 국민 들 에 게 변증법 적 으로 보면 좋 은 면도 있다.

좋은 웹페이지 즐겨찾기