Redis 캐시 예외가 발생하면 어떻게 해야 합니까? 어떻게 해결하나요?

Redis 캐시 예외가 발생하면 어떻게 해야 하나요? 다음 기사에서는 Redis 캐시 예외 및 해결 방법을 소개하겠습니다. 도움이 되길 바랍니다.

캐시 사태

캐시 사태는 동시에 대규모 캐시 오류를 의미합니다. 따라서 후속 요청이 데이터베이스에 떨어지게 되어 데이터베이스가 한 번에 많은 요청을 견딜 수 있게 됩니다. 짧은 시간과 붕괴. [관련 권장 사항: Redis 동영상 튜토리얼]

Solution

1. 많은 양의 데이터가 동시에 만료되는 것을 방지하려면 캐시된 데이터의 만료 시간을 무작위로 설정하세요.

2. 일반적으로 동시성 양이 특별히 크지 않은 경우 가장 일반적으로 사용되는 솔루션은 잠금 및 대기열입니다.

3. 캐시된 각 데이터에 해당 캐시 태그를 추가하고 캐시가 유효하지 않은지 기록합니다. 캐시 태그가 유효하지 않은 경우 데이터 캐시를 업데이트합니다.

캐시 침투

캐시 침투란 캐시에도 없고 데이터베이스에도 없는 데이터를 말하며, 모든 요청이 데이터베이스에 떨어지게 하여 데이터베이스가 짧은 시간 내에 많은 수의 요청을 견딜 수 있게 하고, 무너지다.

Solution

1. 사용자 인증 검증, ID 기본 검증, id<=0; 직접 가로채기 등 인터페이스 계층에 검증 추가

2. , 데이터베이스에서 검색되지 않습니다. 이때 키-값 쌍은 키-널로 기록될 수도 있습니다. 캐시 유효 시간은 30초와 같이 더 짧게 설정할 수 있습니다. (너무 길게 설정하면 사용할 수 없게 됩니다. 정상적인 상황에서). 이렇게 하면 사용자가 동일한 ID를 반복적으로 사용하여 무차별 대입 공격을 하는 것을 방지할 수 있습니다.

3. 블룸 필터를 사용하여 존재해서는 안 되는 데이터를 충분히 큰 비트맵으로 해시합니다. 기본 스토리지 시스템에 대한 쿼리 부담을 피합니다.

추가

비트맵과 블룸필터, 즉 공간 활용도가 극도로 높아졌습니다.

Bitmap: 일반적인 것은 해시 테이블입니다.

Bitmap은 각 요소에 대해 1비트의 정보만 기록할 수 있다는 것이 단점입니다. 추가 기능을 완성하려면 더 많은 것을 희생해야만 할 수 있습니다. 공간과 시간.

Bloom 필터(권장)

는 k(k>1)k(k>1) 독립적인 해시 함수를 도입하여 요소가 주어진 공간 내에서 완성되도록 하고 오판율을 판단하는 과정입니다.

일반적인 알고리즘에 비해 공간 효율성과 쿼리 시간이 훨씬 높다는 장점이 있고, 오인식률이 일정하고 삭제가 어렵다는 단점이 있습니다.

Bloom-Filter 알고리즘의 핵심 아이디어는 여러 가지 해시 함수를 사용하여 "충돌"을 해결하는 것입니다.

해시에는 충돌(충돌) 문제가 있으며, 동일한 해시를 사용하여 얻은 두 URL의 값이 동일할 수 있습니다. 충돌을 줄이기 위해 해시를 여러 개 더 도입할 수 있습니다. 해시 값 중 하나를 통해 요소가 집합에 없다고 결론을 내리면 해당 요소는 확실히 집합에 없습니다. 모든 해시 함수가 해당 요소가 집합에 있음을 알려주는 경우에만 해당 요소가 집합에 존재하는지 확인할 수 있습니다. 이것이 Bloom-Filter의 기본 아이디어입니다.

Bloom-Filter는 일반적으로 대규모 데이터 컬렉션에 요소가 존재하는지 확인하는 데 사용됩니다.

캐시 분해

캐시 분해는 캐시에는 없지만 데이터베이스에 있는 데이터를 말합니다(보통 캐시 시간이 만료된 경우). 이때는 동시 사용자 수가 많아 데이터가 나오지 않습니다. 동시에 캐시에서 읽히지만 동시에 캐시에서 데이터를 읽지 않습니다. 데이터를 검색하기 위해 데이터베이스로 이동하면 데이터베이스에 대한 압력이 순간적으로 증가하여 과도한 압력이 발생합니다. Cache Avalanche는 Cache Avalanche와 달리 동일한 데이터의 동시 쿼리를 의미합니다. Cache Avalanche는 다른 데이터가 만료되어 많은 데이터를 찾을 수 없어 데이터베이스를 검색하는 것을 의미합니다.

솔루션

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

2. 뮤텍스 잠금 추가, 뮤텍스 잠금

캐시 예열

캐시 예열은 시스템이 온라인 상태가 된 후 관련 캐시 데이터가 캐시 시스템에 직접 로드됩니다. 이런 방식으로 먼저 데이터베이스를 쿼리한 다음 사용자가 요청할 때 데이터를 캐싱하는 문제를 피할 수 있습니다! 예열된 캐시 데이터를 사용자가 직접 쿼리!

해결 방법

1. 온라인에 접속할 때 캐시 새로 고침 페이지를 직접 작성하고

2. 데이터 양이 많지 않으며 프로젝트 시작 시 자동으로 로드할 수 있습니다. 정기적으로 캐시

캐시 다운그레이드

방문 횟수가 급격하게 증가하거나, 서비스 문제(응답 시간이 느리거나 응답이 없는 등)가 발생하거나, 핵심 서비스가 아닌 서비스가 핵심 프로세스의 성능에 영향을 미치는 경우에도 여전히 필요합니다. 서비스가 손상되더라도 서비스가 계속 사용 가능한지 확인하십시오. 시스템은 일부 주요 데이터를 기반으로 자동으로 다운그레이드하거나 스위치를 구성하여 수동으로 다운그레이드할 수 있습니다.

캐시 다운그레이드의 궁극적인 목표는 손실이 발생하더라도 핵심 서비스를 사용할 수 있도록 보장하는 것입니다. 그리고 일부 서비스(장바구니에 추가, 결제 등)는 다운그레이드할 수 없습니다.

다운그레이드하기 전에 시스템이 병사를 잃고 지휘관을 유지할 수 있는지 확인하여 죽음까지 보호해야 할 것과 다운그레이드할 수 있는 것을 분류해야 합니다. 예를 들어 로그 수준을 참조할 수 있습니다. 계획 설정:

1. 일반: 예를 들어 일부 서비스는 네트워크 불안정으로 인해 시간이 초과되거나 서비스가 온라인 상태가 되어 자동으로 다운그레이드될 수 있습니다.

2. 일부 서비스는 일정 기간 내에 성공률이 변동합니다. 95~100% 사이) 자동으로 다운그레이드하거나 수동으로 다운그레이드할 수 있으며 알람이 전송될 수 있습니다.

3. 오류: 예를 들어 가용성 비율이 90%보다 낮거나 데이터베이스 연결 풀이 폭발합니다. 방문 횟수가 시스템이 감당할 수 있는 최대 한도까지 갑자기 증가합니다. 이는 상황에 따라 자동으로 다운그레이드되거나 수동으로 다운그레이드될 수 있습니다.

4. 심각한 오류: 예를 들어 특별한 사유로 인해 데이터가 잘못된 경우, 긴급 수동 다운그레이드가 필요합니다.

서비스 다운그레이드의 목적은 Redis 서비스 오류로 인해 데이터베이스에 눈사태 문제가 발생하는 것을 방지하는 것입니다. 따라서 중요하지 않은 캐시 데이터의 경우 서비스 다운그레이드 전략을 채택할 수 있습니다. 예를 들어 Redis에 문제가 있으면 데이터베이스를 쿼리하는 대신 기본값을 사용자에게 직접 반환하는 것이 일반적인 접근 방식입니다.

캐시 핫스팟 키

캐시 키(프로모션 제품 등)는 특정 시점에 만료됩니다. 현재 이 키에 대한 동시 요청이 많습니다. 일반적으로 데이터가 백엔드 DB에서 로드되어 캐시로 복원되는 경우 동시 요청이 많아지면 백엔드 DB가 즉시 과부하될 수 있습니다.

Solution

캐시 쿼리를 잠급니다. KEY가 존재하지 않으면 이를 잠근 다음 DB를 캐시로 확인한 다음 잠금을 해제합니다. 다른 프로세스는 잠금을 찾은 다음 데이터를 반환합니다. 잠금 해제 후 DB에 들어가세요.

더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 비디오를 방문하세요! !

위 내용은 Redis 캐시 예외가 발생하면 어떻게 해야 합니까? 어떻게 해결하나요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!