Redis의 캐시 사태, 캐시 분석 및 캐시 침투에 대해 이야기해 보겠습니다.
- 青灯夜游앞으로
- 2021-07-02 11:11:552285검색
이전 기사에서는 Redis에 대한 몇 가지 기본 지식에 대해 주로 이야기했습니다. 실제 전투나 실제로 겪은 문제는 모두에게 지루할 것입니다. 오늘은 실제 전투에 대해 이야기하겠습니다.
- 캐시 눈사태
- 캐시 분석
- 캐시 침투
이 세 가지 문제가 인터넷상의 많은 파트너들에 의해 논의되었다고 생각합니다. 제가 느낀 점은 이 세 가지 질문이 면접에서도 자주 나오는데, 이 질문을 명확하게 설명하려면 기술이 필요하다는 것입니다. [관련 추천: Redis 영상 튜토리얼]
이 세 가지 질문에 대해 이야기할 때 먼저 일반적인 요청 프로세스에 대해 이야기해 보겠습니다. 그림을 보고 이야기해 보세요.
위 그림의 의미는 대략 다음과 같습니다.
먼저 코드에서 tomcat이나 rpc 서비스일 수 있으며 먼저 원하는 데이터가 캐시에 있는지 확인하고 저장된 경우 호출 측으로 직접 반환됩니다. 존재하지 않는 경우에는 데이터베이스를 쿼리해야 합니다. 결과를 쿼리한 후 캐시에 계속 캐시한 다음 호출자에게 결과를 반환하면 캐시가 적중됩니다.
Cache avalanche
Definition
제가 기억하는 건 제가 추천 시스템 작업을 할 때 일부 데이터는 이 제품을 본 후 유사한 제품을 추천하라는 요청이었습니다. hbase와 redis에 동시에 저장되므로 일괄 알고리즘으로 생성되므로 redis에 저장할 때 만료 시간을 동일하게 설정하면 많은 수의 키가 동시에 무효화되므로 많은 수의 키가 필요합니다. 데이터베이스의 처리량이 제한되어 있기 때문에 요청이 백그라운드 데이터베이스로 전송됩니다. 이 상황은 캐시 사태입니다.
만료 시간 설정에 주의해야 합니다.
눈사태를 예방하는 방법
실제로는 매우 간단합니다. 캐시 시간을 일괄 설정할 때 설정된 캐시 시간에 대해 임의의 숫자를 설정합니다(예를 들어 임의의 숫자는 10분 이내의 숫자, 임의의 숫자일 수 있습니다). 숫자 생성은 Java의 Random)을 사용하여 생성할 수 있으므로 많은 수의 키가 동시에 나타나지 않고 집합적으로 실패할 수 있습니다. 그림을 보고 이야기해 보세요.
눈사태가 실제로 발생하면 어떻게 해야 할까요? ?
트래픽이 그리 크지 않아 데이터베이스가 이를 견딜 수 있습니다. 탈출을 축하합니다. 데이터베이스가 처리할 수 있는 요청 수 한도를 초과하여 트래픽이 매우 많습니다. 데이터베이스가 다운되었습니다. P0 사고 티켓을 받으신 것을 축하합니다. 트래픽이 매우 큽니다. 데이터베이스에 전류 제한 체계가 있는 경우 전류 제한 매개변수에 도달하면 요청이 거부되어 백그라운드 DB가 보호됩니다. 다음은 전류 제한에 대한 몇 가지 단어입니다. 초당 요청 수를 설정하여 DB 끝에 도달하는 많은 요청 수를 제한할 수 있습니다. 여기서 초당 요청 수 또는 동시성 수는 현재의 초당 요청 수가 아닙니다. 특정 키를 쿼리하도록 설정할 수 있습니다. 이는 동일한 키를 가진 많은 요청이 백엔드 데이터베이스에 도달하는 것을 방지하여 대부분의 요청이 발생하도록 하는 것입니다. 차단할 수 있습니다. 사진을 보고 대화하세요.
캐시 분석
Definition
예를 들어 웹 사이트에서 Double Eleven을 진행하거나 반짝 세일 및 기타 운영 활동을 수행하는 경우 일반적으로 이때 웹 사이트 트래픽이 매우 클 것이며 특정 제품은 프로모션으로 인해 승격됩니다. 핫한 제품이 되어 트래픽이 엄청나게 커지게 됩니다. 만약 이 제품이 어떤 이유에서인지 이때 캐시에 장애가 발생하면 이 키의 트래픽이 순식간에 데이터베이스로 흘러가게 됩니다. , 그리고 db는 결국 생존할 수 없게 됩니다. 다운되면 일반적으로 다른 데이터를 쿼리할 수 없습니다. 사진을 보고 대화하세요.
해결 방법
사실 최종 분석에서는 더 이상 DB에 도달하는 트래픽을 허용하지 않는 것만으로도 충분하므로 DB에 도달하는 트래픽을 제한하면 됩니다.
1. 전류 제한
은 위에서 언급한 것과 유사합니다. 주로 특정 키의 트래픽을 제한하며, 이 키가 침투되면 하나의 트래픽만 db에 진입하도록 제한되고 나머지는 거부됩니다. 재작업을 기다려 보세요. Redis를 쿼리해 보세요.
전류 제한 다이어그램은 캐시 항복 전류 제한 다이어그램을 참조하세요.
이것도 로컬 전류 제한과 분산 전류 제한으로 구분됩니다.
로컬 트래픽 제한이란 무엇입니까? 단일 로컬 인스턴스 범위 내에서 이 키의 트래픽을 제한한다는 의미입니다.
분산 전류 제한이란 무엇입니까? 이는 분산 환경에서 여러 인스턴스 범위 내에서 이 키의 누적 트래픽 제한이 한도에 도달하면 모든 인스턴스에서 트래픽을 제한한다는 의미입니다. DB.
2. 분산 잠금 사용
다음은 분산 잠금의 정의에 대한 간략한 소개입니다. 잠금은 분산 시나리오에서도 마찬가지로 공유 리소스에 대한 상호 배타적 액세스를 제공하는 데 사용해야 합니다. 또한 다중 노드 공유 리소스에 대한 상호 배타적 액세스를 보장하는 메커니즘이 필요하며 구현 메커니즘은 분산 잠금입니다.
여기서 공유 리소스는 예시에서 huawei pro입니다. 즉, db에서 huawei pro에 액세스할 때 분산 잠금 효과를 얻으려면 하나의 스레드 또는 하나의 흐름만 액세스해야 합니다.
사진을 보고 이야기하세요.
자물쇠를 잡으러 가세요:
많은 요청이 화웨이 프로 키의 가치를 얻지 못한 후에는 DB로 가서 자물쇠를 얻을 준비가 되었습니다. 이때 db를 얻기 위한 코드는 분산 잠금을 추가한 다음 각 요청과 각 스레드가 Huawei Pro의 분산 잠금을 획득하게 됩니다. (분산 잠금은 그림에서 redis를 사용하여 구현됩니다. 나중에 별도의 기사를 작성하겠습니다. Redis에 국한되지 않는 분산 잠금 구현을 도입합니다.
잠금 획득 후:
이때 스레드 A는 huawei pro의 분산 잠금을 획득하고 스레드 A는 DB로 이동하여 데이터를 로드한 다음 스레드 A는 huawei pro를 다시 캐시에 설정합니다. 그런 다음 데이터를 반환합니다.
다른 스레드에서는 이를 얻지 못했습니다. 한 가지 방법은 클라이언트에 직접 null 값을 반환하는 것이고, 또 다른 방법은 db를 쿼리하고 이를 redis에 넣는 것이 매우 빠르기 때문에 50-100ms를 기다리는 것입니다. 시간이 지나면 다시 쿼리할 때 결과를 사용할 수 있습니다. 그렇지 않으면 null이 직접 반환됩니다. 물론, 대규모 동시성 시나리오에서도 결과를 신속하고 반환할 수 있기를 원합니다. 너무 많은 재시도를 피하세요.
3. 예약된 작업은 핫스팟 키를 업데이트합니다
쉽게 말하면 특정 핫스팟 키의 시간 초과를 정기적으로 모니터링하여 만료되었는지 확인한 후 업데이트를 수행하는 예약된 작업입니다. 만료될 예정인 경우 캐시에 있는 키의 캐시 시간을 연장하세요.
단일 스레드 폴링을 사용하여 만료 시간을 확인하고 업데이트합니다. 그림을 참조하세요.
멀티 스레딩 방법, 핫스팟 키가 너무 많아서는 안 된다는 점에 유의하세요. 핫스팟 키가 너무 많으면 특정 스레드가 많이 열리게 됩니다. 핫스팟 키가 많습니다. 스레드 풀 방법을 사용할 수 있습니다. 그림을 참조하세요.
지연 대기열 구현
위 방법은 단일 스레드이든 다중 스레드이든 솔직하게 말하면 폴링은 키가 곧 만료되는지 확인하는 데 사용됩니다. 이 확인 방법은 부정확한 확인 시간을 발생시켜 다음 확인을 기다리는 동안 시간이 지연되거나 부정확해질 수 있습니다. , 이때 이미 고장이 발생했습니다. 이러한 상황은 발생하지만 실제로 이를 방지하려면 지연 대기열(링 대기열)을 사용해야 합니다. 여기서는 이 대기열에 대해 자세히 설명하지 않습니다. 원칙적으로 Baidu 또는 Google), 소위 지연 대기열은 사용자가 설정한 시간에 따라 소비하기를 희망하면서 이 대기열에 메시지를 보내는 것입니다. 시간이 다 되기 전에 완료하고, 시간이 다 되면 소비가 완료됩니다. 알겠습니다. 사진을 보면서 이야기해 보세요.
1. 프로그램을 처음 시작하면 만료 시간이 설정됩니다. 목록에 있는 키 중 하나를 얻습니다.
2. 키 지연 소비 시간을 순차적으로 설정하세요. 소비 시간은 만료 시간보다 빠릅니다.
3. 대기열 만료를 지연하면 소비자가 키를 소비합니다.
4. 소비자는 메시지를 소비하고 캐시 키의 만료 시간을 지연시킵니다.
5. 새 키 만료 시간을 다시 지연 대기열로 보내고 지연된 캐시의 다음 만료 시간을 기다립니다.
4. 키 설정은 만료되지 않습니다
실제로 메모리 부족으로 인해 키가 제거될 수 있는 상황을 생각해 볼 수 있습니다.
캐시 침투
Definition
소위 침투란 캐시나 데이터베이스에 존재하지 않는 키에 접근하는 것인데, 이때 DB에 직접 도달하는 트래픽과 동일하며, 그러면 일부 사기꾼이 이 취약점을 이용하여 인터페이스를 미친 듯이 플래시하여 DB를 파괴할 수 있으며, 그러면 귀하의 비즈니스는 더 이상 정상적으로 운영될 수 없게 됩니다.
어떻게 해결하나요?
1. null 또는 특수 값 설정
만료 없이 Redis에 null 또는 특정 값을 설정할 수 있습니다. 그러면 다음에 돌아올 때 Redis에서 직접 null 또는 특수 값을 얻을 수 있습니다.
이 솔루션은 근본적인 문제를 해결할 수 없습니다. 이 트래픽으로 인해 쓸모없는 키가 많이 위조될 수 있다면 아무리 많은 null이나 특수 값을 설정해도 쓸모가 없습니다. 그러면 어떻게 해결해야 할까요?
2. 블룸 필터
블룸 필터는 영어로 Bloomfiler라고 합니다. 여기서는 지면 관계로 간단히 소개하겠습니다.
예를 들어 데이터베이스에 수천만 개의 SKU 데이터가 저장되어 있는 경우 현재 요구 사항은 라이브러리에 이 SKU가 있으면 Redis를 쿼리하고 Redis를 쿼리한 다음 Redis를 업데이트하는 것입니다. 이는 SKU 데이터를 해시맵에 넣는 것이며 키는 sku입니다. SKU가 많기 때문에 이 해시맵이 차지하는 메모리 공간이 매우 커지고 결국 메모리가 터질 수 있습니다. 따라서 메모리를 절약하는 방법은 비트 배열을 사용하여 SKU가 존재하는지 여부를 저장할 수 있으며, 0은 존재하지 않음을 의미하고 해시 함수를 사용하여 해시를 계산할 수 있습니다. sku의 값을 구한 후, 비트 배열에서 sku의 해시 값을 추출하고, 모듈로 배열의 위치를 찾아 1로 설정합니다. 요청이 오면 해당 배열 위치가 해당하는지 계산합니다. sku 해시 값은 1입니다. 1이면 존재함을 의미하고, 0이면 존재하지 않음을 의미합니다. 이런 간단한 블룸필터가 구현되는데, Bloomfiler에는 오류율이 있습니다. 정확성을 제공하기 위해 배열 길이와 해시 함수 수를 늘리는 것을 고려해 볼 수 있습니다. 특히 Baidu나 Google을 사용할 수 있습니다. 오늘은 이에 대해 이야기하지 않겠습니다.
캐시 침투를 방지하기 위해 Bloomfiler를 사용하는 과정을 살펴보겠습니다. 그림을 살펴보겠습니다.
bloomfiler의 초기화는 예약된 작업을 통해 db를 읽고 비트 배열의 크기를 초기화할 수 있습니다. 가 0이면 존재하지 않는다는 뜻이고, 각 항목의 해시 값에 해당하는 배열 위치를 계산하여 비트 배열에 삽입합니다.
요청 프로세스, 그림 참조:
bloomfiler 필터를 사용하지 않으면 데이터베이스에 존재하지 않는 키에 대해 실제로 두 개의 IO를 낭비하게 되며 하나는 Redis를 쿼리하는 데 사용됩니다. 하나는 DB를 쿼리하기 위한 것입니다. Bloomfiler가 없으면 이 두 개의 쓸모없는 IO가 저장되고 백엔드 Redis 및 DB 리소스의 낭비가 줄어듭니다.
Summary
오늘은 Redis Cache의 고빈도 인터뷰와 실제 전투에서 겪게 되는 문제점과 해결 방안에 대해 이야기를 나눴습니다.
캐시 눈사태
해결책:
만료 기간을 설정할 때 임의의 시간을 추가하세요. 몇 분 이내일 수 있습니다.
눈사태가 발생하면 어떻게 해야 하는지에 대한 질문뿐만 아니라 전류 제한을 사용할 수도 있습니다.
캐시 분석
해결책:
현재 제한
분산 잠금
여기에서는 핫스팟 키를 정기적으로 업데이트합니다.
만료 없이 시간 설정
캐시 침투
해결책:
redis에 null 또는 특정 값을 설정
bloomfiler를 사용하여
더 많은 프로그래밍 관련 지식을 보려면 다음 사이트를 방문하세요. : 프로그래밍 입문! !
위 내용은 Redis의 캐시 사태, 캐시 분석 및 캐시 침투에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!