Redis 캐시 일관성, 캐시 침투, 캐시 분석 및 캐시 눈사태 문제를 함께 분석해 보겠습니다.

이 기사에서는 캐시 일관성, 캐시 침투, 캐시 고장, 캐시 눈사태 및 캐시된 데이터의 쓰기 동기화 및 DB 일관성과 관련된 문제를 주로 소개하는Redis에 대한 관련 지식을 제공하므로 함께 살펴보시기 바랍니다. 모두에게 도움이 될 것입니다.

관련 권장사항: "Redis의 핫키 저장 문제 분석 및 캐시 예외에 대한 해결책에 대해 이야기"

(1) 캐시 무효화 일관성 문제

일반적인 캐시 사용법은 다음과 같습니다. 먼저 캐시하고, 존재하지 않으면 DB에서 읽고, 다음에 데이터를 읽을 때 결과를 캐시에 기록하면 캐시에서 직접 데이터를 얻을 수 있습니다. [관련 추천 :Redis 영상 튜토리얼]

데이터 수정이란 캐시된 데이터를 직접 무효화한 후 DB 내용을 수정하여 DB 수정이 성공하지 못하도록 하는 방법이지만, 네트워크나 기타 문제로 인해 캐시된 데이터가 정리되지 않아 더러운 데이터. 하지만 동시에 발생하는 시나리오에서는 여전히 더티 데이터 생성을 피할 수 없습니다. 비즈니스에 Key:Hello Value:World 데이터에 대한 읽기 및 수정 요청이 많다고 가정해 보겠습니다. 스레드 A는 OCS에서 Key:Hello를 읽고, Not Found 결과를 가져오고, DB에서 데이터 요청을 시작하고, Key:Hello Value:World 데이터를 가져옵니다. 다음으로 이 데이터를 OCS에 쓸 준비를 하지만 OCS에 쓰기 전에(네트워크) , CPU를 기다리면 스레드 A의 처리 속도가 느려질 수 있습니다.) 또 다른 스레드 B는 데이터 Key:Hello Value:OCS에 대한 수정을 요청하고 먼저 무효화 캐시 작업을 수행합니다. (스레드 B는 이 데이터가 존재하는지 모르기 때문입니다.) 이므로 무효화 작업을 직접 수행합니다.) OCS가 잘못된 요청을 성공적으로 처리했습니다. 스레드 A로 돌아가서 OCS 쓰기를 계속하고 Key:Hello Value:World를 캐시에 씁니다. 스레드 A의 작업도 성공적으로 Key:Hello Value:OCS로 수정되었습니다. 이 문제를 해결하기 위해 OCS는 Memcached 프로토콜(퍼블릭 클라우드가 곧 지원할 예정)을 확장하고 deleteAndIncVersion 인터페이스를 추가했습니다. 이 인터페이스는 실제로 데이터를 삭제하지는 않지만 만료되었음을 나타내기 위해 데이터에 레이블을 지정하고 데이터 버전 번호를 높입니다. 데이터가 없으면 NULL이 기록되고 임의의 데이터 버전 번호도 생성됩니다. OCS 쓰기는 버전 번호의 원자적 비교를 지원합니다. 들어오는 버전 번호가 OCS에 의해 저장된 데이터 버전 번호와 일치하거나 원본 데이터가 존재하지 않는다고 가정하면 쓰기가 허용되고, 그렇지 않으면 수정이 거부됩니다.

지금 장면으로 돌아가서: 스레드 A는 OCS에서 Key:Hello를 읽고, Not Found 결과를 얻고, DB에서 데이터 요청을 시작하고, Key:Hello Value:World 데이터를 가져온 다음 이 데이터를 OCS에 쓸 준비를 합니다. 버전 번호 정보의 기본값은 1입니다. A가 OCS에 쓰기 전에 다른 B 스레드가 데이터 Key:Hello Value:OCS를 수정하는 작업을 시작합니다. 먼저 OCS가 deleteAndIncVersion 요청을 성공적으로 처리하고 임의 버전을 생성합니다. 번호는 12345입니다(1000보다 큰 규칙). 스레드 A로 돌아가서 계속해서 OCS에 쓰기를 요청하고 Key:Hello Value:World 쓰기를 요청합니다. 이때 캐시 시스템은 들어오는 버전 번호 정보가 일치하지 않음(1! = 12345)을 발견하고 쓰기에 실패합니다. 스레드 A의 작업이 종료됩니다. 스레드 B도 DB 데이터 내용을 Key:Hello Value:OCS로 수정했습니다.

이때 OCS의 데이터는 Key:Hello 값:NULL 버전:12345이고, DB의 데이터는 Key:Hello 값:OCS입니다. 후속 읽기 작업에서는 OCS에 쓰기 위해 DB의 데이터를 다시 시도합니다. .

(2) 캐시된 데이터의 쓰기 동기화 및 DB와의 일관성 문제

웹사이트 규모가 커지고 안정성이 향상됨에 따라 각 IDC는 독립적인 DB와 캐시 시스템을 구축하게 됩니다. 현재 캐시 일관성이 중요한 문제가 되었습니다.

우선, 높은 효율성을 보장하기 위해 캐시 시스템은 BINLOG를 작성할 때에도 디스크 IO를 방지합니다. 물론 성능을 위해 캐시 시스템은 동기적으로 삭제할 수만 있고 동기적으로 쓸 수는 없습니다. 동기화는 일반적으로 DB 동기화 도착보다 우선합니다(결국 캐시 시스템의 효율성이 훨씬 높음). 그러면 캐시에 데이터가 없고 DB에 오래된 데이터가 있는 시나리오가 있을 것입니다. 이때, 업무상 데이터 요청이 있고, 읽기 캐시가 Not Found입니다. DB에서 읽어서 캐시에 로드한 기존 데이터는 여전히 DB 데이터 동기화가 도착하면 해당 DB만 업데이트됩니다. , 캐시된 더티 데이터는 지울 수 없습니다.

위 상황에서 볼 수 있듯이 불일치의 근본 원인은 이기종 시스템이 공동으로 동기화할 수 없다는 것입니다. DB 데이터가 먼저 동기화되고 나중에 캐시된 데이터가 동기화된다는 것을 보장할 수 없습니다. 그렇다면 캐시 시스템이 DB 동기화를 어떻게 기다리는지, 아니면 두 시스템이 동기화 메커니즘을 공유할 수 있는지 고려해야 합니다. 캐시 동기화는 또한 실행 가능한 솔루션인 DB BINLOG에 의존합니다.

IDC1의 DB는 BINLOG를 통해 IDC2의 DB와 동기화됩니다. 이 경우 IDC2-DB 데이터 수정 시에도 자체 BINLOG가 생성됩니다. IDC2-DB BINLOG를 통해 캐시된 데이터 동기화를 수행할 수 있습니다. 캐시 동기화 모듈은 BINLOG를 분석한 후 해당 캐시 키를 무효화하고 동기화를 병렬에서 직렬로 변경하여 순서를 보장합니다.

(3) 캐시 침투 (DB가 불필요한 쿼리 트래픽을 겪었습니다)

방법 1: Bloom 필터입니다. 이는 요소가 세트에 있는지 여부를 결정하는 데 사용되는 매우 공간 효율적인 확률 알고리즘 및 데이터 구조입니다(Hashset과 유사). 그 핵심은 긴 바이너리 벡터와 일련의 해시 함수입니다. Google의 구아바를 사용하여 블룸 필터를 구현합니다. 1) 저장된 요소의 개수가 많아질수록 오산 확률도 높아집니다. 2) 일반적인 상황에서는 블룸 필터에서 요소를 삭제할 수 없습니다. 3) 배열 길이와 개수를 결정하는 과정입니다. 해시 함수는 복잡하고 분포가 긴 필터의 사용 시나리오는 무엇입니까? 1) 스팸 주소 필터링(주소 수가 엄청남) 2) 크롤러 URL 주소 중복 제거 3) 캐시 고장 문제 해결

방법 2: 빈 결과를 저장하고 빈 결과에 대한 시간 설정

(4) 캐시 눈사태( 캐시를 동일한 만료 시간으로 설정하면 DB 플러딩이 발생합니다.

방법 1: 대부분의 시스템 설계자는 단일 스레드(프로세스)가 캐시에 쓰기를 보장하여 다수의 동시 요청이 떨어지는 것을 방지하기 위해 잠금 또는 대기열 사용을 고려합니다. 오류 발생 시 기본 스토리지 시스템에서

방법 2: 임의 만료 시간

(5) 캐시 고장(핫 키, 다수의 동시 읽기 요청으로 인한 작은 사태)

캐시가 특정 시점에 만료되는 경우 이 시점에서 이 키에 대한 동시 요청이 많이 발생합니다. 이러한 요청에서 캐시가 만료되었음을 확인하면 일반적으로 백엔드 DB에서 데이터를 로드하고 캐시로 재설정합니다. 이때 대용량 동시 요청은 백엔드 DB를 즉시 압도할 수 있습니다

방법 1: 1. 배포 캐시에서 지원하는 뮤텍스 키(mutex key)를 사용하여 뮤텍스 키를 설정하고, 작업이 성공적으로 반환되면 로드 DB를 수행합니다. 즉, 단 하나의 로드 DB 스레드 처리만 있게 됩니다.

방법 2: 미리 뮤텍스 키를 사용하세요. 값 안에 타임아웃 값(timeout1)을 설정하세요. timeout1은 실제 Memcache 타임아웃(timeout2)보다 작습니다. 캐시에서 timeout1을 읽으면 만료된 것으로 확인됩니다. 시간이 되면 즉시 timeout1을 연장하고 캐시로 재설정한 다음 데이터베이스에서 데이터를 로드하여 캐시로 설정합니다. 이렇게 하면 비즈니스 코드 침입이 증가하고 코딩 복잡성이 증가합니다. : Redis의 관점에서 볼 때 실제로 만료 시간이 없습니다. 이는 핫스팟 키 만료 문제가 없음을 보장합니다. 즉, 만료되지 않으면 기능적 관점에서 "물리적으로" 만료되지 않습니다. , 정적이 되지 않나요? 만료 시간이 곧 만료될 것으로 확인되면 "논리적" 만료

인 백그라운드 비동기 스레드를 통해 캐시가 구성됩니다.

(6) 캐시 시스템의 일반적인 캐시 Fullness 및 데이터 손실

문제는 특정 비즈니스를 기반으로 분석해야 합니다. 일반적으로 오버플로를 처리하기 위해 LRU 전략을 사용하고 데이터 보안을 보장하기 위해 Redis의 RDB 및 AOF 지속성 전략을 사용합니다. 특정 상황에서

더 많은 프로그래밍 관련 지식을 보려면

프로그래밍 비디오

를 방문하세요.

위 내용은 Redis 캐시 일관성, 캐시 침투, 캐시 분석 및 캐시 눈사태 문제를 함께 분석해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!