Redis 고장 사태의 원인과 해결 방법

1. 서문

컴퓨터의 병목 현상 중 하나가 IO라는 것은 누구나 알고 있습니다. 메모리와 디스크 속도의 불일치 문제를 해결하기 위해 캐시를 생성하여 메모리에 핫 데이터를 저장하고 언제든지 액세스할 수 있도록 합니다. 데이터베이스 요청 링크를 줄여 데이터베이스 중단을 방지합니다. 고장이든, 나중에 논의할 침투와 산사태이든, 모두 캐시의 특정 단축키가 실패하는 경우와 같이 높은 동시성을 전제로 한다는 점에 유의해야 합니다.

2. 문제의 원인

두 가지 주요 이유가 있습니다.

• 1. 키가 만료되었습니다.

• 2.

첫 번째 이유로 Redis에서는 Key에 만료 시간이 있습니다. 특정 시점(몰에서 이벤트를 진행하는 경우 0:00부터)에 키가 만료되면 특정 제품에 대한 모든 쿼리 요청이 발생합니다. 0시 이후에는 데이터베이스에 푸시되어 데이터베이스가 중단됩니다.

두 번째 이유는 메모리가 제한되어 있기 때문에 새로운 데이터를 항상 캐시해야 하고 오래된 데이터를 제거해야 하기 때문입니다. 따라서 특정 페이지 교체 전략(일반적인 페이지 교체 알고리즘 예시)에서는 데이터를 제거해야 합니다. 어떤 경우에는 제품이 홍보되기 전에 아무도 관심을 두지 않으면 반드시 제거됩니다.

3. 고장 처리를 위한 처리 아이디어

정상적인 처리 요청은 그림과 같습니다.

Redis의 단일 스레드 특성에 따라 Redis에 트래픽이 많을 경우 키 만료가 불가피합니다. , 작업이 대기열에서 순차적으로 실행되는 것으로 간주할 수 있습니다. 요청이 Redis에 도달하고 키가 만료된 것으로 확인되면 잠금 설정 작업이 수행됩니다.

이 과정은 대략 다음과 같습니다.

• 요청이 Redis에 도달하고 Redis 키가 만료되었음을 확인합니다. 잠금이 없는 경우 대기열 뒤로 돌아갑니다. 잠금을 설정한 다른 스레드가 있을 수 있으므로 잠금을 설정해야 합니다. 데이터베이스를 사용하여 데이터를 가져오고 요청이 반환된 후 잠금을 해제합니다.

• 그런데 새로운 질문이 생깁니다. 잠금을 받고 데이터를 가져오라고 요청한 후 전화를 끊으면 어떻게 될까요? 즉, 잠금이 해제되지 않고 다른 프로세스가 잠금을 기다리고 있습니다.
  네 잠금은 만료 시간을 설정해두었는데, 만료 시간이 지나서 풀리지 않으면 자동으로 풀립니다. 문제는 또 잠금이 걸려있다는 것입니다. 즉, 설정된 시간 내에 데이터가 꺼내지지 않지만 잠금이 만료되어 잠금 만료 시간 값이 증가한다는 것이 일반적인 생각이지만 첫 번째 요청이 시간 초과될 수 있으므로 신뢰할 수 없습니다. 후속 요청도 시간 초과됩니다. 연속으로 여러 번 시간 초과되면 잠금 만료 시간 값이 필연적으로 매우 커집니다. 예, 이에 대한 단점이 너무 많습니다.

또 다른 아이디어는 다른 스레드를 시작하고 이를 모니터링하는 것입니다. 데이터를 가져오는 스레드가 중단되지 않으면 잠금 만료 시간을 적절하게 지연시킵니다.

4. 침투

데이터베이스에 존재하지 않는 데이터에 접근하는 요청이 많은 것이 주된 이유입니다. 예를 들어 책을 판매하는 쇼핑몰에서는 Redis 캐시 때문에 차 제품을 쿼리하도록 요청되었습니다. 주로 핫 데이터를 캐시하는 데 사용되며 데이터베이스에 존재하지 않는 데이터는 캐시할 수 없습니다. 이러한 종류의 비정상적인 트래픽은 데이터베이스에 직접 도달하여 "없음" 쿼리 결과를 반환합니다.

이런 종류의 요청을 처리하기 위한 해결책은 액세스 요청에 블룸 필터, 향상된 블룸 필터, 뻐꾸기 필터와 같은 필터 계층을 추가하는 것입니다.

블룸 필터 외에도 일부 매개변수 검사를 추가할 수 있습니다. 예를 들어 데이터베이스 데이터 ID는 일반적으로 id = -10과 같은 매개변수를 요청하는 경우 이러한 상황을 피하기 위해 Redis가 우회됩니다. 사용자 인증 테스트 및 기타 작업을 확인할 수 있습니다.

5. Avalanche

Avalanche는 고장과 비슷합니다. 차이점은 고장은 특정 순간에 핫스팟 키가 많이 고장나는 반면, 눈사태는 한 순간에 많은 수의 핫스팟 키가 고장나는 경우입니다. 눈사태를 해결하기 위한 전략을 강조하는 것은 매우 부정확한 임의 만료 시간입니다. 예를 들어 은행이 활동을 수행할 때 이자 계수는 이전에는 2%였지만 0점 이후에는 계수가 3%로 변경됩니다. 이런 경우 사용자의 해당 키를 임의 만료로 변경할 수 있나요? 과거의 데이터를 사용하는 경우 이를 더티 데이터(Dirty Data)라고 합니다.

당연히 불가능해, 같은 돈을 저축해라 f0c; 연말까지 이자를 300만 저축하는데 옆집엔 200만밖에 없네 이건 싸움이 아니야 농담이야~

정확한 생각은 먼저 키가 적절한 시간에 만료되는지 확인하십시오. 문제가 성별과 관련이 있지만 시간과 관련이 없는 경우 임의의 만료 시간으로 해결할 수 있습니다.

예를 들어 방금 언급한 은행이 특정 날짜에 특정 계수를 변경하는 경우와 같이 시점과 관련된 경우 먼저 모든 키를 과거 스레드로 업데이트하는 강력한 종속성 분석 솔루션을 사용해야 합니다.

백그라운드에서 핫스팟 키를 업데이트하는 동안 비즈니스 계층에서는 후속 핫스팟 키 업데이트에 대한 부담을 분산시키기 위해 몇 밀리초 또는 몇 초 동안 잠시 절전 모드로 전환하는 등 들어오는 요청을 지연시킵니다.

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