하나의 기사로 Redis 캐시 사태, 캐시 분석 및 캐시 침투를 이해하세요.

이 글은 Redis에 대한 관련 지식을 제공하며, 캐시 눈사태, 캐시 고장 및 캐시 침투에 대한 관련 내용을 주로 소개합니다. 모두에게 도움이 되기를 바랍니다.

추천 학습: Redis 비디오 튜토리얼

Redis의 고주파 문제와 관련하여 캐시 눈사태, 캐시 고장 및 캐시 침투는 인터뷰 중에 모두가 비슷한 질문을 받았을 것이라고 생각합니다. 이러한 질문이 왜 그렇게 인기가 있습니까? Redis 캐시를 사용하면 이러한 문제가 발생하기 쉽기 때문입니다. 다음으로 이러한 문제가 어떻게 발생하는지, 그리고 그에 따른 해결방안은 무엇인지 살펴보겠습니다.

Cache Avalanche

먼저 캐시 Avalanche에 대해 살펴보겠습니다. Cache Avalanche의 개념은 다음과 같습니다. Redis 캐시에서 많은 수의 요청이 처리되지 않아 요청이 데이터베이스로 넘치게 되고 이에 대한 압박이 발생합니다. 데이터베이스가 극적으로 증가합니다.

캐시 눈사태가 발생하는 이유는 두 가지로 요약할 수 있습니다.

• 캐시에 있는 많은 양의 데이터가 동시에 만료되므로 이때 데이터베이스로 많은 양의 요청이 전송됩니다.
• Redis 캐시 인스턴스가 실패하고 많은 수의 요청을 처리할 수 없으며 이로 인해 요청이 데이터베이스로 이동하게 됩니다.

첫 번째 시나리오를 살펴보겠습니다. 캐시에 있는 많은 양의 데이터가 동시에 만료됩니다.

캐시에 있는 많은 양의 데이터가 동시에 만료되었습니다

전설에 따르면 많은 양의 데이터가 동시에 만료되었으며, 이때 해당 데이터를 읽어 달라는 요청이 많았음을 의미합니다. 물론, 캐시 사태가 발생하여 데이터베이스 압력이 급격히 증가하게 됩니다.

대량의 데이터가 동시에 만료되는 솔루션

대량의 데이터가 동시에 만료되는 문제를 처리하려면 일반적으로 두 가지 솔루션이 있습니다.

• 랜덤 증가 데이터 만료 설정의 시간: 즉, 만료 명령을 사용하여 데이터 만료 시간을 설정하는 경우 임의의 시간을 추가합니다. 예를 들어 데이터 a는 5분 후에 만료되고 10~120초가 5에 무작위로 추가됩니다. 분. 이렇게 하면 대량의 데이터가 동시에 만료되는 것을 방지할 수 있습니다.
• 서비스 저하: 즉, 캐시 눈사태가 발생하면 (1) 액세스가 핵심 데이터가 아닌 경우 캐시 적중이 없으면 데이터베이스가 데이터베이스로 이동하지 않으며 null 값과 같은 사전 설정 정보 ​또는 오류 메시지가 직접 반환됩니다. (2) 핵심 데이터에 액세스하고 캐시가 누락되면 데이터베이스 쿼리가 허용됩니다. 이런 방식으로 핵심 데이터가 아닌 요청은 거부되어 데이터베이스로 전송됩니다.

대량의 데이터가 동시에 만료되는 상황에 이어 Redis 캐시 인스턴스 장애 상황을 살펴보겠습니다.

Redis 캐시 인스턴스 장애로 인한 캐시 사태

이 경우 Redis는 읽기 요청을 처리할 수 없으며 해당 요청은 자연스럽게 데이터베이스로 이동하게 됩니다.

일반적으로 이 상황을 처리하는 방법에는 두 가지가 있습니다. 비즈니스 시스템에서

회로 차단기 서비스/전류 제한 요청

을 수행하세요.
• 사전 주의사항: 마스터-슬레이브 클러스터 전환과 같은 Redis 고신뢰성 클러스터를 구축하세요.
• 서비스 서킷 브레이커, 즉 Redis가 실패하면 캐시 시스템에 대한 액세스 요청이 일시 중지됩니다. 액세스 요청을 열기 전에 Redis가 정상으로 돌아올 때까지 기다리십시오.

이런 방식으로 MySQL의 로드 압력, Redis의 CPU 사용량, 메모리 사용량 및 QPS 등과 같은 Redis 또는 데이터베이스의 실행 상태를 모니터링해야 합니다. Redis 인스턴스 캐시가 붕괴된 것이 발견되면 서비스가 일시 중단됩니다.

이러한 상황은 실제로 많은 수의 요청을 배치하고 데이터베이스에 압력을 가할 수 있습니다. 다만, 접근 요청이 일시 중단될 예정이며, 이는 비즈니스 측면에 큰 영향을 미치게 됩니다.

따라서 비즈니스 측면에 미치는 영향을 줄이기 위해 요청 전류 제한을 사용하여 QPS를 제어하고 데이터베이스에 대한 너무 많은 요청을 피할 수 있습니다. 예를 들어 아래 그림에는 초당 20,000개의 요청이 있지만 Redis 오류로 인해 다운되었습니다. 현재 제한 작업은 qps를 초당 2,000으로 줄였고 데이터베이스는 여전히 2,000 qps를 처리하는 데 문제가 없었습니다.

캐시 분석

캐시 분석은 자주 액세스하는 개별 핫스팟 데이터를 캐시할 수 없게 되어 요청이 데이터베이스로 쏟아지는 것을 의미합니다. 핫스팟 데이터가 만료되면 종종 발생합니다.

캐시 고장 문제에 관해서는 매우 자주 액세스되는 핫 데이터이므로 처리 방법이 간단하고 투박하며 만료 시간이 직접 설정되지 않는 것으로 알고 있습니다. 핫스팟 데이터에 자주 액세스하지 않을 때까지 기다렸다가 수동으로 처리하면 됩니다.

캐시 침투

캐시 사태는 특별한 것입니다. 즉, 액세스할 데이터가 Redis 캐시나 데이터베이스에 없다는 의미입니다. 많은 수의 요청이 시스템에 들어오면 Redis와 데이터베이스는 엄청난 압박을 받게 됩니다.

캐시 침투에는 일반적으로 두 가지 이유가 있습니다.

• 데이터가 실수로 삭제되어 캐시와 데이터베이스에 데이터가 없습니다. 그러나 클라이언트는 이를 모르고 여전히 필사적으로 요청하고 있습니다.
• 악의적인 공격의 경우가 있습니다. 즉, 누군가가 사용할 수 없는 데이터를 확인하기 위해 당신을 표적으로 삼고 있다는 것입니다.

캐시 침투에 대해서는 다음 해결 방법을 참조할 수 있습니다.

• 은 캐시에 null 값 또는 기본값을 설정하는 것입니다. 예를 들어 캐시 침투가 발생하면 Redis 캐시에 null 값/기본값을 설정합니다. 이 값에 대한 후속 쿼리는 이 기본값을 직접 반환합니다.
• 블룸 필터를 사용하여 데이터가 존재하는지 확인하고 데이터베이스에서 쿼리하지 마세요.
• 프런트 엔드에서 요청 감지를 수행합니다. 예를 들어 일부 불법 요청을 처리를 위해 백엔드로 보내는 대신 프런트 엔드에서 직접 필터링할 수 있습니다.

첫 번째와 세 번째 사항은 이해하기 쉬우므로 여기서는 설명하지 않겠습니다. 두 번째 사항인 블룸 필터에 초점을 맞춰 보겠습니다.

Bloom 필터

Bloom 필터는 주로 요소가 집합에 있는지 확인하는 데 사용됩니다. 이는 고정 크기 바이너리 벡터(기본값이 0인 비트 배열로 이해될 수 있음)와 일련의 매핑 함수로 구성됩니다.

먼저 블룸 필터가 데이터를 어떻게 표시하는지 살펴보겠습니다.

• 첫 번째 단계에서는 여러 매핑 함수(해시 함수)가 사용되며 각 함수는 데이터의 해시 값을 계산합니다. 두 번째 단계에서는 계산된 해시 값이 비트 배열의 길이에 따라 각각 모듈로가 되어 배열에서 각 해시 값의 위치를 ​​얻습니다.
• 세 번째 단계, 두 번째 단계에서 위치는 각각 다음과 같습니다. 비트 배열에서 1로 설정됩니다.
• 이 3단계를 거쳐 데이터 라벨링이 완료됩니다. 그런 다음 데이터가 없을 때 쿼리하려면 다음을 수행하십시오.

먼저 비트 배열에서 이 데이터의 여러 위치를 계산합니다.

• 그런 다음 비트 배열에서 이러한 위치의 비트 값을 각각 확인합니다. 각 위치의 비트 값이 1인 경우에만 데이터가 존재할 수 있다는 의미이고, 그렇지 않으면 해당 데이터가 존재하지 않아야 한다는 의미입니다.
• 아래 사진을 보시면 기본 원리는 이렇습니다.

추천 학습:

Redis 비디오 튜토리얼

위 내용은 하나의 기사로 Redis 캐시 사태, 캐시 분석 및 캐시 침투를 이해하세요.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!