캐시 침투는 클라이언트/브라우저 측에 존재하지 않는 키를 요청하는 것입니다. 이 키는 Redis에 존재하지 않으며, If마다 데이터베이스에 데이터 소스가 없습니다. 이 키에 대한 요청을 캐시에서 얻을 수 없으면 데이터 소스가 요청됩니다.
존재하지 않는 사용자 ID를 사용하여 사용자 정보에 접근하는 경우 Redis나 데이터베이스에 존재하지 않습니다. 다중 요청으로 인해 데이터 원본이 압도될 수 있습니다.
캐시나 쿼리가 없어야 합니다. 캐시는 누락이 있을 때 수동적으로 작성되므로 내결함성 때문에 쿼리할 수 없는 데이터는 Redis에 캐시되지 않습니다. 이로 인해 데이터가 캐시될 때마다 데이터베이스가 요청됩니다. 존재하지 않는 것이 요청되어 캐싱의 의미가 상실됩니다.
(1) 쿼리에서 반환된 데이터가 비어 있는 경우(데이터 존재 여부에 관계없이) 빈 결과(null)를 캐시하고 빈 결과의 만료 시간을 매우 짧게 설정합니다.
(2) 접근 가능한 목록 설정(화이트 리스트): 비트맵 유형을 사용하여 접근 가능한 목록을 정의합니다. 각 접근은 비트맵의 오프셋으로 사용됩니다. 비트맵 내부에 액세스 ID가 없으면 액세스를 차단하고 허용하지 않습니다.
(3) Bloom 필터
(4)를 사용하여 실시간 데이터 모니터링을 수행하면 Redis의 적중률이 급격히 감소할 때 액세스 개체 및 액세스 데이터를 확인하고 블랙리스트를 설정하는 것으로 나타났습니다.
사용자가 기존 키에 대한 데이터를 요청하면 redis의 키에 대한 데이터가 오래되었습니다. 데이터를 로드하고 이를 Redis에 캐시합니다. 이때 많은 양의 동시성이 데이터베이스 서비스를 압도할 수 있습니다.
특정 키의 데이터를 대량으로 요청하는 경우 이 키는 핫 데이터이므로 "고장" 문제를 피하기 위해 고려해야 합니다.
(1) 사전 설정된 인기 데이터: Redis 최대 액세스 이전에 일부 인기 데이터를 미리 Redis에 저장하고 이러한 인기 데이터 키의 길이를 늘립니다.
(2) 실시간 조정: 현장 모니터링 데이터가 대중적, 실시간으로 키 만료 길이 조정
(3) 잠금 사용:
은 즉시 db를 로드하는 것이 아니라 캐시가 만료되는 때(꺼낸 값은 빈 것으로 판단)입니다.
먼저 성공적인 작업 반환 값(예: Redis의 SETNX)과 함께 캐싱 도구의 일부 작업을 사용하여 뮤텍스 키를 설정합니다.
작업이 성공적으로 반환되면 db 로드 작업을 수행하고 캐시를 재설정합니다. 마지막으로 뮤텍스 키를 삭제합니다.
작업이 실패를 반환하면 db를 로드하는 스레드가 있음을 증명합니다. 일정 시간 동안 대기 상태에 있다가 전체 캐시 가져오기 메서드를 다시 시도합니다.
해당 데이터는 존재하지만 키 데이터가 만료되었습니다. (이때, 대규모의 Redis 캐시가 삭제됩니다.) 동시에 많은 수의 서로 다른 키에 액세스합니다. 즉, 이 시점에서 키는 만료 단계에 있으며 많은 수의 동시 요청이 요청됩니다. 이러한 상황을 캐시 사태라고 하며, 캐시 붕괴와의 차이점은 전자가 핵심입니다.
캐시가 만료될 때 눈사태 효과는 기본 시스템에 끔찍한 영향을 미칩니다!
(1) 다중 레벨 캐시 아키텍처 구축:
nginx 캐시 + redis 캐시 + 기타 캐시(ehcache 등)
(2) 잠금 또는 대기열 사용:
잠금 사용 또는 대기열을 사용하여 한 번에 데이터베이스를 읽고 쓰는 스레드 수가 많지 않도록 함으로써 오류 발생 시 기본 스토리지 시스템에 많은 수의 동시 요청이 떨어지는 것을 방지할 수 있습니다. 동시성이 높은 상황에는 적용할 수 없습니다.
(3) 캐시를 업데이트하도록 만료 플래그를 설정합니다.
캐시된 데이터가 만료되었는지 여부를 기록합니다(선불 금액 설정). 백그라운드 캐시에서 실제 키를 업데이트하기 위해 다른 스레드에 알림을 보냅니다.
(4) 캐시 만료 시간 분산:
예를 들어 원래 만료 시간에 무작위로 1~5분과 같은 임의의 값을 추가하여 각 캐시의 만료 시간이 반복률이 줄어들어 집단적인 실패를 일으키기 어렵습니다.
위 내용은 Redis 기반 데이터 캐싱의 일반적인 문제를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!