Redis 캐시의 세 가지 주요 예외를 처리하는 방법

1. 배경

Redis는 완전 오픈 소스, BSD 호환, 고성능 키-값 데이터 구조 저장 시스템으로 데이터 지속성을 지원하며 데이터를 디스크에 저장할 수 있습니다. 간단한 키-값 유형의 데이터를 지원할 뿐만 아니라 매우 강력한 list, set, zset, hash 등과 같은 데이터 구조의 저장 기능도 제공합니다. Redis는 데이터 백업, 즉 마스터-슬레이브 모드의 데이터도 지원합니다. . 백업을 수행하여 가용성을 높입니다. 빠른 읽기 및 쓰기 속도가 가장 중요합니다. 일상적인 개발에서 가장 자주 사용되는 캐싱 솔루션으로 널리 사용되었기 때문입니다. 그러나 실제 적용 과정에서는 캐시 사태, 캐시 고장, 캐시 침투 등의 비정상적인 상황이 발생할 수 있으며, 이러한 상황을 무시하면 치명적인 결과를 초래할 수 있습니다. 다음에서는 이러한 캐시 예외 사항과 일반적인 처리 솔루션을 주로 분석합니다. .

2. Cache Avalanche

(1)

이란? 일정 기간 동안 Redis Cache에서 처리해야 할 대량의 요청을 처리를 위해 데이터베이스로 보내어 데이터베이스에 부담을 줍니다. 급격하게 증가하고, 심한 경우에도 데이터베이스가 충돌해 시스템 전체가 충돌하는 사태가 발생해 연쇄 효과를 일으킬 수 있어 캐시 사태라고 부른다.

(2) 이유

위 상황이 발생하는 일반적인 이유는 주로 다음 두 가지 점입니다.

• 캐시된 데이터의 대량이 동시에 만료되어 캐시에서 요청해야 하는 데이터가 발생합니다. 데이터베이스에서 다시 가져옵니다.

• redis 자체가 실패하고 요청을 처리할 수 없는 경우 요청은 자연스럽게 데이터베이스로 전송됩니다.

(3) 해결 방법

대량의 캐시 데이터가 동시에 만료되는 상황:

• 실제로 만료 시간을 설정할 때, 많은 수의 키가 동시에 만료되는 경우 이를 전달합니다. 동시에 만료되지 않도록 만료 시간을 무작위로 설정하고 균등하게 설정합니다.

• 캐시 구축 작업이 동시에 수행되지 않도록 뮤텍스 잠금을 추가하세요.

• 이중 키 전략에서는 기본 키가 원본 캐시이고, 백업 키가 복사본 캐시입니다. 기본 키가 만료되면 백업 키에 액세스할 수 있습니다. 기본 키의 캐시 만료 시간은 짧게 설정됩니다. -term이고 백업 키가 장기로 설정되어 있습니다.

• 예약된 작업이나 메시지 대기열을 사용하여 Redis 캐시 등을 업데이트하거나 제거하는 등 백그라운드에서 캐시 전략을 업데이트합니다.

redis 자체가 실패한 상황의 경우:

• 방지 수준에서는 마스터-슬레이브 노드를 통해 고가용성 클러스터를 구축할 수 있습니다. 즉, 마스터 Redis 인스턴스가 중단된 후 다른 슬레이브 라이브러리도 빠르게 메인 데이터베이스로 전환해 서비스를 계속 제공합니다.

• 사고가 발생하면 너무 많은 요청으로 인해 데이터베이스가 충돌하는 것을 방지하기 위해 서비스 회로 차단기 또는 요청 전류 제한 전략을 채택할 수 있습니다. 물론 서비스 회로 차단기는 Redis 서비스가 복원될 때까지 서비스를 중지하는 상대적으로 거칠고 요청 전류 제한은 상대적으로 완만하여 일부 요청을 처리할 수 있습니다. 그러나 구체적인 비즈니스 상황에 따라 적절한 솔루션을 선택하는 것은 여전히 ​​필요합니다.

3. 캐시 분해

(1)

캐시 분해는 일반적으로 많은 수의 동시 사용자가 동시에 캐시에는 없지만 데이터베이스에 있는 데이터를 요청하는 높은 동시성 시스템에서 발생합니다. 즉, 읽기 캐시가 데이터를 읽지 않은 동시에 데이터를 가져오기 위해 데이터베이스로 이동하여 데이터베이스 압력이 순간적으로 증가했습니다. Cache Avalanche는 Cache Avalanche와 달리 동일한 데이터를 동시에 쿼리하는 것을 의미하며, Cache Avalanche는 다른 데이터가 만료되어 많은 데이터를 찾을 수 없어 데이터베이스를 검색하는 것을 의미합니다.

(2) 이유

사실 이런 상황이 발생하는 일반적인 이유는 특정 핫 데이터 캐시가 만료되었기 때문입니다. 핫 데이터이기 때문에 동시 요청 수가 많아 만료되면 여전히 남아 있을 것입니다. 동시에 많은 수의 요청이 들어오고 캐시를 업데이트할 시간이 없습니다. 모두 데이터베이스로 전송됩니다.

(3) 해야 할 일

이 상황에 대한 두 가지 일반적인 해결책이 있습니다:

• 간단하고 거칠게 핫스팟 데이터의 만료 시간을 설정하지 않아 만료되지 않도록 하며, 자연스럽게 위의 내용을 따릅니다. 발생하지 않습니다. 이런 경우 나중에 정리하고 싶다면 백그라운드를 통해 정리하면 됩니다.

• 뮤텍스 잠금을 추가하세요. 즉, 만료된 후 첫 번째 쿼리 요청을 제외하고 잠금 요청을 데이터베이스에서 가져와서 캐시에 다시 업데이트할 수 있습니다. 동시에 새 캐시도 업데이트되고 후속 요청이 캐시에 요청되므로 캐시 중단이 발생하지 않습니다.

4. 캐시 침투

(1)

캐시 침투란 데이터가 Redis에도 없고 데이터베이스에도 없다는 뜻으로, 요청이 올 때마다 캐시에서 찾을 수 없다는 의미입니다. 해당 키를 얻으려면 매번 데이터베이스에 가서 다시 쿼리해야 하고 데이터베이스에 해당 키가 없다는 것을 찾아야 하는데 이는 두 개의 쓸모 없는 쿼리와 동일합니다. 이런 식으로 요청은 캐시를 우회하고 데이터베이스를 직접 확인할 수 있으며, 이때 누군가가 악의적으로 시스템을 공격하려는 경우 의도적으로 null 값이나 기타 존재하지 않는 값을 사용하여 빈번하게 요청을 할 수 있습니다. 데이터베이스에 더 큰 부담을 줍니다.

(2) 왜

이런 현상이 나타나는 이유는 실제로 사용자가 비즈니스 로직에서 특정 정보에 대해 해당 작업이나 처리를 수행하지 않았다면 해당 정보가 저장된 해당 데이터베이스나 캐시는 자연스럽게 이해하기 쉽습니다. 해당 데이터에는 위와 같은 문제가 발생하기 쉽습니다.

(3) 해결 방법

캐시 침투에 대해서는 일반적으로 세 가지 해결 방법이 있습니다.

• 불법 요청에 대한 제한은 주로 매개 변수 확인, 인증 확인 등을 참조하므로 처음부터 다수의 불법요청은 실제 사업발전에 꼭 필요한 수단입니다.

• 캐시 빈 값 또는 기본값. 캐시에서 얻을 수 없는 데이터를 데이터베이스에서 얻을 수 없는 경우에도 빈 결과를 캐시하고 만료 시간을 더 짧게 설정합니다. 이 설정의 기본값은 캐시에 저장되므로 데이터베이스에 계속 액세스하지 않고 캐시에서 두 번째로 값을 가져오므로 다수의 악의적인 요청이 동일한 키를 반복적으로 사용하여 공격하는 것을 방지할 수 있습니다.

• 블룸 필터를 사용하면 데이터 존재 여부를 빠르게 확인할 수 있습니다. 그러면 블룸 필터란 무엇입니까? 간단히 말해서 여러 개의 독립적인 해시 함수를 도입하여 주어진 공간과 오판율 내에서 요소 가중치 결정이 완료되도록 할 수 있습니다. 해시 충돌과 같은 상황이 있다는 것을 알고 있기 때문에 하나의 해시 함수만 사용하면 충돌 확률이 분명히 높아집니다. 이 충돌을 줄이기 위해 여러 해시 함수를 추가로 도입할 수 있으며 Bloom 필터링이 핵심입니다. 해시 알고리즘의 아이디어는 이러한 충돌을 해결하기 위해 여러 가지 다른 해시 함수를 사용하는 것입니다. 장점은 다른 알고리즘을 훨씬 능가하는 높은 공간 효율성과 짧은 쿼리 시간입니다. 단점은 요청된 키가 이 데이터로 블룸 필터의 검증을 통과한다는 것을 완전히 보장할 수 없다는 것입니다. 이론적으로는 확률이 아무리 작더라도 여전히 갈등이 있을 것입니다. 그러나 Bloom 필터 확인을 통과하지 못하는 한 키는 존재하지 않아야 합니다. 이를 사용하는 한 실제로는 존재하지 않는 키에 대한 대부분의 요청을 필터링할 수 있으며 이는 일반적인 시나리오에서 충분합니다.

5. 기타

위의 세 가지 일반적인 Redis 캐시 예외 문제 외에도 캐시 예열 및 캐시 다운그레이드라는 두 용어도 예외 문제가 아닌 두 가지 용어로 자주 듣습니다. 최적화 처리 방법.

(1) 캐시 예열

시스템이 온라인 상태가 되기 전과 후에 캐시 예열은 사용자 작업에 의존하지 않고 관련 캐시 데이터를 캐시 시스템에 직접 로드합니다. 이렇게 하면 먼저 데이터베이스를 쿼리한 다음 사용자가 요청할 때 데이터를 캐싱하는 문제를 피할 수 있습니다. 사용자는 미리 예열된 캐시 데이터를 직접 쿼리합니다. 이를 통해 시스템 시작 초기 단계에서 데이터베이스에 액세스하는 높은 동시 트래픽을 방지하여 데이터베이스에 트래픽 부담을 줄 수 있습니다.

데이터의 크기에 따라 다음 방법을 사용할 수 있습니다.

• 데이터의 양이 크지 않습니다. 프로젝트가 시작되면 자동으로 로드됩니다.

• 대량의 데이터: 백그라운드에서 정기적으로 캐시를 새로 고칩니다.

• 엄청난 양의 데이터: 핫스팟 데이터에 대해서만 사전 로드 캐시 작업을 수행하세요.

(2) 캐시 다운그레이드

캐시 다운그레이드란 캐시에 장애가 발생하거나 캐시 서비스에 문제가 발생한 경우 캐시 서비스 장애로 인해 데이터베이스에 눈사태 문제가 발생하는 것을 방지하기 위해 데이터베이스를 다운그레이드하는 것을 의미합니다. 액세스했지만 어떤 이유로 인해 서비스가 확실히 손실되더라도 여전히 기본적으로 서비스를 사용할 수 있는지 확인하려고 합니다. 따라서 중요하지 않은 캐시 데이터에 대해서는 서비스 저하 전략을 채택할 수 있습니다.

일반적으로 두 가지 방법이 있습니다.

• 메모리 부분의 데이터 캐시에 직접 액세스합니다.

• 시스템 설정의 기본값으로 바로 돌아갑니다.

위 내용은 Redis 캐시의 세 가지 주요 예외를 처리하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!