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

머리말

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읽기 요청 프로세스는 다음과 같습니다.

1. 읽을 때 캐시에 도달하면 데이터가 직접 반환됩니다.
캐시가 히트하지 않으면 데이터베이스를 읽고 데이터베이스에서 데이터를 검색하여 캐시에 넣고 동시에 응답을 반환하면 됩니다.

Cache-Aside 쓰기 프로세스

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

업데이트할 때 먼저

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

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

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

Read-Through

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

캐시에서 데이터를 읽고, 읽고 직접 반환합니다.
1. 읽을 수 없으면 데이터베이스에서 로드하여 씁니다. 그런 다음 응답을 반환합니다.

이 간단한 프로세스는

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

Read-Through는 실제로

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

Write-Through

Write-Through 모드에서는 쓰기 요청이 발생하면 캐시 추상화 계층도 데이터 소스 및 캐시된 데이터의 업데이트를 완료합니다.

Write Behind( 비동기 캐시 쓰기 )

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

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

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

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

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

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

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

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

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

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

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

이중 쓰기의 경우 데이터베이스나 캐시를 먼저 가동해야 할까요?

캐시 제외 캐시 모드에서 일부 친구들은 요청을 작성할 때 왜 Cache-Aside缓存模式中，有些小伙伴还是有疑问，在写入请求的时候，为什么是先操作数据库呢？为什么不先操作缓存呢？

假设有A、B两个请求，请求A做更新操作，请求B做查询读取操作。

1. 线程A发起一个写操作，第一步del cache
2. 此时线程B发起一个读操作，cache miss
3. 线程B继续读DB，读出来一个老数据
4. 然后线程B把老数据设置入cache
5. 线程A写入DB最新的数据

酱紫就有问题啦，缓存和数据库的数据不一致了。缓存保存的是老数据，数据库保存的是新数据。因此，Cache-Aside데이터베이스를 먼저 작동

하는지 질문합니다. 왜

캐시를 먼저 운영하면 안 되나요

?

A와 B라는 두 가지 요청이 있다고 가정해 보겠습니다. A는 업데이트 작업을 수행하도록 요청하고 B는 쿼리 및 읽기 작업을 수행하도록 요청합니다.

스레드 A 쓰기 작업 시작, 첫 번째 단계는 캐시 삭제

이때 스레드 B가 읽기 작업을 시작하고 캐시 누락

1. 스레드 B는 계속해서 DB를 읽고 이전 데이터를 읽습니다
2. 그런 다음 스레드 B는 이전 데이터를 설정합니다. 캐시에 데이터
3. 스레드 A가 최신 데이터를 DB

에 씁니다. Jiang Zi에 문제가 있습니다. 캐시와 데이터베이스의 데이터가 일치하지 않습니다. 캐시는 오래된 데이터를 저장하고, 데이터베이스는 새로운 데이터

를 저장합니다. 따라서 Cache-Aside 캐싱 모드는 캐시를 먼저 작동하는 대신 데이터베이스를 먼저 작동하도록 선택합니다.

캐시 지연 이중 삭제

어떤 친구들은 데이터베이스를 먼저 운영할 필요 없이

캐시 지연 이중 삭제

전략을 사용하면 된다고 말할 수도 있습니다. 지연된 이중 삭제란 무엇입니까?

캐시를 먼저 삭제

한 다음 데이터베이스를 업데이트하세요. 잠깐(예: 1초) 잠자기 상태에서 캐시를 다시 삭제하세요.

잠깐 잠드는 데 보통 얼마나 걸리나요? 모두 1초인가요?

이 대기 시간 = 비즈니스 로직 데이터를 읽는 데 걸리는 시간 + 수백 밀리초. 읽기 요청이 종료되었는지 확인하기 위해 쓰기 요청은 읽기 요청으로 인해 발생할 수 있는 캐시된 더티 데이터를 삭제할 수 있습니다.
2. 캐시 삭제 재시도 메커니즘
3. 지연 이중 삭제
4. 이든, 데이터베이스를 먼저 작동시킨 후 캐시를 삭제하는
Cache-Aside
5. 이든, 캐시 삭제의 두 번째 단계가 실패하면 삭제 실패로 이어집니다. 더티 데이터~

삭제가 실패하면 여러 번 삭제하여 캐시 삭제가 성공했는지 확인하세요~ 따라서

삭제 캐시 재시도 메커니즘

쓰기 요청을 도입하여 데이터베이스를 업데이트할 수 있습니다

몇 가지 이유로 캐시 삭제에 실패했습니다
삭제에 실패한 키를 메시지 큐에 넣습니다

🎜메시지 큐에서 메시지를 소비하고 삭제할 키를 얻습니다.🎜🎜캐시 삭제 작업을 다시 시도하세요🎜🎜🎜biglog를 비동기적으로 읽습니다. 캐시 삭제🎜🎜삭제 다시 시도 캐시 메커니즘은 괜찮습니다. 즉, 많은 비즈니스 코드 침입이 발생할 것입니다. 실제로 데이터베이스의 binlog를 통해 키🎜를 비동기식으로 제거할 수도 있습니다. 🎜🎜🎜🎜🎜 mysql을 예로 들면 Alibaba의 운하를 사용하여 binlog 로그를 수집하여 MQ 대기열로 보낸 다음 ACK 메커니즘을 통해 업데이트 메시지를 확인 및 처리하고, 캐시를 삭제하고, 데이터 캐시 일관성을 보장할 수 있습니다. 🎜추천 학습: "🎜Redis 비디오 튜토리얼🎜》🎜🎜

위 내용은 Redis와 MySQL 간의 이중 쓰기 일관성을 보장하는 방법은 무엇입니까? (메이투안 에르미안)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!