캐싱 기술을 사용하면 데이터베이스에 대한 부담을 줄이고 액세스 효율성을 높일 수 있습니다. 현재 캐싱은 기업 프로젝트에서 점점 더 많은 관심을 받고 있습니다. 그러나 캐싱은 단지 프로젝트를 아무렇게나 추가하는 것을 의미하지 않습니다. 캐싱을 프로젝트에 통합하는 것이 첫 번째 단계입니다. 캐시로 인한 침투 문제와 그에 따른 스노우 바운스 문제는 모두 우리가 시급히 해결해야 할 문제입니다. 이 기사에서는 참고용으로 제가 일상 프로젝트에서 사용하는 솔루션을 공유하겠습니다.
캐시의 일반적인 사용은 그림과 같습니다.
그림과 같이 캐시 사용 프로세스는 다음과 같습니다.
1 먼저 캐시에서 데이터를 가져옵니다. .얻을 수 있는 경우에는 사용자에게 직접 데이터를 반환합니다. 이렇게 하면 데이터베이스에 액세스할 필요가 없어지고 데이터베이스에 대한 부담이 줄어듭니다.
2. 캐시에 데이터가 없으면 데이터베이스에 액세스합니다.
그림과 같이 여기에 BUG가 있습니다.
그림과 같이 캐시는 데이터베이스의 방화벽과 같아서 자주 요청하는 데이터를 캐시에 배치하여 데이터베이스에 대한 부담을 줄입니다. 데이터 베이스. 그러나 누군가 악의적으로 공격하면 쉽게 캐시에 침투하여 데이터베이스에 모든 압력을 가할 수 있습니다. 예를 들어 위 그림에서 캐시의 키는 모두 양수이지만 캐시에 액세스하기 위해 음수를 키로 사용합니다. 이렇게 하면 캐시가 침투하여 데이터베이스에 직접 압력을 가하게 됩니다.
캐시 침투 문제는 동시성이 아무리 커도 문제가 됩니다. 이러한 전제를 바탕으로 캐시 침투 원인을 다음과 같이 분석합니다.
1. 악의적인 공격, 키 명명 방법을 추측한 후 캐시에 없는 키를 사용하여 액세스할 것으로 추정합니다.
2. 첫 번째 데이터 액세스의 경우 현재 캐시에 데이터가 없으므로 동시 시나리오에서는 모든 요청이 데이터베이스로 푸시됩니다.
3. 데이터베이스의 데이터도 비어 있어서 데이터베이스에 접근하더라도 데이터를 얻을 수 없으므로 캐시에 해당 데이터가 없어야 합니다. 이는 또한 침투로 이어질 수 있습니다.
캐시 침투는 그림과 같이 침투 이유를 단계별로 피하는 것입니다.
위 그림과 같이 해결 단계는 다음과 같습니다.
1. 웹 서버를 다시 시작합니다. 이때, 동시에 자주 접근할 수 있는 데이터는 미리 캐시에 기록됩니다. —이렇게 하면 3단계에서 많은 수의 요청이 대기하고 차단되는 것을 방지할 수 있습니다.
2. 키 이름 지정을 표준화하고 캐시 쿼리를 통합하고 항목을 작성합니다. 이런 식으로 입구에서 열쇠의 사양을 감지합니다. – 이런 방식으로 악성 키가 저장되고 차단됩니다.
3. 이때 동기화 메커니즘을 사용하여 동기화 코드 블록 이전에 캐시에 해당 키가 있는지 확인한 다음 동기화 코드 블록에서 다시 확인해야 합니다. 캐시 키의 모든 쿼리. 이 "이중 감지"의 목적은 동시 시나리오로 인해 발생하는 의미 없는 데이터베이스 액세스를 방지하는 것입니다(침투를 엄격하게 방지하는 솔루션이기도 함).
이 단계에서는 큐가 발생하지만 첫 번째 단계에서 말했듯이 많은 큐를 피하기 위해 예측 가능한 많은 수의 요청을 미리 캐시에 쓸 수 있습니다.
4. 데이터베이스에 데이터가 있는지 여부에 관계없이 해당 키는 캐시에 저장되며 값은 비어 있습니다. – 이는 데이터베이스에 해당 데이터가 없기 때문에 데이터베이스에 대한 일반적인 캐시 관통 액세스를 방지하기 위한 것입니다.
5. 4단계에서 null 값이 너무 많으면 메모리 소모가 발생합니다. 불필요한 메모리 소비를 유발합니다. 이런 방식으로 값이 비어 있는 키를 정기적으로 정리해야 합니다. 메모리가 악의적으로 점유되는 것을 방지합니다. 결과적으로 일반 함수는 데이터를 캐시할 수 없습니다.
더 많은 Redis 관련 기술 기사를 보려면 Redis 튜토리얼#🎜🎜을 방문하세요. # 학습 칼럼!
위 내용은 Redis 캐시 침투를 해결하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!