Redis의 세 가지 캐싱 문제에 대해 이야기해 보겠습니다.

이 글은 Redis에 대한 관련 지식을 제공합니다. 주로 캐시 침투, 캐시 고장, 캐시 눈사태라는 세 가지 유형의 캐시 문제를 소개합니다.

추천 학습: Redis 학습 튜토리얼

1. Redis 캐시 적용

실제 비즈니스 시나리오에서 Redis 은 일반적으로 다른 데이터베이스와 함께 사용되어 예를 들어 엔드엔드 데이터베이스는 관계형 데이터베이스인 MySQL과 함께 사용됩니다.

Redis는 핫 데이터와 같이 MySQL에 자주 쿼리되는 데이터를 MySQL에 캐시하므로 사용자가 방문할 때 MySQL에서 쿼리할 필요 없이 Redis에서 직접 캐시된 데이터를 얻을 수 있습니다. 따라서 백엔드 데이터베이스에 대한 읽기 부담이 줄어듭니다.

사용자가 쿼리한 데이터를 Redis에서 사용할 수 없는 경우 사용자의 쿼리 요청은 MySQL 데이터베이스로 전송됩니다. MySQL이 클라이언트에 데이터를 반환하면 Redis에도 데이터가 캐시됩니다. 사용자가 데이터에 다시 액세스할 수 있도록 읽기 시 Redis에서 직접 데이터를 가져올 수 있습니다. 순서도는 다음과 같습니다.

물론 Redis를 캐시 데이터베이스로 사용할 때 일반적인 3가지 캐싱 문제에 직면하게 됩니다.

• 캐시 침투
• 캐시 침투
• 캐시 눈사태

2. 캐시 침투

2.1 소개

캐시 침투 는 사용자가 특정 데이터를 쿼리할 때를 의미합니다. , Redis에 데이터가 존재하지 않습니다. 즉, 캐시가 적중되지 않습니다. 이때 쿼리 요청은 MySQL에 데이터가 존재하지 않는 것으로 나타났습니다. 쿼리가 실패했음을 나타내는 빈 개체만 반환됩니다. 이러한 요청이 너무 많거나 사용자가 이러한 요청을 사용하여 악의적인 공격을 수행하는 경우 MySQL 데이터베이스에 큰 부담을 주고 심지어 붕괴되는 현상을 캐시 침투라고 합니다.

2.2 솔루션

빈 개체 캐시

MySQL이 빈 개체를 반환하면 Redis는 개체를 캐시하고 만료 시간을 설정합니다. 사용자가 동일한 요청을 다시 시작하면 캐시에서 빈 개체를 얻습니다. 사용자의 요청은 캐시 계층에서 차단되므로 백엔드 데이터베이스가 보호됩니다. 그러나 이 접근 방식에도 몇 가지 문제가 있습니다. 요청이 MSQL에 들어갈 수 없지만 이 전략은 Redis 캐시 공간을 차지합니다.

블룸 필터

먼저 사용자가 액세스할 수 있는 핫스팟 데이터의 모든 키를 블룸 필터(캐시 예열이라고도 함)

에 저장합니다. 사용자가 있을 때 요청이 먼저 진행됩니다. Bloom 필터는 요청된 키가 존재하는지 확인합니다. 존재하지 않으면 요청이 직접 거부됩니다. 그렇지 않으면 쿼리가 캐시에서 먼저 수행됩니다. 캐시가 존재하지 않으면 데이터베이스로 이동하여 쿼리하세요. 첫 번째 방법에 비해 Bloom 필터 방법을 사용하는 것이 더 효율적이고 실용적입니다. 프로세스 다이어그램은 다음과 같습니다.

캐시 예열

: 시스템 시작 시 관련 데이터를 미리 Redis 캐시 시스템에 로드하는 것을 말합니다. 이렇게 하면 사용자가 요청할 때 데이터가 로드되는 것을 방지할 수 있습니다.

2.3 솔루션 비교

두 솔루션 모두 캐시 침투 문제 를 해결할 수 있지만 사용 시나리오는 다릅니다.

빈 개체 캐시 : 빈 데이터에 적합한 키 수 시나리오 반복되는 키 요청 가능성이 높습니다.

Bloom 필터: 빈 데이터의 키가 다르고 키 요청이 반복될 확률이 낮은 시나리오에 적합합니다.

3. 캐시 분해

3.1 소개

캐시 분해 는 사용자가 쿼리한 데이터가 캐시에는 존재하지 않고 백엔드 데이터베이스에는 존재한다는 의미입니다. 일반적으로 캐시에 있는 키가 만료되어 발생합니다. 예를 들어, 핫 데이터 키는 항상 많은 수의 동시 액세스를 수신합니다. 특정 순간에 키가 갑자기 실패하면 많은 수의 동시 요청이 백엔드 데이터베이스에 들어가므로 압력이 즉시 증가합니다. 이 현상을 캐시 고장이라고 합니다.

3.2 솔루션

만료 시간 변경

핫스팟 데이터가 만료되지 않도록 설정하세요.

Distributed Lock

에서는

Distributed Lock 방식을 채택하여 캐시 사용 방식을 재설계했습니다. 프로세스는 다음과 같습니다.

• Lock: 키로 쿼리하는 경우 데이터가 생성되면 캐시가 먼저 쿼리됩니다. 그렇지 않은 경우 잠금을 획득한 첫 번째 프로세스가 백엔드 데이터베이스에 들어가 쿼리되고 쿼리 결과가 Redis에 버퍼링됩니다.
• Unlocking: 다른 프로세스가 특정 프로세스에 의해 잠금이 점유된 것을 발견하면 잠금 해제 후 다른 프로세스가 캐시된 키에 차례로 액세스합니다.

3.3 솔루션 비교

Never 만료: 이 솔루션은 실제 만료 시간을 설정하지 않기 때문에 실제로 핫스팟 키로 인한 일련의 위험은 없지만 데이터 불일치 상황이 발생합니다. 코드 복잡성이 증가합니다.

Mutex lock: 이 솔루션의 아이디어는 비교적 간단하지만, 캐시 구축 과정에 문제가 있거나 시간이 오래 걸릴 경우 숨겨진 위험이 있습니다. 교착 상태 및 스레드 풀 차단이 있지만 이 방법을 사용하면 백엔드 저장소 로드를 더 효과적으로 줄이고 더 나은 일관성을 얻을 수 있습니다. 4. Cache Avalanche

4.1 소개

Cache Avalanche는 캐시에 있는 많은 수의 키가 동시에 만료되고 이때 데이터 액세스량이 매우 크다는 것을 의미합니다. 백엔드 데이터베이스 압력이 갑자기 증가하거나 심지어 중단되는 현상을 캐시 눈사태라고 합니다. 캐시 고장은 동시성이 특히 클 때 특정 단축키가 갑자기 만료될 때 발생하는 반면, 캐시 눈사태는 동시에 많은 수의 키가 만료될 때 발생하므로 순서가 동일하지 않습니다. 규모가 전혀.

4.2 솔루션

만료 처리

캐시 눈사태와 캐시 고장은 유사하므로 핫스팟 데이터가 만료되지 않음

방법을 사용하여 대규모 배치 키가 동시에 만료되는 것을 줄일 수도 있습니다. 시간. 또한

키의 중앙 만료 시간을 무작위로 설정

하여 키의 중앙 집중식 만료를 방지합니다. redis 고가용성

한 Redis가 눈사태로 인해 중단될 수 있습니다. 그런 다음 Redis를 몇 개 더 추가하고 클러스터를 구축

하면 나머지는 계속 작동할 수 있습니다. .

추천 학습: Redis 학습 튜토리얼

위 내용은 Redis의 세 가지 캐싱 문제에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!