Q: 좋은 캐시란 어떤 캐시인가요?
문제를 해결하는 캐시가 좋은 캐시입니다. 이 문장은 흰 고양이, 검은 고양이, 쥐를 잡는 고양이가 좋은 고양이에 해당하는 단순한 말도 안되는 문장입니다.
그렇다면 문제 해결을 전제로 어떤 캐시가 가장 좋은 캐시일까요? 이 질문에 대한 나의 대답은 다음과 같습니다. 캐시 적중률이 높은 캐시가 좋은 캐시입니다.
문제 해결을 전제로, 적중률이 높은 캐시는 적중률이 낮은 캐시보다 하드웨어 투자가 덜 필요할 수 있으며, 동시에 적중률이 낮은 캐시의 수보다 캐시 수가 적을 수도 있습니다. 이렇게 하면 주소 지정 속도가 확실히 빨라집니다. 따라서 적중률이 높은 캐시가 좋은 캐시입니다.
캐시 적중률
캐시된 엔터티가 캐시에 던져진 후 엔터티가 캐시되는 동안(캐시되는 엔터티의 수명 주기 동안) 외부 세계에서 한 번도 사용되지 않은 경우 캐시된 엔터티의 적중률은 0입니다. 이 엔터티가 요청되는 횟수가 많을수록 캐시 적중률이 높아집니다.
위에서 언급한 것은 캐시에 있는 엔터티의 적중률입니다. 캐시 전체의 적중률은 위의 캐시된 개별 개체의 적중률 분포도입니다.
캐싱의 경우: 일반적으로 가장 일반적으로 사용되는 개인은 전체에서 매우 작은 부분입니다. 가장 적게 사용되는 것이 전체에서 큰 부분을 차지합니다.
그래서 우리는 종종 다음과 같은 데이터를 봅니다.
10,000개의 캐시된 요소 중 100개가 거의 매분마다 자주 사용됩니다. 2000개의 데이터가 1시간에 한 번 요청됩니다. 하루에 한 번 3000개의 데이터가 요청되며, 나머지 데이터는 캐시에 버려진 후 한 번도 사용되지 않았습니다.
요즘 하드웨어는 빠르게 발전하고 있습니다. 10,000개의 데이터만 캐시하면 사용 여부에 관계없이 10,000개의 데이터를 모두 캐시에 넣을 수 있습니다. 캐시의 데이터. 추가 작업을 수행하거나 데이터베이스에 요청할 필요가 없습니다.
그러나 하드웨어는 빠르게 발전하고 데이터의 양도 빠르게 발전합니다. 소규모 웹사이트의 경우 10,000개의 데이터를 캐시하면 모두 캐시됩니다. 그러나 대규모 웹사이트에는 최소한 수백만 개의 데이터 또는 T 수준 데이터가 있습니다. 물론 이 모든 데이터를 캐시에 넣을 수는 없습니다. 이때 합리적인 캐싱 솔루션을 설계하고 캐시 적중률을 높이는 것이 매우 중요합니다. 그리고 그것은 필요합니다.
캐시 적중률을 향상시키는 몇 가지 일반적인 방법
순전히 기술적 관점에서 보면 단위 시간당 사용자 요청 수만 기록하고 이 정보를 기반으로 가장 일반적으로 사용되는 데이터를 캐시합니다.
그러나 대부분의 경우 비즈니스 로직을 기반으로 캐시 적중률을 향상시킵니다. 예: 작년과 재작년에 게시된 블로그에서 이러한 유형의 기사에 대한 검색 요청은 일반적으로 하루에 몇 번 이상이었습니다. 일반적으로 메모리에 캐시하면 안 됩니다.
또 다른 예를 들어, 답글이 많은 게시물은 일반적으로 답글이 적은 게시물보다 더 많은 사람들이 봅니다.
캐시 적중률을 향상시키기 위해서는 위의 로직을 활용하고 실제 비즈니스 로직을 기반으로 캐싱 알고리즘을 제공해야 합니다. 하드웨어가 허용하는 한 모든 데이터가 아닌 적절한 데이터를 캐시해 보겠습니다.
부정적인 예는 다음과 같습니다. 대규모 블로그 사이트에서는 어떤 경우에도 사용자가 기사를 요청하면 해당 기사가 메모리 캐시에 없는 것으로 확인되어 데이터베이스에서 읽은 다음 캐시에 넣습니다.
아시다시피 현재 크롤러가 많이 있습니다. 또한, 블로그 등 검색 엔진 친화적인 사이트의 경우 대부분의 접근 압력은 검색 엔진에서 비롯됩니다. 이러한 방문은 일반적으로 한 시간 또는 하루이며, 특정 기사에 대해 몇 번 또는 한 번만 요청하고 다시는 요청하지 않습니다. 위의 캐싱 방법의 적중률은 매우 낮습니다.
Guo Hongjun님, 당신은 나에게 이 블로그의 콘텐츠를 캐시하라고 제안하지 않았기 때문에 여기에서 누군가가 질문할 수 있습니다. 하지만 적어도 내 블로그 사이트가 응답하기에 너무 느리지 않도록 하려면 어떻게 해야 내 사이트의 성능을 향상시킬 수 있습니까? 사용자 요청에.
이 문제에 대한 해결책은 여러 가지가 있습니다. 가장 간단한 방법 중 하나는 이러한 블로그를 파일 시스템의 캐시인 정적 HTML 페이지로 만드는 것입니다. 적중률이 낮은 많은 콘텐츠를 캐시하도록 합니다.
페이지에 동적 논리 판단이 필요한 경우 데이터를 XML 파일로 캐시한 다음 서버 세그먼트가 이러한 XML 파일을 통합하거나 파일을 포함할 수 있습니다. 이것은 또한 좋은 접근 방식입니다.
캐시 적중률에 대해 많은 문제가 언급되었으므로 캐시 적중률에 대한 견해를 간략하게 요약해 보겠습니다.
소규모 웹사이트는 모든 데이터를 캐시할 수 있으며 일반적으로 압력이 크지 않으므로 캐시 적중률 문제는 무시할 수 있습니다.
대규모 서비스에서는 전체 데이터를 캐싱할 수 없고, 데이터의 일부만 캐시 적중률을 최대한 높이기 위해 비즈니스 로직에 적합한 캐싱 방식을 설계해야 합니다.
적중률을 높이는 방법은 대부분 비즈니스 로직에 묶여 있으며 특정 문제에 대한 상세한 분석이 필요합니다. 메모리에 캐시할 수 없는 데이터의 경우 성능을 향상시키는 가장 간단한 방법은 파일 캐싱을 사용하는 것입니다.
파일 캐싱은 전체 콘텐츠를 정적 파일로 캐시할 수 있습니다. 또한 전체 페이지의 영역을 파일로 캐시한 다음 이를 포함할 수도 있으며, 캐시를 위해 엔터티를 XML 파일로 직렬화할 수도 있습니다.
캐싱의 덜 중요한 몇 가지 측면을 살펴보겠습니다.
캐시 수명주기 활동
만료되지 않거나 영원히 변경되지 않는 콘텐츠는 캐시에 저장하면 안 됩니다. 캐시는 영구 저장소가 아닌 임시 저장소이므로 캐시 수명 주기가 제한됩니다.
차례로 다음과 같은 활동을 거칠 수 있습니다.
캐시를 입력하세요. (캐시 입력 시 향후 만료 정책을 지정해야 할 수 있습니다. 지정하지 않은 경우 시스템 기본 만료 정책을 사용해야 합니다.)
캐시에서 이를 얻으십시오. 이때 스레드 안전 문제를 처리해야 합니다.
캐시를 업데이트할 때 캐시를 떠날 때 스레드 안전 문제도 고려해야 합니다. 이는 외부 요청일 수도 있고 캐시가 만료 정책에 따라 이를 지울 수도 있습니다.
캐시 만료 정책
일반적으로 나는 당신이 접촉한 캐시에서 어떤 캐시 만료 전략을 접했습니까?
가장 일반적인 만료 전략은 다음과 같습니다.
오랫동안 요청하지 않으면 만료됩니다. 가장 일반적인 것은 ASP 및 ASP.net에서 제공하는 섹션 기능입니다. 사실 그것은 캐시입니다.
파일 변경에 의존하는 캐시는 파일이 수정되면 만료됩니다(일반적으로 웹 사이트의 Web.config). 파일이 변경되면 캐시가 다시 시작될 뿐만 아니라 IIS 프로세스도 릴리스를 수행합니다.
이를 기반으로 많은 종속성에 대한 캐시 만료 정책을 볼 수 있습니다. 예를 들어 데이터베이스에 의존하는 캐시 만료 정책이 있습니다.
물론 비즈니스 로직에 더 복잡한 만료 전략이 있을 수 있습니다. CSDN 포인트 시스템 포럼의 새 버전에서는 목록 데이터 캐시가 600개에 도달하면 게시물 목록 캐시가 이를 550개의 데이터로 지웁니다.
또 다른 예는 게시물을 참조하는 목록이 없을 때 새 포인트 기반 포럼 게시물의 캐시가 만료되고 게시물이 만료되는 것입니다.
캐시 동기화 문제
캐시를 사용한다는 것은 동일한 데이터의 여러 복사본이 공존할 수 있음을 의미합니다. 코드에서 특정 상황을 고려하지 않으면 두 데이터가 일치하지 않게 됩니다. 이때 문제가 발생하게 됩니다.
해결책은 간단합니다. 비즈니스 로직과 코드 트리거 상황을 신중하게 생각하고 바닥에 닿지 않은 영역을 떠나지 마십시오.
간단한 방법으로 인해 코드 논리가 매우 복잡해질 수 있습니다.
이것이 일부 사람들이 필요하지 않은 경우 캐싱을 사용하지 말 것을 권장하는 이유입니다. 캐싱을 사용하기 시작하면 데이터 동기화를 처리하기 위해 많은 코드를 추가할 준비를 해야 합니다.
캐시 데이터 초기화 및 채우기
캐시가 초기화된 후 일부 데이터를 캐시에 미리 채워야 하는 경우가 있습니다. 캐시된 데이터의 초기화 작업입니다.
캐시된 데이터의 초기화 작업 중에 다음 문제를 고려해야 합니다.
초기화하는 데 시간이 얼마나 걸리나요? 일반적으로 사이트인 경우 Global.asa의 Application_OnStart에서 이 초기화 작업을 처리할 수 있습니다. 초기화는 일반적으로 너무 오래 걸릴 수 없습니다. 현재 코드 최적화 능력이 테스트됩니다.
초기화 중에는 일반적인 사용 중에 한 번에 하나의 데이터를 처리하는 대신 일반적으로 데이터를 일괄적으로 가져옵니다.
요약:
이 기사에서는 특정 캐싱 기술을 깊이 다루지 않고 캐싱에 대한 나의 견해를 소개합니다. 이 글의 설명을 통해 캐싱의 사용법만 알고 캐싱의 개념을 이해하지 못하는 분들이 예비적인 이해를 할 수 있기를 바랍니다.
http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx