1. 전통적인 캐시 중 하나(404)
이 방법은 nginx의 404 오류를 백엔드로 보낸 다음, Proxy_store를 사용하여 백엔드에서 반환된 페이지를 저장하는 것입니다.
구성:
위치/{
루트 /home/html/;#홈 디렉토리
1일 만료;#웹페이지 만료 시간
error_page 404 =200 /fetch$request_uri;#404 /fetch 디렉토리로 이동
}
위치 /fetch/ {#404여기로 직접 연결
내부;#이 디렉터리는 외부에서 직접 액세스할 수 없음을 나타냅니다.
1일 만료;#웹페이지 만료 시간
alias /home/html/;#가상 디렉터리 파일 시스템 주소는 location/과 일치해야 하며, Proxy_store는 파일을 이 디렉터리에 저장합니다.
Proxy_pass http://www.sudone.com/;#백엔드 업스트림 주소, /fetch도 프록시입니다.
Proxy_set_header Accept-Encoding '';# 백엔드가 압축된( gzip 또는 deflate) 콘텐츠를 반환하지 않도록 합니다. 압축된 콘텐츠를 저장하면 문제가 발생합니다.
Proxy_store on;#프록시에서 반환된 파일을 저장하려면 nginx를 지정하세요.
Proxy_temp_path /home/tmp;#임시 디렉터리, 이 디렉터리는 /home/html과 동일한 하드 디스크 파티션에 있어야 합니다.
}
이를 사용할 때 nginx는 /home/tmp 및 /home/html에 파일을 쓸 수 있는 권한이 있어야 합니다. Linux 에서 nginx는 일반적으로Nobody 사용자로 실행되도록 구성되므로 이 두 디렉토리는 none으로 설정되어야 합니다. 물론 아무도 사용하지 않는 사용자에게만 적용하려면 chmod 777을 사용할 수도 있지만 숙련된 모든 시스템 관리자는 777을 함부로 사용하지 말 것을 권고할 것입니다.
2. 기존 캐시 2(!-e)
원칙은 기본적으로 404 점프와 동일하지만 더 간결합니다.
위치/{
루트 /홈/html/;
Proxy_store 켜짐;
Proxy_set_header Accept-Encoding '';
프록시_임시_경로 /home/tmp;
if ( !-f $request_filename )
{
Proxy_pass http://www.sudone.com/;
}
}
이 구성은 404에 비해 코드가 많이 절약되는 것을 볼 수 있습니다. 요청한 파일이 파일 시스템에 존재하는지 확인하기 위해 !-f를 사용합니다. 존재하지 않는 경우 백엔드로 Proxy_pass를 수행하고 반환도 다음을 사용하여 저장됩니다. 프록시_스토어.
두 기존 캐시 모두 기본적으로 동일한 장점과 단점을 가지고 있습니다.
단점 1: read.php?id=1과 같은 매개변수가 있는 동적 링크는 지원되지 않습니다. nginx는 파일 이름만 저장하기 때문에 이 링크는 파일 시스템에 read.php로만 저장되므로 사용자는 읽기에 액세스할 수 있습니다. php?id= 2는 잘못된 결과를 반환합니다. 동시에 nginx는 매우 정직하고 글을 작성하기 때문에 http://www.sudone.com/ 및 보조 디렉토리 http://www.sudone.com/download/ 형식의 홈페이지를 지원하지 않습니다. 링크 시스템에 따라 이러한 요청이 파일에 저장되고 이 링크는 분명히 디렉토리이므로 저장이 실패합니다. 이러한 경우 올바르게 저장하려면 다시 작성해야 합니다.
단점 2: nginx 내부에는 캐시 만료 및 정리를 위한 메커니즘이 없습니다. 캐시된 파일은 머신에 영구적으로 저장됩니다. 캐시할 항목이 많으면 전체 하드 디스크 공간을 차지하게 됩니다. 이를 위해 쉘 스크립트를 사용하여 정기적으로 정리할 수 있으며, PHP와 같은 동적 프로그램을 작성하여 실시간 업데이트를 수행할 수 있습니다.
단점 3: 상태코드는 200개까지만 캐싱이 가능하므로 백엔드에서 반환한 301/302/404 등의 상태코드는 방문수가 많은 의사정적 링크가 삭제되면 계속 캐싱되지 않는다. 침투하여 후단에 많은 압력이 가해지게 됩니다.
단점 4: nginx는 자동으로 메모리나 하드 디스크를 저장 매체로 선택하지 않습니다. 물론 현재 운영 체제에는 운영 체제 수준의 파일 캐싱 메커니즘이 있으므로 그럴 필요가 없습니다. 하드 디스크에 저장된 경우 대용량 동시 읽기에 대해 너무 걱정하지 마십시오. 성능 문제가 발생합니다.
nginx의 기존 캐시의 단점 역시 Squid 등의 캐싱 소프트웨어와는 기능이 다르기 때문에 장점으로도 볼 수 있습니다. 프로덕션 애플리케이션에서는 Squid와 파트너로 사용되는 경우가 많습니다. Squid는 종종 ?가 포함된 링크를 차단할 수 없지만 nginx는 http://sudone.com/? 및 http://sudone과 같은 액세스를 차단할 수 있습니다. com /은 Squid에서 두 개의 링크로 처리되므로 링크가 http://sudone.com/?1 또는 http://sudone.com/이 되더라도 nginx는 한 번만 저장합니다. ? 123은 nginx에서 캐시할 수 없으므로 백엔드 호스트를 효과적으로 보호합니다.
nginx는 링크 형식을 파일 시스템에 매우 충실하게 저장하므로 링크의 경우 캐시 머신에서 캐시 상태와 내용을 쉽게 확인할 수 있으며 rsync와 같은 다른 파일 관리자와도 쉽게 협력할 수 있습니다. 완전히 파일 시스템 구조입니다.
이러한 기존 캐시는 모두 Linux에서 /dev/shm에 파일을 저장할 수 있습니다. 일반적으로 시스템 메모리를 캐싱에 사용할 수 있도록 이렇게 합니다. 메모리를 사용하면 만료 콘텐츠가 훨씬 빨리 정리됩니다. /dev/shm/을 사용할 때 tmp 디렉터리를 /dev/shm 파티션으로 지정하는 것 외에도 작은 파일과 디렉터리가 많은 경우 inode 수와 이 메모리의 최대 용량도 수정해야 합니다. 분할:
마운트 -o 크기=2500M -o nr_inodes=480000 -o noatime,nodiratime -o /dev/shm 다시 마운트
위 명령은 3G 메모리가 있는 시스템에서 사용됩니다. /dev/shm의 기본 최대 메모리는 시스템 메모리의 절반인 1500M이므로 동시에 shm 개수도 2500M로 늘어납니다. 시스템 inode는 기본적으로 충분하지 않을 수 있습니다. 그러나 흥미로운 점은 여기에서 조정이 480000으로 약간 보수적이지만 기본적으로는 충분하다는 것입니다.
3. mem 캐시 기반 캐시 d
nginx는 memcached 를 일부 지원하지만 기능이 특별히 강력하지는 않으며 성능도 여전히 매우 좋습니다.
위치 /mem/ {
if ( $uri ~ "^/mem/([0-9A-Za-z_]*)$" )
{
$memcached_key "$1" 설정;
memcached_pass 192.168.1.2:11211;
}
70에 만료됩니다.
}
이 구성은 데이터를 검색하기 위해 http://sudone.com/mem/abc에서 memcached의 키 abc를 가리킵니다.
nginx에는 현재 memcached에 쓰기 위한 메커니즘이 없으므로 memcached에 데이터 쓰기는 백그라운드에서 동적 언어를 사용하여 수행되어야 합니다. 404를 사용하여 데이터 쓰기를 위해 백엔드에 연결할 수 있습니다.
4. 타사 플러그인 ncache 기반
ncache는 Sina Brothers가 개발한 좋은 프로젝트입니다. nginx와 memcached를 사용하여 Squid 캐싱과 유사한 일부 기능을 구현합니다. 이 플러그인을 사용해 본 경험이 없습니다.
http://code.google.com/p/ncache/
5. 새로 개발된 nginx의 Proxy_cache 기능
nginx-0.7.44 버전부터 nginx는 Squid와 유사한 좀 더 공식적인 캐시 기능을 지원합니다. 아직 개발 단계이고 지원이 상당히 제한되어 있습니다. 이 캐시는 링크를 md5 인코딩으로 해싱한 후 저장하므로 지원할 수 있습니다. 모든 링크와 동시에 404/301/302와 같은 200이 아닌 상태도 지원됩니다.
구성:
먼저 캐시 공간을 구성합니다.
Proxy_cache_path /path/to/cache level=1:2key_zone=NAME:10m 비활성=5m max_size=2m clean_time=1m;
이 구성은 서버 태그 외부에 있습니다. 레벨은 캐시 공간에 두 가지 수준의 해시 디렉터리가 있음을 지정합니다. 첫 번째 수준 디렉터리는 1자이고 두 번째 수준은 2자입니다. 저장된 파일 이름은 /path/와 유사합니다. to/cache /c/29/b7f54b2df7773722d382f4809d65029c;keys_zone은 이 공간에 이름을 지정합니다. 10m은 공간 크기가 10MB임을 의미하고, 비활성의 5m은 기본 캐시 시간이 5분임을 의미합니다. 2m를 초과하는 단일 파일은 캐시되지 않습니다. clean_time은 1분을 지정합니다. 캐시를 한 번 지웁니다.
위치/{
Proxy_pass http://www.sudone.com/;
Proxy_cache NAME;#NAME 키 사용_zone
Proxy_cache_valid 200 302 1h;#200 및 302 상태 코드가 1시간 동안 저장됩니다.
Proxy_cache_valid 301 1d;#301 상태 코드는 하루 동안 저장됩니다.
proxy_cache_valid any 1m;#다른 항목은 1분 동안 저장됩니다.
}