적중: 필요한 데이터는 캐시를 통해 직접 얻을 수 있습니다.
Missed: 원하는 데이터를 캐시를 통해 직접 얻을 수 없으며, 데이터베이스에 다시 쿼리하거나 다른 작업을 수행해야 합니다. 그 이유는 단순히 캐시에 존재하지 않거나 캐시가 만료되었기 때문일 수 있습니다.
일반적으로 캐시 적중률이 높을수록 캐시 사용의 이점이 높아지고 애플리케이션 성능이 향상되며(응답 시간이 짧을수록 처리량이 높아짐) 동시성에 저항하는 능력이 강해집니다.
고동시 인터넷 시스템에서는 캐시 적중률이 중요한 지표임을 알 수 있습니다.
memcached에서 state 명령을 실행하면 memcached 서비스의 상태 정보를 볼 수 있습니다. 여기서 cmd_get은 총 get 수, get_hits는 총 적중 수, 적중률 = get_hits를 나타냅니다. /cmd_get.
물론 일부 오픈 소스 타사 도구를 통해 전체 memcached 클러스터를 모니터링할 수도 있으며 디스플레이가 더욱 직관적이 될 것입니다. 일반적인 것에는 zabbix, MemAdmin 등이 있습니다.
그림에 표시된 대로: MemCached 서비스의 적중률에 대한 MemAdmin의 모니터링 통계
마찬가지로 redis에서는 info 명령을 실행하여 redis 서비스의 상태 정보를 볼 수 있습니다. 여기서 keyspace_hits는 총 적중 횟수 및 keyspace_misses 총 실패 횟수이며, 적중률 = keyspace_hits/(keyspace_hits+keyspace_misses)입니다.
오픈 소스 도구인 Redis-star는 Redis 서비스 관련 정보를 차트로 시각화하는 동시에 Redis 서비스를 모니터링하기 위한 관련 플러그인도 제공합니다.
이전 장에서 캐시 적중률에 영향을 미치는 여러 요소를 분석해 보겠습니다.
캐시는 "읽기는 많고 쓰기는 적다"는 비즈니스 시나리오에 적합합니다. 반대로 캐시 사용의 의미는 실제로 크지 않으며 적중률도 매우 낮습니다.
비즈니스 요구 사항에 따라 적시성 요구 사항이 결정되며 이는 캐시 만료 시간 및 업데이트 전략에 직접적인 영향을 미칩니다. 적시성 요구 사항이 낮을수록 캐싱에 더 적합합니다. 동일한 키, 동일한 요청 수의 경우 캐시 시간이 길어질수록 적중률이 높아집니다.
캐시는 대부분의 인터넷 애플리케이션 비즈니스 시나리오에 매우 적합합니다.
일반적으로 캐시 세분성이 작을수록 적중률이 높아집니다. 실제적인 예를 들어보겠습니다.
단일 개체(예: 단일 사용자 정보)를 캐싱할 때 개체에 해당하는 데이터가 변경될 때만 캐시를 업데이트하거나 캐시를 제거하면 됩니다. 컬렉션(예: 모든 사용자 데이터)을 캐시할 때 개체에 해당하는 데이터가 변경되면 캐시를 업데이트하거나 제거해야 합니다.
또 다른 상황이 있는데, 다른 곳에서도 해당 개체에 해당하는 데이터를 얻어야 한다고 가정하면(예를 들어 다른 곳에서도 개별 사용자 정보를 얻어야 함) 캐시가 단일 개체인 경우 캐시를 직접 칠 수 있습니다. , 그렇지 않으면 직접 타격을 할 수 없습니다. 이는 더 유연하며 캐시 적중률도 더 높아집니다.
또한 캐시 업데이트/만료 정책도 캐시 적중률에 직접적인 영향을 미칩니다. 데이터가 변경되면 캐시된 값을 직접 업데이트하는 것이 캐시를 제거하거나 캐시를 만료시키는 것보다 적중률이 더 높습니다. 물론 시스템 복잡성도 더 높아집니다.
캐시는 용량이 제한되어 있어 캐시 오류 및 제거가 쉽게 발생할 수 있습니다(현재 대부분의 캐시 프레임워크 또는 미들웨어는 LRU 알고리즘을 사용합니다). 동시에 캐시 기술의 선택도 중요합니다. 예를 들어, 애플리케이션에 내장된 로컬 캐시를 사용하면 단일 시스템 병목 현상이 발생할 가능성이 높아지지만 분산 캐시를 사용하면 확장이 쉽습니다. 따라서 시스템 용량을 계획하고 확장 가능 여부를 고려해야 합니다. 또한 다양한 캐싱 프레임워크나 미들웨어의 효율성과 안정성도 다릅니다.
캐시 노드에 장애가 발생하면 캐시 무효화를 방지하고 영향을 최소화해야 합니다. 이 특별한 상황도 설계자가 고려해야 합니다. 업계의 일반적인 접근 방식은 일관된 해시 알고리즘이나 노드 중복성을 사용하는 것입니다.
일부 친구들은 다음과 같이 오해할 수 있습니다. 비즈니스 요구 사항은 데이터 적시성에 대한 요구 사항이 높고 캐시 시간이 캐시 적중률에 영향을 미치므로 시스템은 캐시를 사용해서는 안 됩니다. 실제로 이는 중요한 요소 동시성을 무시합니다. 일반적으로 동일한 캐시 시간과 키에서 동시성이 높을수록 캐시 시간이 짧더라도 캐시 수익이 높아집니다.
설계자의 관점에서 애플리케이션은 가능한 한 캐시를 통해 직접 데이터를 얻고 캐시 무효화를 방지해야 합니다. 이는 또한 설계자의 능력을 테스트하기 위해 비즈니스 요구 사항, 캐시 세분성, 캐시 전략 및 기술 선택과 같은 다양한 측면에서 포괄적인 고려와 절충이 필요합니다. 자주 액세스하고 적시성 요구 사항이 낮은 핫 서비스에 최대한 집중하고, 캐시 사전 로드(워밍), 저장 용량 증가, 캐시 세분성 조정, 캐시 업데이트를 통해 적중률을 향상시킵니다.
적시성이 높거나 캐시 공간이 제한되어 있고, 콘텐츠 범위가 크거나(또는 매우 무작위 액세스), 액세스량이 낮은 애플리케이션의 경우 캐시 적중률이 오랫동안 매우 낮을 수 있으며, 예열된 캐시는 액세스하기 전에 만료됩니다.
Redis 관련 기술 기사를 더 보려면 Redis 튜토리얼 열을 방문하세요. 배우다 !
위 내용은 Redis 캐시 적중률을 향상하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!