Java MQ 메시지 큐의 기본 지식 포인트는 무엇입니까?

캐싱 눈사태

먼저 일반적인 캐싱 프로세스가 어떤지 살펴보겠습니다. 아래 그림과 같이:

먼저 사용자가 이 항목에 액세스한 다음 이 누군가가 이 Redis에 액세스하는 것을 볼 수 있습니다. Redis가 액세스 데이터를 가지고 있으면 캐시에서 얻은 데이터를 직접 반환합니다. Redis 캐시가 데이터를 찾지 못하면 MySql 데이터베이스에 쿼리하고 결과가 있으면 MySql에서 검색된 데이터를 Redis 캐시에 동기화하고 쿼리 결과를 반환합니다.

이것은 간단하고 일반적인 캐싱 프로세스입니다. 그럼 이러한 일반적인 캐싱 프로세스를 기반으로 캐시 눈사태가 무엇인지 살펴보겠습니다.

먼저 예를 하나 들어보겠습니다. 더블일레븐때 동동에서 물건을 살때 홈페이지에 들어가게 되는데 더블일레븐이라 홈페이지 방문수가 엄청나더라구요. 홈페이지의 데이터는 Redis에 캐시됩니다.

홈페이지 데이터가 Redis의 100개 키에 저장되어 있고 캐시 만료 시간이 2시간으로 설정되어 있다고 가정합니다. Double Eleven 동안 2시간 이상 쇼핑하면 홈페이지 데이터의 Redis 캐시가 이 시점에 모두 만료됩니다. 순간, 모든 요청이 MySql 데이터베이스에 도달하게 됩니다. 이때 데이터베이스의 액세스 압력이 증가하여 MySql 데이터베이스가 제때 응답하지 못하고 중단됩니다. 그러다가 동게나는 매우 불만스러워서 기술담당자를 아프리카로 보냈습니다.

이 예를 통해 아래 그림을 살펴보겠습니다.

즉, 사용자가 무언가에 액세스할 때 redis의 많은 수의 키가 유효하지 않아 이 무언가가 데이터베이스에 직접 액세스하여 데이터베이스 요청이 많은 경우 이러한 현상은 cache avalanche입니다. 간단히 말해서, 이번 사태가 다가오고 있는 것처럼 많은 수의 Redis 캐시가 동시에 무효화됩니다.

그렇다면 캐시 눈사태에 대한 해결책은 무엇입니까? 아래에서 이에 대해 이야기해 보겠습니다.

• 이 캐시의 만료 시간을 설정하여 많은 수의 키가 동시에 무효화되는 것을 방지합니다. 즉, 이 캐시를 설정할 때 키의 만료 시간을 늘릴 수 있습니다 .

• 우리는 일반적으로 Redis를 클러스터에 배포합니다. 이러한 핫스팟의 키가 다른 Redis 노드에 고르게 분산되도록 이러한 핫스팟의 키를 다른 노드에 배치할 수 있습니다.

• 캐시 만료 시간을 설정하지 않아 키가 만료되지 않도록 하는 더 폭력적인 방법도 있습니다.

캐시 침투

다음으로 캐시 침투가 무엇인지 소개하겠습니다.

예를 들어보겠습니다. 어떤 노인이 웹사이트를 개발했는데, 어느 날 갑자기 해커들의 공격을 받았습니다. 그의 공격 방법은 캐시 침투 원리에 기초했습니다.

보통 데이터베이스의 기본 키는 0부터 증가하고 음수가 없다는 것은 누구나 알고 있습니다. 그래서 이 해커는 이를 이용하여 ID가 ​​0보다 작은 매개변수로 계속 요청을 보냈습니다. 이 사람은 먼저 웹사이트의 모든 데이터를 Redis Cache에 넣었는데, 해커는 ID가 0보다 작은 숫자를 사용하여 요청했습니다. Redis Cache에는 ID가 0보다 작은 이 데이터가 없었기 때문에 Redis는 이를 수행하지 못했습니다. 결과적으로 Redis가 결과를 찾을 수 없으면 데이터베이스에서 이를 확인한 다음 모든 요청이 데이터베이스에 적중되고 Redis 캐시 계층이 해당 데이터를 가로챌 수 없기 때문에 항상 데이터베이스에 적중됩니다. 조금도.

이 데이터는 Redis Cache에 직접 침투하여 데이터베이스에 직접 침투합니다. 마찬가지로 아래 그림을 살펴보겠습니다.

먼저 악의적인 사용자가 무언가에 접근하여 id=-1로 데이터를 요청합니다. 그런 다음 id=-1인 데이터를 Redis 캐시에서 찾을 수 없으므로 이동합니다. 내부 쿼리시 데이터가 발견되지 않아 빈 데이터만 프런트 엔드로 반환될 수 있었습니다.

이 악의적인 사용자(해커)는 스크립트를 사용하여 이 데이터를 지속적으로 요청하여 Redis에 직접 침투하여 이 데이터베이스에 타격을 가하는 것을 소위 캐시 침투라고 합니다. 간단히 말해서, 캐시 침투는 캐시나 데이터베이스에 그러한 데이터가 없다는 것을 의미합니다. 일반적으로 일반 사용자는 이러한 상황에 액세스하지 않습니다.

그러면 캐시 침투에 대한 솔루션은 다음과 같습니다.

• 요청이 Redis를 침투하여 데이터베이스로 직접 이동하는 경우 데이터베이스에서 어떤 결과가 발견되더라도 Redis 캐시에 다시 기록되므로 Redis 캐시에 다시 기록됩니다. 다음에 사용할 수 있다는 점입니다. 동일한 매개변수로 요청이 전송되면 Redis 캐시에 의해 직접 가로채어 데이터베이스로 다시 전송되지 않습니다.

• 요청된 매개변수의 유효성을 확인하세요.

• 더 직접적이고 간단하며 투박한 방법은 이 IP를 차단하는 것입니다.

• 마지막으로 블룸 필터를 사용하는 것이 아주 좋은 방법입니다.

캐시 고장

마지막 문제인 캐시 고장에 대해 이야기해 보겠습니다.

더블 일레븐(Double Eleven)을 예로 들어보겠습니다: 더블 일레븐(Double Eleven) 중에 당 형제는 큰 행사를 열고 싶다고 발표하고 자신이 20년 전에 사용했던 컴퓨터를 경매에 부치고 싶다고 말했습니다. 그러자 많은 사람들이 이 컴퓨터에 관심을 보였습니다. 관심이 있어서 Dong Ge는 이 컴퓨터를 Double Eleven에서 9시에 경매하기로 결정했습니다. 그런 다음 Dong의 개발 프로그래머는 컴퓨터 데이터를 Redis 캐시의 키에 해당하는 Redis 캐시에 넣었습니다.

경매가 진행되는 동안 모두가 매우 열정적이었습니다. 경매는 거의 3시간 동안 진행되었습니다. 온라인 경매는 아직 끝나지 않았지만 이 컴퓨터에 해당하는 Redis 캐시 키의 만료 시간은 3시간 30분입니다. 모두가 3시간 30분 동안 경매를 하고 있을 때 갑자기 이 컴퓨터의 캐시 키가 무효화되었습니다. 결과적으로 많은 수의 경매 요청이 Redis에서 데이터를 찾을 수 없게 되었습니다. 이때 데이터베이스에 순간적인 압력이 증가하여 시스템이 제때에 응답하지 못하고 중단됩니다.
이때 당 형제는 자신의 컴퓨터가 아직 경매에 나오지 않은 것을 보고 약간 화가 나서 프로그래머를 아프리카로 보냈습니다.

마찬가지로 다음 그림을 살펴보겠습니다.

사용자가 특정 웹사이트를 방문한 후 Redis로 가서 경매 플래시 세일 제품을 요청합니다. 캐시가 유효하지 않은 경우 Redis는 결과를 반환할 수 있습니다. 캐시 키가 쿼리되었지만 캐시된 키가 만료되면 요청이 Redis에 침투하여 데이터베이스에 직접 도달합니다.

여기서 모두가 주목해야 할 것은 이것이 특정 핫스팟의 키라는 것입니다. 이 핫스팟의 키에 계속해서 액세스하려는 사용자 요청이 많습니다. 이 핫스팟의 키가 갑자기 실패하면 모든 요청이 다음으로 전송됩니다. 이 프로세스를 캐시 분석이라고 합니다. 매우 뜨거운 지점을 관통하는 열쇠라는 것을 기억하세요.

이 캐시 분석에 대한 해결책은 다음과 같습니다.

• 이 핫스팟 키가 만료되지 않도록 합니다. 즉, 만료 시간을 설정하지 않습니다(권장하지 않음).

• 단일 애플리케이션인 경우 뮤텍스 잠금을 사용하세요(분산 잠금에 대해서는 후속 기사에서 설명합니다).

위 내용은 Java MQ 메시지 큐의 기본 지식 포인트는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!