Nginx 서버 의 캐 시 메커니즘 (1)

1. 웹 캐 시 기술 에 대한 약술
웹 캐 시 기술 은 서버 의 부 하 를 줄 이 고 네트워크 의 체증 을 낮 추 며 네트워크 의 확장 성 을 강화 하 는 효과 적 인 방법 중 하나 로 여 겨 진다. 그 기본 적 인 사상 사 는 클 라 이언 트 가 방문 한 시간 국부 적 원 리 를 이용 하여 클 라 이언 트 가 방문 한 내용 을 복사 본 으로 만 들 고 한 동안 메모리 에 로 컬 에 두 며 데이터 가 다음 에 방문 할 때 백 엔 드 서버 에 연결 할 필요 가 없다.로 컬 에 저 장 된 데이터 복사 본 에 해당 합 니 다.
2, 404 오류 드라이브 캐 시
Nginx 서버 가 자체 프 록 시 스토어 기능 에 의존 하여 404 오 류 를 재정 비해 왔 습 니 다.Nginx 서버 가 클 라 이언 트 요청 을 처리 할 때 요청 한 자원 데이터 가 존재 하지 않 는 것 을 발견 하면 404 오류 가 발생 할 수 있 습 니 다. 그리고 서버 는 이 오 류 를 캡 처 하여 백 엔 드 서버 에 데 이 터 를 요청 하고 마지막 으로 백 엔 드 서버 의 응답 데 이 터 를 클 라 이언 트 에 전송 하 며 로 컬 에서 캐 시 합 니 다.실현 원리 상 Nginx 서버 는 백 엔 드 서버 가 시작 한 데이터 요청 처럼 웹 캐 시 를 완성 하 는데 주로 404 오류 로 작 동 됩 니 다.

location / {
    root /107lab/server/;    #web   
    error_page 404 =200 /errpage$request_uri;   #404    /errpage    ；
}

#  404      
location /errpage/ {
    internal;   #               
    alias /home/html/;  
    proxy_pass http://myUpstream/;  #  upstream       。
    
    proxy_set_header Accept-Encoding "";    #        (Gzip/defalte)  
    proxy_store on; #  nginx          
    proxy_store_access user:rw group:rw all:r;  #           
    proxy_temp_path /107lab/server/tmp; #      ，      /107lab/server/          
}

3. 자원 에 드라이버 웹 캐 시가 존재 하지 않 습 니 다.
이 방법 은 '404 오류 구동 웹 캐 시' 방법 과 원리 적 으로 대동소이 하 다.다른 점 은 이 방법 은 location 블록 의 location if 조건 을 통 해 Nginx 서버 와 백 엔 드 서버 의 통신 과 웹 캐 시 를 직접 구동 하 는 것 으로 판단 된다.

location /errpage/ {
    .... #    
    alias /home/html/;
    internal;   #               
    proxy_pass http://myUpstream/;  #  upstream       。
    
    proxy_set_header Accept-Encoding "";    #        (Gzip/defalte)  
    proxy_store on; #  nginx          
    proxy_store_access user:rw group:rw all:r;  #           
    proxy_temp_path /107lab/server/tmp; #      ，      /107lab/server/          
    
    if (!-f $request_filename) {    #          
        proxy_pass http://myUpstream/;  #    upstream       
    }
}

location if 조건 판단 지원 하 는 "! - f" 는 요청 한 자원 이 Nginx 서버 에서 파일 인지 여 부 를 판단 합 니 다. 만약 $requestfilename 이 존재 하지 않 거나 파일 형식 이 아 닌 경우 false 로 돌아 갑 니 다.요청 한 자원 이 존재 하지 않 는 다 면 (즉, if 괄호 안의 판단 이 true) 백 엔 드 서버 를 통 해 데 이 터 를 가 져 와 클 라 이언 트 에 게 전송 하고 proxy 를 사용 합 니 다.store 캐 시 진행.  상기 두 가지 캐 시 메커니즘 의 원 리 는 비슷 하 다. 실제 응용 에서 우 리 는 Proxy Store 의 캐 시 디 렉 터 리 를 / dev / shm 에 설정 하여 캐 시 데이터 의 처리 속 도 를 높 일 수 있다.메모리 에 캐 시 데 이 터 를 저장 하지 않 으 면 이 두 가지 캐 시 체 제 는 캐 시 데 이 터 를 청소 하 는 체 제 를 지원 하지 않 습 니 다. 캐 시 파일 은 로 컬 에 저장 되 어 디스크 공간 을 차지 합 니 다.  주의:

이상 의 두 가지 캐 시 는 200 상태 코드 의 해당 데이터 만 캐 시 할 수 있 습 니 다. 이것 은 '404 오류 구동 캐 시' 를 설정 할 때 404 오 류 를 200 상태 로 다시 바 꾸 는 이유 입 니 다

.

이 두 가지 캐 시 메커니즘 은 동적 링크 요청 을 지원 하지 않 습 니 다.예 를 들 어 getSource? id = 1 과 getSource? id = 2 두 가지 요청 은 이 두 가지 캐 시 체 제 는 id = 1 인 자 를 무시 하여 되 돌아 오 는 자원 이 정확 하지 않다 는 등 문 제 를 초래 할 수 있 습 니 다.