Redis 캐시 문제 분석 예시

1. Redis 캐시 적용

실제 비즈니스 시나리오에서 Redis는 일반적으로 관계형 데이터베이스 MySQL과 함께 사용하는 등 백엔드 데이터베이스에 대한 부담을 줄이기 위해 다른 데이터베이스와 함께 사용됩니다.

Redis는 핫스팟 데이터와 같이 자주 쿼리되는 데이터를 MySQL에 캐시합니다. 이러한 방식으로 사용자는 MySQL에 액세스할 필요 없이 Redis에 캐시된 데이터를 직접 얻을 수 있습니다. 백엔드 데이터베이스에 대한 읽기 부담을 줄입니다.

사용자가 쿼리한 데이터를 Redis에서 사용할 수 없는 경우, 사용자의 쿼리 요청은 MySQL 데이터베이스로 전송되며 MySQL은 데이터를 클라이언트에 반환할 때 Redis에도 데이터를 캐시합니다. 사용자는 이를 다시 읽을 수 있으며 Redis에서 직접 데이터를 가져올 수 있습니다. 흐름도는 다음과 같습니다.

Redis를 캐시 데이터베이스로 사용할 때 필연적으로 세 가지 일반적인 캐시 문제에 직면하게 됩니다.

• 캐시 침투

• 캐시 분석

• Cache Avalanche

2. Cache Penetration

2.1 Introduction

캐시 침투란 사용자가 특정 데이터를 쿼리했을 때 해당 데이터가 Redis에 존재하지 않으며, 캐시를 사용하면 쿼리 요청이 MySQL에 지속성 계층 데이터베이스로 전송됩니다. MySQL에는 빈 개체만 반환할 수 있으므로 쿼리가 실패했습니다. 이러한 요청이 많거나 사용자가 이러한 요청을 사용하여 악의적인 공격을 수행하는 경우 MySQL 데이터베이스에 큰 부담이 가해지고 심지어 붕괴되는 현상을 캐시 침투라고 합니다.

2.2 솔루션

빈 개체 캐시

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

Bloom 필터

먼저 사용자가 접근할 수 있는 핫스팟 데이터의 모든 키를 Bloom 필터에 저장합니다(캐시 예열이라고도 함)

, 사용자 요청이 있는 경우 먼저 Bloom 필터를 통과합니다. 블룸 필터는 요청한 키가 존재하는지 여부를 확인하며, 존재하지 않으면 요청을 직접 거부하고, 캐시가 없으면 먼저 쿼리를 실행합니다. 다시 데이터베이스에 쿼리하세요. 첫 번째 방법에 비해 Bloom 필터 방법을 사용하는 것이 더 효율적이고 실용적입니다. 프로세스 다이어그램은 다음과 같습니다.

캐시 워밍업은 시스템이 시작되기 전에 관련 데이터를 Redis 캐시 시스템에 미리 로드하는 프로세스입니다. 이렇게 하면 사용자가 요청할 때 데이터가 로드되는 것을 방지할 수 있습니다.

2.3 솔루션 비교

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

캐시 빈 개체: 빈 데이터에 적합한 키 수가 제한되어 있습니다. 키 요청이 반복될 가능성이 높습니다.

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

3. 캐시 분해 3.1 소개

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

3.2 솔루션

만료 시간 변경

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

분산 잠금

캐시 사용을 재설계하는 분산 잠금 방법을 채택합니다. 프로세스는 다음과 같습니다.

• Lock: 키로 데이터를 쿼리할 때 먼저 캐시를 쿼리합니다. 그렇지 않은 경우 분산 잠금을 통해 잠급니다. 잠금을 획득한 첫 번째 프로세스는 쿼리할 백엔드 데이터베이스에 들어가고 쿼리 결과를 Redis에 버퍼링합니다.

• Unlocking: 다른 프로세스가 특정 프로세스에 의해 잠금이 점유된 것을 발견하면 잠금 해제 후 다른 프로세스가 캐시된 키에 차례로 액세스합니다.

3.3 솔루션 비교

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

Mutex 잠금: 이 솔루션의 아이디어는 비교적 간단하지만, 캐시 구축 과정에 문제가 있거나 시간이 오래 걸릴 경우 숨겨진 위험이 있습니다. 스레드 풀 차단이 가능하지만 이 방법이 더 효율적일 수 있습니다. 좋은 방법은 백엔드 저장소 로드를 줄이고 더 나은 일관성을 제공합니다.

4. 캐시 사태

4.1 소개

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

4.2 솔루션

만료 처리

많은 수의 키가 동시에 만료되어 발생하는 캐시 고장 및 사태 문제를 줄이기 위해 핫스팟 데이터 절대 전략을 채택할 수 있습니다. 이는 캐시 눈사태와 다릅니다. 유사점이 있습니다. 또한 키가 동시에 만료되는 것을 방지하기 위해 키에 대한 만료 시간을 무작위로 설정할 수 있습니다.

redis 고가용성

한 Redis가 눈사태로 인해 중단될 수 있으며, Redis를 몇 개 더 추가하고 클러스터를 구축하면 나머지는 계속 작동할 수 있습니다.

위 내용은 Redis 캐시 문제 분석 예시의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!