nginx에서 cahce의 키 생성 규칙 수정에 대한 생각

수행할 작업의 초기 개념적 편차를 제외하면 이 키를 수정하는 데 필요한 코드의 양은 그리 크지 않습니다. nginx의 캐시에는 파일 캐시와 메모리 캐시인 Proxy_cache와 memcached가 포함됩니다. 파일 캐시는 방문한 페이지를 캐시 파일에 복사합니다. 다음 액세스가 키를 기반으로 하는 경우 업스트림 서버에 액세스하지 않고 캐시 파일에서 직접 읽습니다. 이름에서 알 수 있듯이 메모리 캐싱은 파일을 메모리에 캐시합니다.

memcached는 항상 연결을 끊고 디버깅할 수 없기 때문에 먼저 Proxy_cahce를 사용하여 키 생성 규칙을 수정했습니다. 이 프로세스에서 더 흥미로운 점은 키를 문자열로 처리한 후 이 작업은 문자열 작업이 되며 문자열 작업에 극복할 수 없는 장애물은 없습니다. 하지만 주의가 필요한 점은 nginx.conf에서 캐시_키 생성 규칙을 구성할 수 있으므로 유연성이 매우 높으며 요구 사항에 따라 키의 특정 필드를 지워야 하며 이러한 필드도 구성에 기록해야 한다는 것입니다. file.이므로 del_args 매개변수의 유연성도 매우 높습니다. 이 분석에 따르면 하드 코딩 문자열 작업은 후속 작업에 부정적인 영향을 미칩니다. 따라서 이 규칙은 계속해서 아래쪽으로 분석됩니다.

이 문제를 추상화하고 nginx와 밀접하게 관련된 세부 사항에서 해결하려는 모델을 추출합니다. 본질적으로 문자열 처리 문제입니다.

문자열 A, 문자열의 형식은 URL의 형식과 매우 유사합니다. 가장 완전한 것은 $scheme$domain$uri$is_args$args를 포함합니다. 이런 식으로 가장 긴 순서대로 진행합니다. 목록, 구성 테이블에는 가장 긴 키보다 적은 수의 매개변수만 포함됩니다.

문자 B, 키에서 삭제할 키워드는 URL의 매개변수 부분에 있는 키로 이름, 나이, 생년월일 등과 유사하며 127.0.0.1/index.html? name= **&age=**에 등장하는 문자로, 이를 분할한 후 다시 결합합니다.

왜 A를 분해하고 다시 조립하는 데 그렇게 많은 수고를 해야 합니까? ngx_http_request_t를 포함하여 캐시_키를 읽기 때문에 구성된 캐시키이든 구조체 자체에 존재하는 URL이든 args 매개변수는 ngx_string_t 유형으로 정의되며 이 유형의 데이터는 문자열로 저장됩니다. 전역 상수이고 읽기 전용이므로 수정 시에는 저장용 문자열을 새로 생성해야 하며, 함수 내에서 연산하여 새로운 Key에 할당한 후에는 이 내용이 사라질 수 없으므로 로 설정합니다. 정적으로 정적인 수량으로 만들고 저장 위치를 ​​전역 데이터 영역으로 변경합니다. 그러나 이렇게 하면 숨겨진 위험이 있습니다. 이 수정 후에는 하나의 값만 키에 할당됩니다. 즉시 사용하면 괜찮지만, 그렇지 않으면 다른 프로세스나 다른 프로세스가 이 값을 수정하면 내부 내용이 교체됩니다. 그러나 이러한 상황을 방지하기 위해 잠긴 경우에는 잠금 오버헤드를 고려해야 합니다. 정적인 양을 사용하지 않고 직접 호출 상위 레이어에 변수를 설정하고, 이 스코프에서 키를 생성하는 함수를 호출하고, 처리 후 스택에서 변수를 처리하는 것이 좋을 것 같습니다.

다른 하나는 효과 표시에 관한 것인데, 캐시가 맞는지 프런트엔드 인터페이스에서 직접 확인해야 한다는 게 이상한데, 이게 필요한 이유는 아무도 없기 때문인 것 같아요. 특히 자신의 습관을 바꾸는 것입니다. 이 습관이 이상하든 아니든, 그것이 당신에게 유익하든지 기술적인 성취를 향상하든 상관없이, 반면에 그것은 단지 습관일 뿐입니다. 긍정적으로 보면 모니터링 시스템을 구축해야 하며, 프런트 엔드에서 직접 서버 상태를 모니터링해야 합니다. 이 경우 개발 볼륨이 급격히 증가하게 되며, 이 경우 개발 시간이 계속해서 필요하게 됩니다. 증가하다.

일반적으로 Nginx가 설계한 모듈에는 결함이 있습니다. 나중에 자세히 설명하겠습니다. 하나는 곧 무너질 것입니다.

위 내용은 관련 측면을 포함하여 nginx에서 cahce의 키 생성 규칙을 수정하는 것에 대한 생각을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.