Redis 캐시 고장이 발생한 경우 수행할 작업

분산 캐싱은 읽기가 많고 쓰기가 적은 비즈니스 시나리오에서 자주 사용되는 기술입니다. 방문, 백엔드 데이터베이스 및 기타 데이터 소스가 잘 보호됩니다. 현재 시장에는 Redis, Memcached 및 Alibaba의 Tair와 같은 많은 분산 캐시가 있습니다. 어떤 캐시 제품을 사용하든 기본적으로 캐시 고장, 캐시 무효화 및 단축키 문제가 발생합니다. 이러한 문제를 어떻게 효과적으로 방지하는가 역시 캐싱이 가져다주는 배당금을 즐기면서 해결해야 할 어려운 문제입니다.

보통 우리는 캐시를 사용할 때 캐시에 캐시가 있는지 먼저 확인하고, 캐시 내용이 없으면 직접 데이터베이스에 쿼리합니다. 예를 들어 아래 그림과 같이

캐시 분석:

# 🎜🎜#Description

존재하지 않는 ID에 대해 상품 세부정보 등 기존 데이터를 조회할 경우 매번 해당 DB에 접근하여 악의적으로 파기하게 됩니다. DB에 과도한 부담을 직접적으로 초래할 가능성이 높습니다.

해결책:

특정 키를 통해 데이터를 쿼리할 때 데이터베이스에 해당 데이터가 존재하지 않으면 이 키에 해당하는 값을 기본값으로 설정하고, "NULL"과 같이 캐시 만료 시간을 설정하면 이 키를 통한 모든 액세스는 캐시가 만료되기 전에 캐시에 의해 차단됩니다. 나중에 이 키에 해당하는 데이터가 DB에 존재할 경우 캐시가 무효화된 후 이 키를 통해 다시 데이터에 접근하면 새로운 값을 얻을 수 있다.

캐시 무효화:

설명

고동시성 환경에서 이때 키에 해당하는 캐시가 실패하면 이때 여러 프로세스가 동시에 DB를 쿼리한 다음 동시에 캐시를 설정합니다. 이때 키가 시스템 내 핫스팟 키이거나 동시에 다수의 키가 실패할 경우 DB 접근량이 순간적으로 늘어나 과도한 부담을 안겨준다.

해결책:

동시에 많은 수의 키에 해당하는 캐시 오류를 방지하기 위해 시스템의 키 캐시 만료 시간을 균일하게 조정합니다.
캐시 방식을 재설계합니다. 사용되며, 키를 통해 데이터를 쿼리할 때 먼저 캐시를 쿼리하고, 이때 캐시를 쿼리할 수 없으면 분산 잠금을 통해 이를 잠급니다. 잠금을 획득한 프로세스는 DB를 확인하고 캐시를 설정합니다. 그런 다음 다른 프로세스에서 잠금이 있음을 발견하면 잠금을 기다린 다음 캐시된 데이터를 반환하거나 잠금이 해제된 후 DB를 다시 쿼리합니다.

핫스팟 키:

Description

캐시(아마도 애플리케이션 및 프로모션 제품용)의 특정 키에 해당하는 값은 다음과 같습니다. 하나의 머신을 중앙 집중화하면 모든 트래픽이 동일한 머신으로 흐르게 되어 시스템의 병목 현상이 발생합니다. 이 문제의 문제점은 머신 용량을 늘려도 해결할 수 없다는 것입니다.

해결책:

클라이언트 핫스팟 키 캐시: 값에 해당하는 핫스팟 키를 클라이언트에 로컬로 캐시하고 만료 시간을 설정합니다. 각 읽기 요청에 대해 먼저 키가 로컬 캐시에 있는지 확인하고, 존재하지 않으면 직접 반환됩니다. 그런 다음 분산 캐시 시스템에 액세스합니다.
핫스팟 키를 여러 하위 키에 분산시킨 다음 캐시 클러스터의 다른 컴퓨터에 저장합니다. 이러한 하위 키에 해당하는 값은 핫스팟 키와 동일합니다. 핫스팟 키를 통해 데이터를 쿼리할 때 일부 해시 알고리즘을 통해 하위 키가 무작위로 선택된 다음 캐시 머신에 액세스하여 핫스팟을 여러 하위 키에 배포합니다. 더 많은 Redis 관련 기술 기사를 보려면

Redis tutorial 열을 방문하세요!

위 내용은 Redis 캐시 고장이 발생한 경우 수행할 작업의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!