Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)-Redis-php.cn

Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)

藏色散人

풀어 주다： 2023-02-15 20:09:23

앞으로

1641명이 탐색했습니다.

머리말

4월에 한 친구가 인터뷰를 위해 Meituan에 갔습니다. 그는 Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법에 대한 질문을 받았다고 말했습니다. 이 질문은 실제로 이중 쓰기 시나리오에서 캐시와 데이터베이스의 일관성을 보장하는 방법을 묻습니다. 이 기사에서는 이 질문에 대답하는 방법에 대해 논의할 것입니다.

github 주소, 모든 별에 감사드립니다

일관성에 대해 이야기하세요

일관성은 분산 시스템에서 데이터의 일관성을 의미합니다. 노드 값이 일관됩니다.

강력한 일관성: 이 일관성 수준은 시스템이 작성해야 하는 내용이 판독되는 내용과 가장 일치합니다. 그러나 그 구현은 종종 성능에 큰 영향을 미칩니다. the system
약한 일관성: 이 일관성 수준은 쓰기가 성공한 후 즉시 작성된 값을 읽을 수 있다고 약속하지 않거나 데이터가 일관성을 유지하는 데 걸리는 시간을 약속하지 않도록 시스템을 제한합니다. 시간 수준(예: 두 번째 수준)이 지나면 데이터가 일관성 있는 상태에 도달할 수 있도록 최선을 다할 것입니다.
최종 일관성: 최종 일관성은 약한 일관성의 특별한 경우입니다. 특정 기간 내에 데이터 일관성 상태에 도달할 수 있도록 보장합니다. 여기서 최종 일관성을 별도로 언급하는 이유는 약한 일관성에서 매우 존경받는 일관성 모델이자 대규모 분산 시스템의 데이터 일관성에 대해 업계에서도 높은 평가를 받는 모델이기 때문입니다

세 가지 고전 캐싱 모드

캐싱을 사용하면 성능이 향상되고 데이터베이스 부담이 완화될 수 있지만, 캐시를 사용하면 데이터 불일치가 발생할 수도 있습니다. 일반적으로 캐시를 어떻게 사용합니까? 세 가지 기본 캐싱 패턴이 있습니다.

Cache-Aside Pattern
Read-Through/Write through
Write Behind

Cache-Aside Pattern

Cache-Aside Pattern, 즉 Bypass Cache Mode입니다. 캐시와 데이터베이스 간의 데이터 불일치 문제를 최대한 해결하기 위해 제안되었습니다.

Cache-Aside 읽기 프로세스

Cache-Aside Pattern읽기 요청 프로세스는 다음과 같습니다.

Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)

읽을 때 캐시에 도달하면 데이터가 직접 반환됩니다.

Cache-Aside 쓰기 프로세스

Cache-Aside Pattern쓰기 요청 프로세스는 다음과 같습니다.

Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)

업데이트할 때 먼저

데이터베이스를 업데이트한 다음 캐시를 삭제하세요.

Read-Through/Write-Through(읽기-쓰기 침투)

Read/Write Through 모드에서는 서버가 캐시를 주요 데이터 저장소로 사용합니다. 애플리케이션과 데이터베이스 캐시 간의 상호 작용은 추상 캐시 레이어를 통해 완성됩니다.

Read-Through

Read-Through간단한 과정은 다음과 같습니다

Read Through简要流程

읽을 수 없으면 데이터베이스에서 로드하여 씁니다. 그런 다음 응답을 반환합니다.

이 간단한 프로세스는

Cache-Aside와 비슷합니까? 실제로 Read-Through는 Cache-Provider의 추가 계층입니다. 프로세스는 다음과 같습니다.

Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)

Read-Through는 실제로

Cache-Aside 위에 있는 캡슐화 계층입니다. 그러면 프로그램 코드가 더욱 간결해지고 데이터 소스의 로드도 줄어듭니다.

Write-Through

Write-Through 모드에서는 쓰기 요청이 발생하면 캐시 추상화 계층도 데이터 소스 및 캐시된 데이터의 업데이트를 완료합니다. Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)

Write Behind( 비동기 캐시 쓰기 )

Write Behind는 Read-Through/Write-Through와 유사합니다. 는 캐시와 데이터베이스를 읽고 쓰는 역할을 합니다. 둘 사이에는 큰 차이가 있습니다. Cache ProviderRead/Write Through는 캐시와 데이터를 동기식으로 업데이트하는 반면, Write Behind는 데이터베이스를 직접 업데이트하지 않고 캐시만 업데이트하며, batch asynchronous를 통해 데이터베이스를 업데이트합니다.

Write behind流程

이렇게 하면 캐시와 데이터베이스 간의 일관성이 강하지 않습니다.

일관성 요구 사항이 높은 시스템은 주의해서 사용해야 합니다. 그러나 빈번한 쓰기 시나리오에 적합합니다. MySQL의 InnoDB 버퍼 풀 메커니즘은 이 모드를 사용합니다.

캐시 운영시 캐시를 삭제해야 할까요, 아니면 업데이트를 해야 할까요?

일반적인 비즈니스 시나리오에서는

Cache-Aside 모드를 사용합니다. 일부 친구들은 캐시 제외요청을 작성할 때 왜 캐시를 업데이트하는 대신 캐시를 삭제합니까?라고 물을 수 있습니다.

Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)

캐시를 운영할 때 캐시를 삭제해야 할까요, 아니면 업데이트를 해야 할까요? 먼저 예를 살펴보겠습니다.

스레드 A가 먼저 쓰기 작업을 시작하고, 첫 번째 단계는 데이터베이스를 업데이트하는 것입니다.
스레드 B가 쓰기 작업을 시작한 다음, 두 번째 단계에서는 데이터베이스를 업데이트합니다.
네트워크 및 기타 이유로 인해 스레드 B가 캐시를 먼저 업데이트했습니다
스레드 A가 캐시를 업데이트했습니다.

이때, 캐시는 A의 데이터(기존 데이터)를 저장하고, 데이터베이스는 B의 데이터(새 데이터)를 저장하며, 데이터가 일관되지 않고 더티 데이터가 나타납니다. 캐시를 업데이트하는 대신 캐시를 삭제하면 이러한 더티 데이터 문제는 발생하지 않습니다.

캐시를 업데이트하는 것은 캐시를 삭제하는 것에 비해 두 가지 단점이 있습니다:

당신이 작성한 캐시 값이 복잡한 계산을 거쳐 얻어지는 경우. 캐시가 자주 업데이트되면 성능이 낭비됩니다.
데이터베이스 쓰기 시나리오가 많고 데이터 읽기 시나리오가 적은 경우 데이터를 읽기 전에 업데이트되는 경우가 많아 성능도 낭비됩니다(실제로 쓰기가 많은 시나리오에서는 캐싱이 최선의 솔루션이 아닙니다). 가성비)