Cache Avalanche는 Redis의 많은 캐시가 동시에 실패함을 의미합니다. 이 기간 동안 동시에 많은 수의 요청이 시작되면 요청이 데이터베이스에 직접 액세스하게 됩니다. 데이터베이스를 압도할 수 있습니다.
Cache Avalanche는 일반적으로 캐시에는 없지만 데이터베이스에 있는 데이터를 말하며, 시간 만료로 인해 요청이 데이터베이스로 직접 이동합니다.
캐시 사태를 해결하는 방법에는 여러 가지가 있습니다.
1. 캐시에 대한 단일 스레드 액세스를 보장하기 위해 잠금을 설정합니다. 이렇게 하면 동시에 데이터베이스에 액세스하는 요청이 많지 않습니다.
2. 만료 시간을 동일하게 설정하지 마세요. 일반적인 예는 워밍업 데이터를 초기화할 때 캐시에 데이터를 저장할 때 많은 수의 캐시가 동시에 만료되지 않도록 임의의 시간을 사용할 수 있습니다.
3. 메모리가 허용하는 경우 캐시가 만료되지 않도록 설정할 수 있습니다.
캐시 고장은 캐시 눈사태와 매우 유사합니다. 차이점은 캐시 고장은 일반적으로 단일 캐시 오류를 의미하며 동시에 이 키에 액세스해야 하는 대규모 동시 요청이 있기 때문에 발생합니다. 데이터베이스 압박.
캐시 고장을 해결하는 방법은 캐시 사태를 해결하는 방법과 매우 유사합니다.
1. 캐시에 대한 단일 스레드 액세스를 보장하기 위한 잠금입니다. 이러한 방식으로 첫 번째 요청이 데이터베이스에 도달한 후 캐시가 다시 작성되고 후속 요청이 캐시를 직접 읽을 수 있습니다.
2. 메모리가 허용하는 경우 캐시가 만료되지 않도록 설정할 수 있습니다.
캐시 침투와 위 두 현상의 본질적인 차이점은 이때 접근한 데이터는 데이터베이스에 존재하지 않으므로 데이터베이스가 존재하지 않기 때문에 캐시에도 절대 존재하지 않는다는 점입니다. , 따라서 동시성이 너무 크면 데이터가 데이터베이스에 지속적으로 도착하여 데이터베이스에 큰 부담을 줍니다.
캐시 침투 문제의 경우 키 자체가 존재하지 않기 때문에 잠금을 하면 좋은 효과가 없으므로 스레드 액세스 횟수를 제어하더라도 계속해서 데이터베이스에 요청이 도착하게 됩니다.
캐시 침투 문제를 해결하려면 일반적으로 다음 솔루션을 함께 사용할 수 있습니다.
1. 인터페이스 계층은 검증을 수행하고 발견된 경우 불법 키를 직접 반환합니다. 예를 들어 데이터베이스가 자동 증가 ID를 사용하는 경우 정수가 아닌 ID 또는 음수 ID가 오면 직접 반환할 수 있습니다. 또는 32비트 UUID를 사용하는 경우 ID 길이가 다음과 같으면 직접 반환할 수 있습니다. 32비트와 같지 않습니다.
2. 존재하지 않는 데이터를 캐시하거나 비어 있거나 기타 합의된 유효하지 않은 값을 직접 캐시할 수 있습니다. 이 솔루션을 사용하면 키의 만료 시간을 짧게 설정하는 것이 가장 좋습니다. 그렇지 않으면 존재하지 않는 많은 키가 Redis에 저장되어 많은 메모리를 차지하게 됩니다.
위의 캐시 침투 솔루션과 관련하여 생각해 보겠습니다. 키가 첫 번째 방법의 검증을 우회할 수 있고 현재 액세스된 존재하지 않는 키가 많이 있는 경우(예: 1억 또는 10억), 그러면 이때 모두 캐시에 저장되기 때문에 매우 큰 공간을 차지하게 되고 서버 메모리도 많이 낭비하게 되어 메모리가 부족하게 됩니다.
그렇다면 더 나은 해결책이 있을까요? 다음에 소개해드릴 Bloom 필터는 키 값이 너무 많은 문제를 최대한 해결할 수 있는 기능입니다.
대부분의 사람들은 다음과 같은 인터뷰 질문이 있다는 것을 알고 있을 것입니다. 10억 개의 무질서한 방대한 데이터에 요소가 존재하는지 신속하게 확인하는 방법은 무엇입니까?
이 문제를 해결하려면 Bloom 필터를 사용해야 합니다. 그렇지 않으면 대부분의 서버 메모리가 이렇게 많은 양의 데이터를 저장할 수 없습니다.
블룸 필터는 1970년 Bloom이 제안한 것입니다. 실제로는 긴 이진 벡터(비트맵)와 일련의 무작위 매핑 함수(해시 함수)입니다.
블룸 필터를 사용하면 요소가 세트에 있는지 검색할 수 있습니다. 장점은 일반 알고리즘에 비해 공간 효율성과 쿼리 시간이 훨씬 좋다는 점이다. 단점은 일정 수준의 오인식률이 있고 삭제가 어렵다는 점이다.
Redis의 데이터 구조 중 하나는 비트맵입니다. Bloom 필터의 중요한 구현은 비트 배열인 비트맵의 구현이며, 이 배열의 각 위치에는 0과 1만 있습니다. 상태에서는 각 위치가 1바이트만 차지합니다. 여기서 0은 요소가 없음을 의미하고 1은 요소가 있음을 의미합니다. 아래 그림과 같이 간단한 Bloom 필터 예입니다(해싱 및 비트 연산 후에 키 값이 있어야 하는 위치에서 키 값을 찾을 수 있음).
위에서는 Lonely와 Wolf가 같은 위치에 있다는 것을 발견했습니다. 해싱 후 서로 다른 키 값이 같은 값을 얻는 현상을 해시 충돌이라고 합니다. 해시 충돌이 발생한 후 비트 연산이 수행되면 반드시 같은 위치에 있게 됩니다.
해시 충돌이 너무 많이 발생하면 판단의 정확성에 영향을 미칩니다. 따라서 해시 충돌을 줄이기 위해 일반적으로 다음 두 가지 요소를 고려합니다.
1 비트맵 배열의 크기를 늘립니다. 비트맵 배열이 클수록 차지하는 메모리도 커집니다.
2. 해시 함수 수를 늘립니다. (하나의 함수 후에 동일한 키 값이 같으면 두 개 이상의 해시 함수를 계산한 후 동일한 결과를 얻을 확률은 자연스럽게 감소합니다.)
위의 두 가지 방법을 종합적으로 고려해야 합니다. 예를 들어 비트 배열을 늘리면 더 많은 공간을 소비하고 더 많은 해시 계산도 CPU를 소비하여 최종 계산 시간에 영향을 미치므로 비트 배열이 얼마나 큰지 , 해시 함수를 계산해야 하는 횟수 및 적절한 횟수는 특정 상황에 대한 구체적인 분석이 필요합니다.
다음은 해시 함수를 두 번 전달하여 얻은 Bloom 필터입니다. 아래 그림에 따르면 우리 Redis가 전혀 존재하지 않지만 Redis가 두 가지를 통과하는 경우를 쉽게 알 수 있습니다. 두 개의 해시 함수 이후에 얻은 위치는 이미 1입니다(하나는 Wolf가 f2를 통해 얻었고, 다른 하나는 Nosql이 f1을 통해 얻었습니다).
위의 현상을 통해 블룸 필터의 관점에서 블룸 필터는 주로 두 가지 주요 특성을 갖는다는 결론을 내릴 수 있습니다.
1 블룸 필터가 요소가 존재한다고 판단하면 이 요소는 다음과 같습니다. 현재의.
2. Bloom 필터에서 요소가 존재하지 않는다고 판단하는 경우 이 요소는 존재하지 않아야 합니다.
요소의 관점에서 보면 다음과 같은 두 가지 주요 특징을 그릴 수 있습니다.
1. 요소가 실제로 존재한다면 블룸 필터가 그 존재를 확실히 결정합니다.
2. 요소가 존재하지 않으면 Bloom 필터가 요소가 존재한다고 판단할 수 있습니다.
PS: 해시 함수가 N번 전달되면 N 위치가 1이어야 존재 여부를 확인할 수 있습니다. 하나가 0인 한 요소가 존재하지 않는 것으로 판단할 수 있습니다. 블룸 필터 중간.
블룸 필터에는 항상 거짓양성률이 있기 때문에 해시 충돌을 100% 피할 수는 없기 때문입니다. 블룸 필터는 이를 거짓양성 확률, 즉 거짓양성 확률(False Positive Probability), 줄여서 fpp라고 부릅니다.
실제로 Bloom 필터를 사용할 때 fpp를 직접 정의한 다음 Bloom 필터 이론을 기반으로 필요한 해시 함수 수와 비트 배열 공간의 크기를 계산할 수 있습니다. 해시 충돌이 발생하지 않는다는 보장이 100% 없기 때문에 이 fpp를 100%로 정의할 수 없다는 점에 유의해야 합니다.
위 내용은 Java 캐시 및 솔루션의 눈사태 및 침투 문제의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
