레디 스 오늘은 몇 가지 일반적인 면접 질문을 공유 :

어떻게 캐시 사태를 해결하기 위해?
어떻게 캐시가 침투 해결하기 위해?
어떻게 데이터베이스 캐시를 두 번 쓰기와 일관성 문제를 보장하기 위해?

캐시 눈사태

1.1 캐시 사태는 무엇입니까?

첫째, 우리는 캐시 (레디 스)를 사용하는 이유는 무엇입니까이 질문에 대답하자 :

캐시 쿼리가 순수 메모리 액세스 및 하드 디스크 액세스, 그래서 쿼리 캐시는 데이터베이스 쿼리의 속도보다 빠르다 : 1, 성능을 향상시킬 수 있습니다

요청의 일부 캐시 그룹, 높은 동시성을 지원하기 위해 2, 동시 능력을 향상

이제 문제는,이 우리가 우리의 모든 요청이 데이터베이스를 실행한다는 것을 의미 캐시를 걸 경우 .

우리 모두는 레디 스 데이터가 (캐시 모두에 둘 수 없음을 알고 메모리가 비싸고 제한 레디 스 데이터가 만료 시간을 설정해야하므로), 키 - 값 쌍을 삭제 만료됩니다, 그것은 + 불활성는 정기적으로 두 가지 전략을 삭제하려면 삭제를 사용 만료 된 키의 삭제.

캐시 데이터의 경우 만료 시간이 동일 하고,이 모든 단지 레디 스 빛의 데이터의 일부를 삭제합니다. 이것은이 기간에,이 캐시가 발생할 수 있습니다 동시에 실패 , 데이터베이스에 대한 모든 요청을.

이 캐시 눈사태입니다 :

레디 스 모든 데이터베이스 요청을 이동 전화를 끊었다.
캐시 된 데이터는 일정 시간 캐시 미스, 모든 데이터베이스를 이동하는 요청의 결과로, 동일한 유효 기간을 설정합니다.

이 경우 캐시 눈사태, 우리의 데이터베이스 넣을 가능성이 파멸을 전체 서비스의 마비의 결과!

1.2 방법 캐시 사태를 해결하기 위해?

.은 "모든 데이터베이스 요청을 이동, 일정 시간 캐시 미스의 결과로, 캐시 된 데이터에 대해 동일한 만료 시간 설정"이것은 매우 좋은 솔루션입니다 :

해결 방법 : 때 캐시 만료 시간을 추가하는 임의의 값 을 크게 것, 캐시를 줄이는 동시에 만료 .

은 "레디 스를 끊었 모든 데이터베이스 요청을 이동"이 상황은, 우리는 다음과 같은 생각을 할 수 있습니다 :

이 사건 이전 : 레디 스를 달성 고 가용성 (마스터 - 슬레이브 아키텍처 + 센티넬 또는 레디 스 클러스터), 레디 스는 이런 일이 발생 걸 피하려고.
사건에 : 레디 스 정말 사건을 끊었, 우리는 설정할 수 있습니다 로컬 캐시 (으로 Ehcache) + 전류 제한 (hystrix) , 우리의 데이터베이스는 (적어도 우리의 서비스가 정상적으로 작동 할 수 있도록) 죽일이었다 피하기 위해 노력을
사건 후 : 영구적 인 레디 스, 자동으로 다시 시작 디스크에서 데이터를로드 빠른 복구 캐시 데이터 .

둘째, 캐시 침투

2.1 캐시 침투는 무엇인가

예를 들어, 우리는 데이터베이스 테이블을, ID 1이 (의 처음부터입니다 긍정적 ),하지만 내 데이터베이스를 망치려고 해커가있을 수 있습니다, 각 요청의 ID입니다 음 . 이 갈 모든 데이터베이스 요청을 찾아 내 캐시에 쓸모 리드하지만, 아, 항상 null 객체를 반환 이러한 데이터베이스 값이 없습니다.

캐시 침투 특정 쿼리를 말한다 존재하지 않는 데이터 . 에서 경우 캐시 미스 및 결함에 대한 허용 오차를 고려하기 때문에, 데이터베이스의 데이터를 찾는 캐시에 기록되지 않은 데이터의 부재로 이어질 것입니다, 조회 할 데이터베이스에 대한 모든 요청에 , 그것은 캐시의 의미를 잃었다.

이 캐시 침투입니다 :

요청에 이어지는 캐시 미스에 요청 된 데이터, 많은 수의 데이터베이스를 이동합니다.

이 경우 관통 캐시, 우리의 데이터베이스도 가능합니다 쓰러 뜨리 전체 서비스의 마비의 결과!

2.1 어떻게 캐시가 침투 해결하기 위해?

두 가지 옵션이 있습니다, 캐시 침투를 해결 :

요청의 매개 변수가 합법적이 아니기 때문에 (모든 요청 매개 변수가 존재하지 않음), 그래서 우리가 사용할 수있는 블룸 필터 (블룸 필터) 압축 필터 또는 조기 차단을 , 불법, 데이터베이스 계층이 요청을하지 않습니다!
우리는 데이터베이스에서 찾을 수 없을 때, 우리는 것입니다 빈 캐시 개체가 내부 이동하도록 설정 . 하면 다음 번에 요청, 당신은 캐시에서 내부를 얻을 수 있습니다.
이 경우 우리는 일반적으로 빈 객체는 설정합니다 짧은 만료 시간을 .

셋째, 쓰기 캐싱 및 이중 일관성있는 데이터베이스

읽기 동작은 3.1, 처리되도록 인

캐시 침투 말하기, 또한 위에서 언급 한 : 당신이 기록 된 데이터베이스 캐시에서 데이터를 찾을 수없는 경우.

일반적으로 우리는 읽을 같은 시간이 일상적인 고정이 :

캐시에 내부가 캐시에 우리의 데이터는 다음에 직접 액세스합니다.
데이터 캐시가없는 우리가 원하는 경우, 우리는 데이터베이스를 쿼리로 이동하며, 데이터베이스 캐시에 기록 된 데이터를 확인합니다 .
마지막으로, 데이터는 요청자에게 반환

3.2 캐시와 듀얼 - 쓰기 데이터베이스 일관성 문제는 무엇인가?

단지 쿼리 경우, 데이터는 데이터와 데이터베이스가 문제가되지 않습니다 캐시. 그러나 우리가하고자 할 때 업데이트 그것을위한 시간? 각각의 경우는 가능성이 데이터베이스 및 캐시 된 데이터 불일치가 발생할 의.

다음은 일관성 수단 데이터베이스 데이터와 일치하지 않는 데이터 캐시

이론적으로 한 우리가 설정 한 키의 만료 시간을 , 우리는 데이터 캐시와 데이터베이스가 있음을 보장 할 수 와 궁극적으로 일치 . 캐시 된 데이터가 만료 한, 그것은 삭제됩니다. 그런 다음 어떤 캐시가 없기 때문에, 당신은 데이터베이스에서 데이터를 확인하고 캐시에 데이터를 조사하기 위해 데이터베이스에 기록 할 수 있습니다 읽어 보시기 바랍니다.

만료 시간을 설정하는 것 외에, 우리는 더 할 필요가 피할 일이 일관성에서 데이터베이스 캐시를.

3.3 업데이트

업데이트 작업을 수행 할 때 일반적으로, 우리는 두 가지 선택이있다 :

데이터베이스를 운영하고 캐시를 조작하려면
첫 번째 작업 캐시, 다음은 데이터베이스를 운영

첫째, 상관없이 우리가 무엇을 선택 우리 모두가 희망 것이 분명해야합니다 동시에 두 가지 작업이 성공하거나 동시에 실패 중 하나 . 그래서, 이것은로 바뀝니다 분산 트랜잭션 문제.

그래서, 원자 파괴되는 경우 , 다음과 같은 경우가있을 수 있습니다 :

데이터베이스의 성공적인 운영, 캐시 작업이 실패했습니다 .
캐시 작업이 성공, 데이터베이스 작업이 실패했습니다 .

첫 번째 단계가 실패하면, 우리가 직접 예외 밖으로 잘 돌아, 두 번째 단계는 실행되지 않습니다.

여기에서 우리는 그것에 대해 구체적인 분석 할 수 있습니다.

3.3.1 운영 캐시

캐시 작업은 두 가지 옵션이 있습니다 :

업데이트 캐시
캐시 삭제

일반적으로, 우리는로 이동합니다 캐시 제거 다음과 같은 이유로 캐싱 정책을 :

캐시를 갱신과 함께 높은 경우 동시 환경 이전 여부 데이터베이스 작업 데이터베이스의 관점에서 작업 후에,이다 쉽게 데이터베이스 원인이 캐시 데이터 불일치 . (캐시를 삭제 직접 단순히 많은)
각 데이터베이스를 업데이트하는 경우 캐시를 [이 어떤 성능을 비용 자주 업데이트의 현장을 말한다] 업데이트가 즉시 삭제해야한다. 등시는 (데이터베이스에 반영 내부에있는 캐시에 기록 된 후, 더 캐시, 나는 데이터베이스를 찾을 다시 읽고 느리게 )

이 두 지점을 기반으로 캐시를 업데이트 할 때,을 수행하는 것이 좋습니다 삭제 작업을!

3.3.2 데이터베이스를 업데이트 한 다음 캐시를 삭제

정상적인 상황은 이것이다 :

데이터베이스, 성공을 조작합니다;
그리고 캐시뿐만 아니라 성공을 삭제;

원자 파괴되는 경우 :

성공적으로 (작동 데이터베이스)의 첫 번째 단계, 두 번째 단계가 실패 (캐시 삭제)가 발생합니다 데이터베이스를 새로운 데이터, 이전 데이터 캐시입니다 .
첫 번째 단계는 (데이터베이스를 운영하는) 실패했을 경우에, 우리는 데이터 불일치하지 않고, 직접 오류 (예외)를 반환 할 수 있습니다.

높은 동시성 시나리오에서 일관성 데이터베이스 및 캐시 데이터의 경우 확률이 특히 낮은 , 그것은없는 것은 아니다 :

캐시는 단지 실패
스레드 데이터베이스를 쿼리, 오래된 값이었다
스레드 B는 데이터베이스에 새 값을 기록
스레드 B는 캐시를 삭제
스레드는 이전 값 쓰기 캐시에서 찾을 수

상기 경우를 달성하거나 대답 특히 낮은 확률을 :

이 조건이 읽기 캐시 캐시 미스에 일어날 필요로하고 있기 때문에 쓰기 작업과 동시있다. 실제로 데이터베이스 쓰기 작업이 읽기 작업보다 훨씬 느립니다뿐만 아니라 테이블을 잠그고하는 캐시를 업데이트 늦게 쓰기 작업에 대한 실행하는 동안, 그리고 쓰기 작업 전에 필요한 데이터베이스 작업에 읽기 , 이러한 조건이 모두 충족 기본 확률은 크지 않다.

이 전략, 사실, 디자인 패턴은 다음과 같습니다Cache Aside Pattern

솔루션 실패의 캐시를 삭제합니다 :

키는 메시지 큐에 전송 삭제할
자신의 소비 메시지, 키가 삭제하세요
성공할 때까지 재 시도를 삭제 작업을 계속

3.3.3 캐시를 삭제 한 다음 데이터베이스를 업데이트

이 같은 일반적으로 뭔가 :

캐시, 성공을 삭제;
그리고 또한 성공적으로 데이터베이스를 업데이트;