Redis로 인한 눈사태를 해결하는 방법

눈사태의 원인:

캐시 눈사태에 대한 간단한 이해는 원래 캐시 오류로 인해(또는 데이터가 캐시에 로드되지 않음) 새 캐시가 도착하지 않은 경우(캐시는 정상적으로 획득됨)입니다. 아래 표시된 대로 Redis에서) 원래 캐시에 액세스해야 하는 모든 요청은 데이터베이스 쿼리로 이동하며, 이는 데이터베이스 CPU 및 메모리에 큰 부담을 가하며 심각한 경우 데이터베이스 가동 중지 및 시스템 충돌을 일으킬 수 있습니다.

기본 해결 방법은 다음과 같습니다.

첫째, 대부분의 시스템 설계자는 너무 많은 손상을 피하기 위해 한 번에 데이터베이스를 읽고 쓰는 스레드 수가 많지 않도록 잠금 또는 대기열 사용을 고려합니다. 캐시가 실패하면 데이터베이스에 대한 부담이 어느 정도 완화될 수 있지만 시스템 처리량도 감소합니다.

둘째, 사용자 행동을 분석하고 캐시 무효화 시간을 균등하게 분배하도록 노력하세요.

셋째, 특정 캐시 서버가 다운된 경우 redis 기본 및 백업과 같은 기본 및 백업을 고려할 수 있습니다. 그러나 이중 캐싱에는 업데이트 트랜잭션이 포함되며 업데이트는 해결해야 할 더티 데이터를 읽을 수 있습니다.

Redis 눈사태 효과에 대한 솔루션:

1. 독립형 버전의 경우 로컬 잠금을 사용할 수 있습니다.

2. 메시지 미들웨어 방법

3. Redis+Ehchache

4 . 할당된 Redis 키의 공유 만료 시간

설명:

1. 데이터베이스 서버에 갑자기 많은 요청이 있을 경우 요청을 제한합니다. 위의 메커니즘을 사용하면 하나의 스레드(요청)만 작동하는 것이 보장됩니다. 그렇지 않으면 대기열에 넣고 대기합니다(클러스터 분산 잠금, 독립형 로컬 잠금). 서버 처리량을 줄이고 효율성을 낮춥니다.

자물쇠에 추가하세요!

단 하나의 스레드만 입력할 수 있음을 보장합니다. 실제로 하나의 요청만 쿼리 작업을 수행할 수 있습니다.

여기서 현재 제한 전략을 사용할 수도 있습니다~

2. 메시지 미들웨어를 사용하여 이 문제를 해결하세요. 플랜이 가장 믿을 수 있는 플랜입니다!

메시지 미들웨어는 높은 동시성을 해결할 수 있습니다! ! !

많은 요청에 접근할 때 Redis에 값이 없으면 쿼리 결과는 메시지 미들웨어에 저장됩니다(MQ 비동기 동기화 기능 사용).

3. 2차 캐시인 A1을 수행합니다. A2는 원본 캐시이고, A2는 복사 캐시입니다. A1이 만료되면 A2에 액세스할 수 있습니다. A1의 캐시 만료 시간은 단기로 설정되고, A2는 장기로 설정됩니다(이 점은 보충입니다)

4 . 다른 키, 다른 만료 시간을 설정하여 캐시를 무효화해야 합니다.

더 많은 Redis 관련 지식을 알고 싶으시면

Redis 사용법 튜토리얼

칼럼을 방문해 주세요!

위 내용은 Redis로 인한 눈사태를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!