이 글은 Redis의 캐시 침투, 캐시 눈사태, 캐시 고장 및 캐시 일관성에 대해 간략하게 설명하고, 캐시 침투 및 캐시 눈사태에 대한 솔루션을 소개합니다. 모두에게 도움이 되기를 바랍니다!
캐시가 넓은 영역에서 동시에 실패하고 후속 요청이 데이터베이스에 떨어지게 되어 데이터베이스가 짧은 시간에 많은 수의 요청을 견딜 수 없게 되고 Collapse
예를 들어 전자상거래 홈페이지의 경우 모든 홈페이지의 키 만료 시간은 모두 12시간이며, 낮 12시에 새로고침되어 0시에 플래시 세일 이벤트가 있어서 많은 사용자가 몰리게 됩니다. , 그러나 캐시에 있는 모든 키가 유효하지 않으면 모든 요청이 데이터베이스로 전달됩니다. 데이터베이스가 이를 처리할 수 없으면 직접 차단됩니다. 또는 redis가 다운되면 많은 요청이 mysql로 전달됩니다. 전화를 끊게 만듭니다. [관련 권장 사항: Redis 동영상 튜토리얼]
따라서 이 경우 동시에 많은 키 실패를 방지하려면 각 키의 만료 시간에 임의의 값을 추가해야 합니다. Redis 클러스터 배포이므로 핫스팟 데이터를 다른 라이브러리에 배포할 수 있습니다.
사전: Redis 클러스터의 고가용성을 보장하고, 가능한 한 빨리 시스템 가동 중지 시간을 보충하고, 적절한 메모리 제거 전략을 선택하세요.
진행 중: 로컬 ehcache 캐시 + hystrix 전류 제한 및 다운그레이드 mysql 충돌을 방지하려면
후: Redis 지속성 메커니즘에 의해 저장된 데이터는 가능한 한 빨리 캐시에 복원됩니다.
요청된 키가 캐시에 많이 존재하지 않습니다. 예를 들어 해커가 캐시에 존재하지 않는 키를 생성하고 대량의 요청을 시작하여 대량의 요청이 발생합니다. 데이터베이스에 빠지게 됩니다.
먼저 기본 입력 매개변수 확인을 수행하고 잘못된 매개변수를 직접 차단해야 합니다. 예를 들어 데이터베이스 ID가 0보다 작을 수 없도록 쿼리하고 이메일 형식을 확인하는 등
둘 다인 경우. 캐시와 데이터베이스는 특정 키의 데이터를 찾을 수 없으면 해당 키를 redis에 기록하고 값은 null이며 만료 시간은 다음 요청이 데이터베이스에 떨어지는 것을 방지하도록 설정됩니다.
Bloom 필터를 통해 Bloom 필터는 주어진 데이터가 대용량 데이터에 존재하는지 매우 편리하게 판단할 수 있습니다. 가능한 모든 요청 값은 Bloom 필터에 저장될 수 있으며, 요청이 오면 먼저 요청이 전송되었는지 여부를 확인합니다. Bloom 필터에는 사용자가 존재하며 존재하지 않는 경우에는 직접 차단합니다.
캐시 분해는 지속적으로 대규모 동시성을 전달하는 키 핫스팟을 의미합니다. 대규모 동시성은 키가 실패하면 캐시를 뚫고 직접 요청합니다. 데이터베이스
강한 일관성이 필요한 경우 캐시를 사용할 수 없습니다. 강력한 일관성은 보장할 수 없고 최종 일관성만 보장할 수 있기 때문입니다.
데이터베이스 업데이트가 실패하면 데이터베이스에 여전히 오래된 데이터가 있고 redis는 비어 있으며 데이터가 비어 있으면 일관성이 없습니다. 쿼리를 위해 데이터베이스로 이동한 다음 캐시로 업데이트합니다.
캐시를 먼저 삭제한 다음 데이터베이스를 업데이트하세요. 캐시를 삭제했지만 이때 데이터베이스를 업데이트하지 않는 등 동시성이 높은 시나리오에서도 문제가 발생할 수 있습니다. redis가 비어 있으면 데이터베이스를 읽어 redis로 업데이트합니다. 이때 캐시된 스레드가 삭제된 후 데이터베이스가 업데이트되면 데이터베이스와 redis 데이터가 일치하지 않게 됩니다. 데이터 업데이트 작업을 대기열에 넣고 직렬화할 수 있습니다. 작업은 발생하지 않지만 효율성이 떨어지기 때문에 일반적으로 권장되지 않습니다.
더 많은 프로그래밍 관련 지식을 보려면 프로그래밍 소개를 방문하세요! !
위 내용은 Redis의 캐시 침투, 캐시 사태, 캐시 분석 및 캐시 일관성에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
