Nginx 캐시 정리

nginx에서 캐시를 캐시하는 여러 가지 방법

1. nginx의 Proxy_cache 기능 nginx-0.7부터 시작 버전 .44부터 nginx는 Squid와 유사한 보다 공식적인 캐시 기능을 지원합니다. 이 캐시는 링크를 md5 인코딩으로 해싱한 후 저장하므로 모든 링크를 지원할 수 있으며 404/301/302와 같은 200이 아닌 상태도 지원합니다. 구성: 먼저 캐시 공간을 구성합니다(http):proxy_cache_path /xok/to/cache level=1:2keys_z inactive=5m max_size=1g clean_time=1m; proxy_temp_path 매개변수 경로도 위의 proxy_cache_path와 동일한 파티션에 있어야 합니다. 그렇지 않으면 오류가 보고됩니다. 이 구성은 서버 태그 외부에 있습니다. 레벨은 캐시 공간에 두 가지 수준의 해시 디렉터리가 있음을 지정합니다. 첫 번째 수준 디렉터리는 1자이고 두 번째 수준은 2자입니다. . 저장 파일 이름은 /xok/to/cache/e/4a/0f1019b0db2f97d17c2238c0271a74ae와 유사합니다.keys_zone은 이 공간에 이름을 부여하며, 50m은 메모리 캐시 공간(활성)인 50MB의 공유 메모리 공간 크기를 나타냅니다. inactive 5m은 캐시 기본값을 나타냅니다. 기간이 5분이면 max_size는 총 캐시 공간이 1g이고 디스크 캐시 공간이 이 값을 초과하면 clean_time 정책이 실행된다는 의미입니다. 캐시는 1분에 한 번씩 정리되어야 합니다. 위치 / { Proxy_pass http://xok.la/; Proxy_cache xok1;#Use xok1 thiskey_zone Proxy_cache_valid 200 302 1H;#200 및 302 1시간 동안 상태 코드 301 1d;# 301 상태 코드는 1시간 동안 저장됩니다. day proxy_cache_valid any 1m; #다른 것은 1분 동안 저장됩니다 }여기에 사용된 예:

위치 ~ ^/(xx|yy).action{
proxy_set_header Accept-Encoding "";
proxy_set_header 호스트 $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header //설명 참조 1
proxy_cache dream_cache;
proxy_cache_key $host$uri$is_args$arg_pageNo$arg_subjectId;//설명 보기 2
proxy_cache_methods GET POST;
proxy_cache_valid 200 301 302 5s;
proxy_cache_use_stale 오류 시간 초과 업데이트 http_404 http_500 http_502 http_503;//설명 3 참조
proxy_cache_lock on;//참조 설명 4
proxy_cache_lock_timeout 5s;
proxy_pass http://localhost;}
설명 1:

add_header X-Cache $upstream_cache_status; 응답 헤더를 통해 캐시 적중 상태를 관찰합니다.

nginx는 캐시 상태를 표시하는 $upstream_cache_status 변수를 제공하여 Squid Effect와 유사하게 이 상태를 표시하도록 구성에 http 헤더를 추가할 수 있습니다. .

$upstream_cache_status에는 다음 상태가 포함됩니다.

·MISS 누락, 요청이 백엔드로 전송됩니다.
·HIT 캐시 적중
·EXPIRED 캐시가 만료되었으며 요청이 백엔드로 전송되었습니다.
·UPDATING 캐시가 업데이트되는 중입니다. , 이전 것이 사용됩니다.
·STALE 백엔드의 응답은

설명 2:

proxy_cache_key $host$uri$is_args$arg_pageNo$arg_subjectId; 일반적으로 캐시 키를 지정합니다. url. 여기서 두 가지 변수에 주목하세요:

(1) $is_args'?' 물음표

(2 ) $args; 물음표 뒤의 모든 매개변수를 나타냅니다.

여기서는 예제의 작성 방법을 이해하는 것이 더 중요하다고 생각합니다. 일부 매개변수를 지정하는 쓰기 방법인 pageNo와 두 개의 매개변수인 subjectId가 있으며 다른 매개변수는 무시됩니다. 예를 들어 타임스탬프가 추가되면 타임스탬프가 무시될 수 있습니다. 그렇지 않으면 캐시가 적중되지 않습니다.

설명 3:

proxy_cache_use_stale 오류 시간 초과 업데이트 http_404 http_500 http_502 http_503;

proxy_cache_use_stale 백엔드 서버에서 발생하는 상황을 지정할 때 nginx는 다음을 수행할 수 있습니다. 만료된 캐시를 사용하세요. 예를 들어 업데이트가 지정된 경우

캐시를 업데이트할 스레드가 하나만 있는지 확인하고 이 스레드에서 캐시를 업데이트하는 과정에서 다른 스레드는 현재 캐시에 있는 만료된 버전에만 응답합니다.

설명 4:

proxy_cache_lock on;

#동일한 요청을 정의하고 한 번만 허용합니다. 동시에 요청이 백엔드로 전송되고 새로운

# 항목이 Proxy_cache_key에 따라 메모리에 기록되고 Proxy_cache_lock_time 시간 초과가 직접 해제됩니다

proxy_cache_lock 켜기 |끄기 #기본 끄기proxy_cache_lock_timeout 시간 #기본 5초첨부됨 몇 가지 소개는 다음과 같습니다.

1개의 Proxy_cache 구문: Proxy_cache zone_name; 기본값: None

사용 필드: http, server, location

캐시 영역 이름을 설정합니다. 동일한 영역을 다른 장소에서 사용할 수 있습니다.

0.7.48 이후에는 캐시가 백엔드의 "Expires", "Cache-Control: no-cache", "Cache-Control: max-age=XXX" 등을 따릅니다. 그러나 현재 nginx는 "private" 및 "no-store"와 같은 일부 캐시 제어 지시문을 무시합니다. 마찬가지로 nginx는 일부 개인 데이터가 손상되지 않도록 캐시 프로세스 중에 "Vary" 헤더를 처리하지 않습니다. 모든 사용자에게 표시되는 경우 백엔드는 "no-cache" 또는 "max-age=0" 헤더를 설정해야 합니다. 그렇지 않으면 Proxy_cache_key에 $http_cookie_xxx와 같은 사용자 지정 데이터가 포함되어 있습니다. 개인 데이터는 캐시되지 않으므로 개인 데이터와 공용 데이터를 별도로 지정할 수 있습니다. 캐싱 지시어는 프록시 버퍼(버퍼)에 의존합니다. Proxy_buffers가 off로 설정된 경우 캐싱이 적용되지 않습니다.


proxy_cache_key 2개

구문: proxy_cache_key line;
기본값: $scheme$proxy_host$request_uri;
사용 필드: http, server, location
지시문은 캐시에 포함된 캐시를 지정합니다. 키워드.

proxy_cache_key "$host$request_uri$cookie_user";

proxy_cache_key "$scheme$host$request_uri";

3 Proxy_cache_path

구문: Proxy_cache_path 경로 [레벨=번호] key_z [비활성 =time] [max_size=size];기본값: 없음사용 필드: http 지시문은 캐시 경로 및 일부 기타 매개변수를 지정합니다. 파일에 있습니다. 캐시된 파일 이름과 키는 프록시 URL의 MD5 코드입니다. level 매개변수는 캐시된 하위 디렉터리의 수를 지정합니다. 예:

proxy_cache_path /data/nginx/cache levels=1:2 keys_z/td>

파일 이름은 /data/nginx/cache/c/29/b7f54b2df7773722d382f4809d65029c와 유사합니다. 모든 활성 키와 메타데이터는 key_zone 매개변수로 지정된 영역에 저장됩니다. 캐시된 데이터가 inactive 매개변수로 지정된 시간 내에 요청되지 않으면 삭제됩니다. 기본 비활성 시간은 10분입니다. 캐시 관리자 프로세스는 max_size 매개변수에 정의된 디스크의 캐시 크기를 제어합니다. 크기가 초과되면 가장 적게 사용된 데이터가 삭제됩니다. 영역의 크기는 캐시된 페이지 수에 비례하여 설정됩니다. 페이지(파일)의 메타데이터 크기는 운영 체제에 따라 결정됩니다. FreeBSD/i386에서는 64바이트입니다. FreeBSD/amd64. 영역이 가득 차면 LRU(최근에 사용된 알고리즘)에 따라 키가 처리됩니다. proxy_cache_path와 Proxy_temp_path는 동일한 파일 시스템에서 사용해야 합니다.

4개의 Proxy_cache_methods

구문: Proxy_cache_methods [GET HEAD POST];
기본값: Proxy_cache_methods GET HEAD;
사용 필드: http, server, location
GET/HEAD는 명령문을 장식하는 데 사용됩니다. 즉, 다음 명령문 설정만 사용하더라도 GET/HEAD를 비활성화할 수 없습니다:

proxy_cache_methods POST;

5개의 Proxy_cache_min_uses

구문: Proxy_cache_min_uses the_number;기본값: Proxy_cache_min_uses 1;사용 필드: http, 서버, 위치쿼리 후 응답이 캐시되는 횟수, 기본값은 1입니다.

6 Proxy_cache_valid

구문: Proxy_cache_valid reply_code [reply_code ...] time;
기본값: 없음
사용 필드: http, 서버, 위치
다른 응답에 대해 다른 캐시 시간을 설정합니다. 예: proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; proxy_cache_valid 5m; proxy_cache_valid 200 302 10m; proxy_cache_valid 301 1h; proxy_cache_valid any 1m;

7 Proxy_cache_use_stale

캐시 무효화(여러 스레드가 동시에 로컬 캐시를 업데이트하는 경우)를 방지하기 위해 'updating' 매개변수를 지정할 수 있습니다. 그러면 단 하나의 스레드만 캐시를 업데이트하고 다른 스레드는 해당 캐시를 업데이트합니다. 이 스레드가 캐시를 업데이트하는 동안 캐시는 현재 캐시에 있는 만료된 버전에만 응답합니다.

구성 코딩 및 구성:

각 명령에 대한 후크(예: 콜백)는 구성 파일을 읽을 때 호출되는 ngx_http_proxy_module.c에 정의되어 있습니다. 구성할 때 "HTTP_CACHE"를 YES로 설정하기만 하면 됩니다(auto/options에서 HTTP_CACHE 줄을 찾을 수 있음). "proxy_cache_purge" 지시문을 사용하려면 nginx를 다운로드해야 합니다. 추가 기능의 "Cache Purge" 모듈, 구성 시 "--add-module="을 사용하여 코드를 로드합니다.

다음 첨부 파일에는 다른 nginx 캐시 콘텐츠가 있지만 현재는 거의 사용되지 않습니다. 관심이 있으시면 자세히 알아볼 수 있습니다.

2. 전통적인 캐시(404) 중 하나 이 방법은 nginx의 404 오류를 백엔드로 보낸 다음, Proxy_store를 사용하여 페이지를 저장하는 것입니다. 백엔드에서 반환되었습니다. 위치 / { 루트 /home/html/;#홈 디렉터리 1일 만료;#웹 만료 page Time error_page 404 =200 /fetch$request_uri;#404 ​​​​/fetch 디렉토리로 이동 } 위치 /fetch/ {#404 여기로 이동 내부;#이 디렉토리는 외부에서 직접 접근할 수 없음을 나타냅니다. 만료 1d;#웹 만료 시간 page alias /home/html/;#가상 디렉터리 파일 시스템 주소는 location/과 일치해야 하며, Proxy_store는 파일을 이 디렉터리에 저장합니다. Proxy_pass http:/ /xok.la/;#백엔드 업스트림 주소,/fetch도 프록시입니다 Proxy_set_header Accept-Encoding '';#백엔드가 압축을 반환하지 않도록 합니다(gzip 또는 수축) 콘텐츠, 압축된 콘텐츠를 저장하면 문제가 발생할 수 있습니다. Proxy_store on;#프록시에서 반환된 파일을 저장하려면 nginx를 지정하세요. Proxy_temp_path /home/tmp;#Temporary 디렉터리, 이 디렉터리는 동일한 디렉터리에 있어야 합니다. as /home/html 하드 디스크 파티션 내 } 사용 시 nginx는 /home/tmp 및 /home/html 파일 쓰기 권한을 위해 Linux에서는 nginx가 일반적으로Nobody 사용자로 실행되도록 구성됩니다. 이런 방식으로 이 두 디렉토리는 반드시Nobody 사용자에게 독점적으로 설정되어야 합니다. chmod 777도 있지만 숙련된 시스템 관리자라면 777을 아무렇게나 사용하지 않는 것이 좋습니다.3. 기존 캐시 2(!-e)원리는 기본적으로 404 점프와 동일하지만 더 간결합니다. 위치 / { 루트 /home/html/; Proxy_store on; Proxy_set_header Accept-Encoding ''; Proxy_temp_path /home/tmp; if ( !-f $request_filename ) { Proxy_pass http://xok.la/; } } 이 구성을 사용하면 404에 비해 코드가 많이 절약되는 것을 볼 수 있습니다. 요청한 파일이 파일 시스템에 있는지 확인하기 위해 !-f를 사용합니다. 존재하지 않는 경우 백엔드로 Proxy_pass를 수행하고, 동일한 방법이 Proxy_store 저장을 반환하는 데 사용됩니다. 두 기존 캐시 모두 기본적으로 동일한 장점과 단점이 있습니다. 단점 1: read.php?와 같은 매개변수가 있는 동적 링크는 지원되지 않습니다. =1, nginx는 파일 이름만 저장하기 때문에 이 링크는 파일 시스템에 read.php로만 저장되므로 사용자가 read.php?id=2에 액세스하면 잘못된 결과가 반환됩니다. 동시에 http://xok.la/ 형식의 홈페이지 및 보조 디렉토리 http는 지원되지 않습니다. //xok.la/download/, nginx는 매우 정직하고 링크에 따라 파일 시스템에 이러한 요청을 작성하고 이 링크는 분명히 디렉토리이므로 저장이 실패하기 때문입니다. 이러한 경우 올바르게 저장하려면 다시 작성해야 합니다. 단점 2: nginx에는 캐시 만료 및 정리를 위한 메커니즘이 없습니다. 캐시할 항목이 많으면 캐시된 파일이 머신에 영구적으로 저장됩니다. 전체 시스템. 이를 위해 쉘 스크립트를 사용하여 정기적으로 정리할 수 있으며, PHP와 같은 동적 프로그램을 작성하여 실시간 업데이트를 수행할 수 있습니다. 단점 3: 상태 코드는 200개만 캐시할 수 있으므로 백엔드에서 반환된 301/302/404와 같은 상태 코드는 다음과 같은 의사 정적 링크가 있는 경우 캐시되지 않습니다. 많은 수의 방문이 삭제되면 계속해서 침투하여 백엔드에 많은 압력을 가하게 됩니다.단점 4: nginx는 메모리나 하드 디스크를 저장 매체로 자동 선택하지 않습니다. 물론 현재에는 운영 체제 수준의 파일 캐싱 메커니즘이 있습니다. 운영 체제에 저장되므로 대규모 동시 읽기로 인한 IO 성능 문제에 대해 너무 걱정할 필요가 없습니다. nginx 기존 캐싱의 단점도 Squid 등의 캐싱 소프트웨어와 특성이 다르기 때문에 장점이라고도 볼 수 있습니다. 프로덕션 애플리케이션에서는 Squid와 파트너로 사용되는 경우가 많습니다. Squid는 종종 ?가 있는 링크를 차단할 수 없는 반면, nginx는 http://xok.la/?와 같은 액세스를 차단할 수 있습니다. http://xok.la/는 Squid에서 두 개의 링크로 처리되므로 두 개의 침투가 발생하지만 nginx는 링크가 http://가 되더라도 한 번만 저장합니다. xok .la/?1 또는 http://xok.la/?123은 nginx에서 캐시할 수 없으므로 백엔드 호스트를 효과적으로 보호합니다. nginx는 링크 형식을 파일 시스템에 매우 정직하게 저장하므로 링크의 경우 캐시 상태와 내용을 캐시 머신에서 쉽게 확인할 수 있으며, rsync와 같은 다른 파일 관리자와 함께 쉽게 사용할 수 있으며 완전히 파일 시스템 구조입니다. 이 두 가지 기존 캐시는 모두 Linux에서 /dev/shm에 파일을 저장할 수 있습니다. 일반적으로 시스템 메모리를 캐싱에 사용할 수 있도록 이렇게 합니다. . 그렇다면 만료된 콘텐츠를 정리하는 것이 훨씬 더 빨라질 것입니다. /dev/shm/을 사용할 때 tmp 디렉토리를 /dev/shm 파티션으로 지정하는 것 외에도 작은 파일과 디렉토리가 많은 경우 메모리 파티션도 수정해야 합니다. inode 수 및 최대 용량: mount -o size=2500M -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm 위 명령은 3G 메모리가 있는 시스템에서 사용됩니다. /dev/shm의 기본 최대 메모리는 시스템 메모리의 절반인 1500M이므로 동시에 2500M으로 늘어납니다. shm 시스템의 inode 수는 기본적으로 설정되어 있어 충분하지 않을 수 있지만 흥미로운 점은 여기서 조정이 480000으로 다소 보수적이지만 기본적으로는 충분하다는 것입니다. 4. memcached 기반의 캐시 nginx는 memcached를 지원하지만, 기능이 특별히 강하지는 않고, 그래도 성능이 매우 뛰어납니다. . 위치 /mem/ { if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" ) { set $memcached_key "$1"; memcached_pass 192.168.6.2:11211; } 만료 70; }이 구성은 http://xok. /mem/abc는 데이터를 검색하기 위해 memcached의 키 abc를 지정합니다. nginx에는 현재 memcached에 쓸 수 있는 메커니즘이 없으므로 memcached에 데이터를 쓰는 작업은 백그라운드의 동적 언어를 사용하여 수행해야 합니다. 404를 사용하여 백엔드에 연결할 수 있습니다. 데이터를 씁니다. 5. 타사 플러그인 ncache를 기반으로 합니다.ncache는 Sina Brothers에서 개발한 좋은 프로젝트입니다. Squid 캐시 기능과 유사한 일부를 구현하기 위해 memcached를 사용했지만 이 플러그인을 사용해 본 경험이 없습니다. http://code.google.com/p/ncache/ 이상 내용의 측면을 포함하여 Nginx 캐시 구성을 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.