Redis를 사용할 때 주의해야 할 점은 무엇인가요?

Redis 사용 시 주의해야 할 주요 문제는 다음과 같습니다.

Redis 및 데이터베이스 이중 쓰기 일관성 문제 (권장 학습: Redis 비디오 튜토리얼)

분석: 일관성 문제는 일반적인 분산 문제입니다. , 그리고 그들은 최종 일관성과 강력한 일관성으로 더 구분됩니다. 데이터베이스와 캐시가 이중으로 기록되면 필연적으로 불일치가 발생합니다. 이 질문에 답하려면 먼저 전제를 이해해야 합니다. 즉, 데이터에 대한 강력한 일관성 요구 사항이 있으면 캐시할 수 없습니다. 우리가 하는 모든 일은 최종 일관성만 보장할 수 있습니다. 또한 근본적으로 우리가 만든 솔루션은 불일치 가능성을 줄일 수 있을 뿐 불일치를 완전히 피할 수는 없습니다. 따라서 강력한 일관성 요구 사항이 있는 데이터는 캐시할 수 없습니다. ----------

분석: 일관성 문제는 일반적인 분산 문제이며 최종 일관성과 강력한 일관성으로 더 나눌 수 있습니다. 데이터베이스와 캐시가 이중으로 기록되면 필연적으로 불일치가 발생합니다. 이 질문에 답하려면 먼저 전제를 이해해야 합니다. 즉, 데이터에 대한 강력한 일관성 요구 사항이 있으면 캐시할 수 없습니다. 우리가 하는 모든 일은 최종 일관성만 보장할 수 있습니다. 또한 근본적으로 우리가 만든 솔루션은 불일치 가능성을 줄일 수 있을 뿐 불일치를 완전히 피할 수는 없습니다. 따라서 강력한 일관성 요구 사항이 있는 데이터는 캐시할 수 없습니다.

우선 올바른 업데이트 전략을 채택하고 데이터베이스를 먼저 업데이트한 다음 캐시를 삭제하세요. 둘째, 캐시 삭제 실패 문제가 발생할 수 있으므로 메시지 큐를 활용하는 등의 보상 방안을 마련하는 것으로 충분하다.

캐시 침투 및 캐시 사태 문제 처리 방법

분석: 솔직히 이 두 가지 문제는 중소 규모의 전통적인 소프트웨어 회사가 직면하기가 매우 어렵습니다. 대규모 동시 프로젝트가 있는 경우 트래픽은 약 수백만 달러에 이릅니다. 이 두 가지 문제를 깊이 생각해 보아야 합니다.

답변: 아래와 같이

캐시 침투 즉, 해커가 의도적으로 캐시에 존재하지 않는 데이터를 요청하여 모든 요청이 데이터베이스로 이동하게 하여 데이터베이스 연결이 비정상적으로 되는 현상을 말합니다.

해결책:

(1) 뮤텍스 잠금을 사용합니다. 캐시가 실패하면 먼저 잠금을 얻은 다음 데이터베이스를 요청합니다. 잠금을 얻지 못하면 일정 시간 동안 잠자기 상태가 된 후 다시 시도합니다

(2) 비동기 업데이트 전략을 채택하고 키에 값이 있는지 여부에 관계없이 직접 반환합니다. 캐시 만료 시간은 value 값으로 유지됩니다. 캐시가 만료되면 스레드가 비동기적으로 시작되어 데이터베이스를 읽고 캐시를 업데이트합니다. 캐시 예열(프로젝트 시작 전 캐시 로딩) 작업이 필요합니다.

(3) 요청이 유효한지 신속하게 확인할 수 있는 차단 메커니즘을 제공합니다. 예를 들어 Bloom 필터를 사용하여 일련의 합법적이고 유효한 키를 내부적으로 유지 관리합니다. 요청에 포함된 키가 합법적이고 유효한지 신속하게 확인합니다. 불법이라면 직접 반납하세요.

Cache Avalanche, 즉 넓은 영역에서 캐시가 동시에 실패하는 현상입니다. 이때 또 다른 요청의 물결이 들어오고 결과적으로 요청이 모두 데이터베이스로 전송되어 비정상적인 데이터베이스가 발생합니다. 연결.

해결책:

(1) 집단적 실패를 방지하려면 캐시 만료 시간에 임의의 값을 추가합니다.

(2) 뮤텍스 잠금을 사용하지만 이 솔루션의 처리량이 크게 떨어집니다.

(3) 더블 캐시. 캐시 A와 캐시 B라는 두 개의 캐시가 있습니다. 캐시 A의 만료 시간은 20분이고, 캐시 B의 만료 시간은 없습니다. 캐시 준비 작업을 직접 수행하십시오. 그런 다음 다음 사항을 분석합니다.

I 캐시 A에서 데이터베이스를 읽고, 있으면 직접 반환합니다.

II A에는 데이터가 없으며, B에서 직접 데이터를 읽고, 직접 반환하고, 비동기적으로 업데이트 스레드를 시작합니다.

III 업데이트 스레드는 캐시 A와 캐시 B를 동시에 업데이트합니다.

Redis에서 동시 키 경쟁 문제를 해결하는 방법

분석: 이 문제는 대략적으로 동시에 키를 설정하는 여러 하위 시스템이 있다는 것입니다. 이때 우리가 주의해야 할 점은 무엇입니까? 그것에 대해 생각해 본 적이 있나요? 블로거가 사전에 Baidu를 검색한 결과 기본적으로 redis 트랜잭션 메커니즘을 사용하는 것이 좋습니다. 블로거는 redis 트랜잭션 메커니즘 사용을 권장하지 않습니다. 우리 프로덕션 환경은 기본적으로 Redis 클러스터 환경이므로 데이터 샤딩 작업이 수행됩니다. 트랜잭션에 여러 키 작업이 포함된 경우 이러한 여러 키가 반드시 동일한 redis 서버에 저장될 필요는 없습니다. 따라서 Redis의 트랜잭션 메커니즘은 매우 쓸모가 없습니다.

답변: 아래와 같습니다

(1) 이 열쇠를 조작하면 순서가 필요없습니다

이 경우 분산형 자물쇠를 준비하시면 모두가 자물쇠를 잡고, 자물쇠를 잡은 후 그냥 설정작업을 하시면 됩니다. . 단순 비교.

(2) 이 키를 조작하려면 순서가 필요합니다

key1이 있다고 가정하면 시스템 A는 key1을 valueA로 설정해야 하고 시스템 B는 key1을 valueB로 설정해야 하며 시스템 C는 key1을 valueC로 설정해야 합니다.

예상 key1의 값은 valueA->valueB->valueC의 순서로 변경됩니다. 이때 데이터베이스에 데이터를 쓸 때 타임스탬프를 저장해야 합니다. 타임스탬프가 다음과 같다고 가정합니다.

系统A key 1 {valueA  3:00}
系统B key 1 {valueB  3:05}
系统C key 1 {valueC  3:10}

그런 다음 시스템 B가 먼저 잠금을 잡고 key1을 {valueB 3:05}로 설정한다고 가정합니다. 다음으로, 시스템 A는 잠금을 획득하고 값 A의 타임스탬프가 캐시의 타임스탬프보다 이전임을 확인하므로 설정 작업을 수행하지 않습니다. 등.

Redis 관련 기술 기사를 더 보려면 Redis 데이터베이스 사용 튜토리얼 컬럼을 방문하여 알아보세요!

위 내용은 Redis를 사용할 때 주의해야 할 점은 무엇인가요?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!