Redis 와 MySQL 의 더 블 쓰기 일치 성 을 어떻게 보장 하 는 지 에 대해 이야기 해 보 겠 습 니 다.

1 일치 성 이란 무엇 인가?

일치 성 은 바로 데이터 가 일치 하 는 것 이다.분포 식 시스템 에서 여러 노드 에서 데이터 의 값 이 일치 하 는 것 으로 이해 할 수 있다.
강 한 일치 성:이러한 일치 성 단 계 는 사용자 의 직관 에 가장 부합 되 고 시스템 에 무엇 을 기록 하 라 고 요구 하 며 읽 은 것 도 무엇 인지,사용자 의 체험 성 이 좋 지만 실현 하면 시스템 의 성능 에 큰 영향 을 미친다.
약 한 일치 성:이러한 일치 성 단 계 는 시스템 이 기록 에 성공 한 후에 기록 한 값 을 즉시 읽 을 수 있 는 것 을 약속 하지 않 고 얼마 후에 데이터 가 일치 하 는 것 을 약속 하지 않 지만 가능 한 한 특정한 시간 단계(예 를 들 어 초 단계)까지 보장 한 후에 데이터 가 일치 하 는 상태 에 이 를 수 있 습 니 다.
최종 일치 성:최종 일치 성 은 약 한 일치 성의 특례 로 시스템 은 일정한 시간 안에 데이터 가 일치 하 는 상태 에 이 를 수 있 도록 보장 할 것 이다.여기 서 최종 일치 성 을 단독으로 제기 한 이 유 는 약 일치 성에 서 매우 추앙 하 는 일치 성 모델 이자 업계 가 대형 분포 식 시스템 의 데이터 일치 성에 있어 비교적 추앙 하 는 모델 이기 때문이다.
 두 세 개의 전형 적 인 캐 시 모드
캐 시 는 성능 을 향상 시 키 고 데이터베이스 압력 을 완화 시 킬 수 있 지만 캐 시 를 사용 하 는 것 도 데이터 의 불일치 문 제 를 초래 할 수 있다.일반적으로 우 리 는 캐 시 를 어떻게 사용 합 니까?세 가지 전형 적 인 캐 시 사용 모드 가 있 습 니 다.

Cache-Aside Pattern；

Read-Through / Write-Through

Write-behind

(1) Cache-Aside
Cache-Aside Pattern,즉 측로 캐 시 모드 입 니 다.캐 시 와 데이터베이스 의 데이터 가 일치 하지 않 는 문 제 를 가능 한 한 해결 하기 위해 서 였 다.
a.Cache-Aside 읽 기 절차
4.567914 의 읽 기 요청 절 차 는 다음 과 같다.

읽 을 때 캐 시 를 먼저 읽 고 캐 시가 명중 되면 데 이 터 를 되 돌려 줍 니 다.캐 시가 명중 되 지 않 으 면 데이터 베 이 스 를 읽 고 데이터베이스 에서 데 이 터 를 꺼 내 캐 시 에 넣 은 후 응답 을 되 돌려 줍 니 다.b.cache-Aside 쓰기 프로 세 스
Cache-Aside Pattern 의 쓰기 요청 절 차 는 다음 과 같 습 니 다.

업 데 이 트 를 받 았 을 때 데이터 베 이 스 를 업데이트 한 다음 캐 시 를 삭제 합 니 다.
이 데이터 가 다음 에 필요 할 때 Cache-Aside 모드 를 사용 하면 데 이 터 를 가 져 올 때 데이터 창고 에서 데 이 터 를 가 져 와 Cache 에 기록 합 니 다.
(2)Read-Through/Write-Through(읽 기와 쓰기 관통)
Read/Write-Through 모드 에서 서버 는 캐 시 를 주요 데이터 로 저장 합 니 다.응용 프로그램 과 데이터베이스 캐 시 상호작용 은 모두 추상 캐 시 층 을 통 해 이 루어 진다.
a.Read-Through
Read-Through 읽 는 간단 한 절 차 는 다음 과 같 습 니 다.

캐 시 에서 데 이 터 를 읽 고 직접 되 돌 릴 때 까지 읽 기;
읽 을 수 없 으 면 데이터베이스 에서 불 러 오고 캐 시 에 기록 한 후 응답 을 되 돌려 줍 니 다.
이 간단 한 절 차 는 Cache-Aside 와 비슷 하지 않 나 요?사실 Read-Through 는 Cache-Provider 가 한 층 더 생 겼 을 뿐 입 니 다.절 차 는 다음 과 같 습 니 다.

Read-Through 는 실제로 Cache-Aside 위 에 한 층 의 패 키 징 만 했 을 뿐 프로그램 코드 를 더욱 간결 하 게 만 들 고 데이터 소스 의 부하 도 줄 일 수 있 습 니 다.
b.Write-Through
Write-Through 모드 에서 쓰기 요청 이 발생 했 을 때 캐 시 추상 층 에서 데이터 원본 과 캐 시 데이터 의 업 데 이 트 를 완성 합 니 다.절 차 는 다음 과 같 습 니 다.

(3)Write-behind(비동기 캐 시 기록)
Write-behind 는 Read-Through/Write-Through 와 비슷 한 점 이 많 습 니 다.모두 Cache Provider 가 캐 시 와 데이터 베 이 스 를 읽 고 쓰 는 것 을 책임 집 니 다.이들 은 또 하나의 큰 차이 점 이 있다.Read/Write-Through 는 캐 시 와 데 이 터 를 동기 화 하 는 것 이 고 Write-Behind 는 캐 시 만 업데이트 하 며 데이터 베 이 스 를 직접 업데이트 하지 않 고 대량의 비동기 방식 으로 데이터 베 이 스 를 업데이트 한다.

이런 방식 에서 캐 시 와 데이터베이스 의 일치 성 이 강하 지 않 기 때문에 일치 성에 대한 요구 가 높 은 시스템 은 신중하게 사용 해 야 한다.
그러나 이 는 자주 쓰 는 장면 에 적합 하 다.MySQL 의 Innodb Buffer Pool 체 제 는 바로 이런 모델 을 사용 하 는 것 이다.
3.캐 시 를 조작 할 때 캐 시 를 삭제 하 는 것 입 니까?캐 시 를 업데이트 하 는 것 입 니까?
일상적인 개발 에서 우리 가 일반적으로 사용 하 는 것 은 Cache-Aside 모델 이다.그러나 여기 서 우 리 는 Cache-Aside 가 요청 을 쓸 때 왜 캐 시 를 업데이트 하 는 것 이 아니 라 캐 시 를 삭제 하 는 지 알 게 되 었 습 니 다.

캐 시 를 조작 할 때 캐 시 를 삭제 해 야 합 니까?캐 시 를 업데이트 해 야 합 니까?여기 서 하나의 예 를 통 해 설명 한다.

스 레 드 A 는 먼저 쓰기 동작 을 시작 하고 첫 번 째 단 계 는 데이터 베 이 스 를 업데이트 합 니 다.스 레 드 B 는 먼저 쓰기 동작 을 시작 하고 두 번 째 단 계 는 데이터 베 이 스 를 업데이트 합 니 다.그러나 네트워크 등 으로 인해 스 레 드 B 는 캐 시 를 먼저 업데이트 했다.스 레 드 A 캐 시 업데이트;
또한 캐 시 를 업데이트 하 는 것 은 캐 시 를 삭제 하 는 것 보다 두 가지 약점 이 있 습 니 다.
만약 당신 이 기록 한 캐 시 값 이 복잡 한 계산 을 거 쳐 얻 은 것 이 라면 캐 시 업데이트 빈도 가 높 으 면 성능 을 낭비 합 니 다.데이터 베 이 스 를 쓰 는 장면 이 많 고 데 이 터 를 읽 는 장면 이 적은 상황 에서 데 이 터 를 읽 지 못 하고 업데이트 되 는 경우 가 많 습 니 다.이것 도 성능 을 낭비 합 니 다.4.더 블 쓰기 의 경우 데이터 베 이 스 를 먼저 조작 하 시 겠 습 니까?캐 시 를 먼저 조작 하 시 겠 습 니까?
4.567914.캐 시 모드 에서 일부 동료 들 은 의문 이 있 습 니 다.요청 을 쓸 때 왜 데이터 베 이 스 를 먼저 조작 합 니까?왜 캐 시 를 먼저 조작 하지 않 습 니까?
예:A,B 두 개의 요청 이 있다 고 가정 하고 A 에 게 업데이트 작업 을 요청 하 며 B 에 게 조회 읽 기 작업 을 요청 합 니 다.

스 레 드 A 에서 쓰기 동작 을 시작 합 니 다.첫 번 째 단계 del cache;이 때 스 레 드 B 에서 읽 기 동작 을 시작 합 니 다.cache miss;스 레 드 B 는 DB 를 계속 읽 고 오래된 데 이 터 를 읽 습 니 다.이때 스 레 드 B 는 오래된 데 이 터 를 cache 에 설정 합 니 다.스 레 드 A 가 DB 업데이트 데 이 터 를 기록 합 니 다.
캐 시 와 데이터베이스 데이터 가 일치 하지 않 습 니 다.캐 시 는 오래된 데 이 터 를 저장 하고 데이터 베 이 스 는 새로운 데 이 터 를 저장 합 니 다.따라서 Cache-Aside 캐 시 모드 는 캐 시 를 먼저 조작 하 는 것 이 아니 라 데이터 베 이 스 를 먼저 조작 하 는 것 을 선택 했다.
그러나 이 럴 때 동료 들 은 데이터 베 이 스 를 먼저 조작 하고 캐 시 를 조작 하 는 것 이 다 르 면 일치 하지 않 을 수 있 습 니까?둘 이 원자 조작 도 아니 고그 럴 거 야.그러나 이런 방식 은 캐 시 삭제 실패 등 으로 더러 운 데 이 터 를 초래 할 확률 이 낮다.
그렇다면 이러한 캐 시 삭제 에 실패 한 상황 에 대해 어떻게 일치 성 을 보장 합 니까?
데이터베이스 와 캐 시 데이터 가 일치 합 니 다.괜 찮 겠 습 니까?
실제로 데이터베이스 와 캐 시 의 절대적 인 일치 성 을 이 룰 수 는 없다.
자물쇠 넣 어도 돼 요?동시 쓰기 기간 에 자 물 쇠 를 추가 합 니 다.읽 기 동작 은 캐 시 에 쓰 지 않 습 니까?캐 시 및 데이터베이스 패키지 CAS 낙관적 잠 금,캐 시 업데이트 시 lua 스 크 립 트 를 통 해?분산 사무,3PC?TCC?
사실 이 는 CAP 이론 에 의 해 결정 된다.캐 시 시스템 에 적용 되 는 장면 은 비강 일 치 된 장면 으로 CAP 의 AP 에 속한다.개인 적 으로 절대적 인 일치 성 을 추구 하 는 업무 장면 은 캐 시 도입 에 적합 하지 않다 고 생각 합 니 다.
CAP 이론 은 분포 식 연극 에서 Consistency(일치 성),Availability(가용성),Partition tolerance(분 구 용 착 성)를 말한다.세 가 지 를 동시에 가 질 수 없다.
5 가지 방안 은 데이터베이스 와 캐 시 의 일치 성 을 확보 합 니 다(1)캐 시 지연 더 블 삭제
일부 동료 들 은 반드시 데이터 베 이 스 를 먼저 조작 해 야 하 는 것 은 아니 라 캐 시 지연 더 블 삭제 전략 을 사용 하면 데이터 의 일치 성 을 확보 할 수 있다 고 말 할 수 있다.그렇다면 시간 지연 더 블 삭 제 는 무엇 일 까?

캐 시 삭제 하기;데이터베이스 업데이트 하기;조금 만 더 휴면(예 를 들 어 1 초)하고 캐 시 를 다시 삭제 합 니 다.
그럼 이 건 잠깐 쉬 는 거 예요.보통 얼마나 걸 려 요?다 1 초?
이 휴면 시간=업무 논리 데 이 터 를 읽 는 데 걸 리 는 시간+수백 밀리초.읽 기 요청 이 끝 났 는 지 확인 하기 위해 읽 기 요청 이 가 져 올 수 있 는 캐 시 더러 운 데 이 터 를 삭제 할 수 있 습 니 다.
이런 방안 은 그런대로 괜 찮 은 편 이다.휴면 하 는 순간(예 를 들 어 그 1 초)에 만 더러 운 데이터 가 있 을 수 있 고 일반 업무 도 받 아들 일 수 있다.하지만 두 번 째 캐 시 삭제 에 실패 하면?캐 시 와 데이터 베 이 스 는 일치 하지 않 을 수 있 습 니 다.그 렇 죠?Key 에 게 자 연 스 러 운 expire 만 료 시간 을 설정 해서 자동 으로 만 료 시 키 는 것 이 어 떻 습 니까?그 업 무 는 기한 이 지난 시간 내 에 데이터 가 일치 하지 않 는 것 을 받 아들 여야 합 니까?아니면 다른 더 좋 은 방안 이 있 을까요?
(2)캐 시 삭제 재 시도 메커니즘
지연 더 블 삭제 든 Cache-Aside 의 먼저 데이터 베 이 스 를 조작 하고 캐 시 를 삭제 하 든 두 번 째 캐 시 삭제 에 실패 하여 데이터 가 일치 하지 않 는 문제 가 발생 할 수 있 습 니 다.이 방안 을 사용 하여 최적화 할 수 있 습 니 다.삭제 에 실패 하면 몇 번 더 삭제 해 야 합 니 다.캐 시 삭제 에 성공 하면 됩 니 다.그래서 캐 시 삭제 재 시도 체 제 를 도입 할 수 있 습 니 다.

데이터베이스 업데이트 요청 쓰기;캐 시 는 어떤 이유 로 삭제 에 실 패 했 습 니 다.삭제 에 실패 한 키 를 메시지 대기 열 에 놓 기;메시지 큐 에 대한 정 보 를 소비 하고 삭제 할 key 가 져 오기;캐 시 삭제 다시 시도 하기;(3)binlog 비동기 읽 기 캐 시 삭제
캐 시 시스템 을 다시 삭제 하 는 것 은 괜 찮 지만 많은 업무 코드 가 침입 할 수 있 습 니 다.사실은 이렇게 최적화 할 수 있다.데이터 뱅 크 의 binlog 를 통 해 비동기 탈락 key.

이상 은 바로 Redis 와 MySQL 의 더 블 쓰기 일치 성 을 어떻게 보장 하 는 지 에 대한 상세 한 내용 입 니 다.Redis 와 MySQL 의 더 블 쓰기 일치 성에 관 한 자 료 는 저희 의 다른 관련 글 을 주목 해 주 십시오!