Redis 캐시 및 MySQL 데이터 일관성 방법

수요원인

동시성이 높은 비즈니스 시나리오에서 데이터베이스는 대부분의 경우 동시 사용자 액세스에 대한 가장 취약한 링크입니다. 따라서 요청이 MySQL 등의 데이터베이스에 직접 접근하는 대신 Redis에 먼저 접근할 수 있도록 Redis를 이용하여 버퍼링 작업을 수행해야 합니다.

이 비즈니스 시나리오는 주로 Redis 캐시에서 데이터를 읽는 문제를 해결합니다. 비즈니스 작업은 일반적으로 아래 그림의 프로세스에 따라 수행됩니다.

일반적으로 캐시 단계를 읽는 데에는 문제가 없지만, 일단 데이터 업데이트(데이터베이스 및 캐시 업데이트)가 포함되면 캐시(Redis)와 데이터베이스(MySQL) 간의 데이터 일관성 문제가 발생하기 쉽습니다.

MySQL 데이터베이스를 먼저 작성한 다음 Redis 캐시를 삭제하거나, 캐시를 먼저 삭제하고 데이터베이스에 쓰는 경우 데이터 불일치가 발생할 수 있습니다. 예를 들어보세요:

1. Redis 캐시가 삭제되고 MySQL 데이터베이스에 쓸 시간이 되기 전에 다른 스레드가 읽기 시작하여 캐시가 비어 있음을 발견하면 이때 데이터베이스에서 데이터를 읽어 캐시에 씁니다. , 캐시에 더티 데이터가 포함되어 있습니다.

2. 라이브러리가 먼저 작성되고 캐시가 삭제되기 전에 라이브러리를 작성하는 스레드가 충돌하고 캐시가 삭제되지 않으면 데이터 불일치도 발생합니다.

쓰기와 읽기가 동시적이고 순서를 보장할 수 없기 때문에 캐시와 데이터베이스 간에 데이터 불일치가 발생합니다.

여래가 해결해 주나요? 다음은 비즈니스 및 기술 비용을 기준으로 선택한 두 가지 솔루션입니다. 먼저 쉬운 솔루션과 어려운 솔루션이 있습니다.

​캐싱 및 데이터베이스 일관성 솔루션

1. 첫 번째 옵션: 지연된 이중 삭제 전략 채택

라이브러리 쓰기 전후에 redis.del(키) 작업을 수행하고 합리적인 시간 초과를 설정합니다.

의사 코드는 다음과 같습니다

​공개 무효 쓰기(문자열 키, 객체 데이터){

redis.delKey(키);

​db.updateData(데이터);

Thread.sleep(500);

redis.delKey(키);

}

2. 구체적인 단계는 다음과 같습니다:

1) 캐시를 먼저 삭제하세요

2) 데이터베이스를 다시 작성합니다

3) 500밀리초 동안 잠을 자세요

4) 캐시를 다시 삭제하세요

그렇다면 이 500밀리초는 어떻게 결정되며, 얼마나 오랫동안 절전 모드로 유지되어야 할까요?

시간이 많이 걸리는 프로젝트의 데이터 읽기 비즈니스 로직을 평가해야 합니다. 이는 읽기 요청이 종료되고 쓰기 요청이 읽기 요청으로 인해 캐시된 더티 데이터를 삭제할 수 있도록 하는 것입니다.

물론 이 전략에서는 Redis와 데이터베이스 마스터-슬레이브 간의 시간 소모적인 동기화도 고려해야 합니다. 데이터 쓰기를 위한 최종 대기 시간: 데이터 비즈니스 로직을 읽는 데 걸리는 시간에 수백 밀리초를 추가합니다. 예: 1초 동안 잠을 자세요.

3.캐시 만료 시간 설정

이론적으로 캐시 만료 시간을 설정하는 것은 최종 일관성을 보장하는 솔루션입니다. 모든 쓰기 작업에는 데이터베이스가 적용됩니다. 캐시 만료 시간에 도달하는 한 후속 읽기 요청은 자연스럽게 데이터베이스에서 새 값을 읽고 캐시를 채웁니다.

4. 이 플랜의 단점

이중 삭제 전략 + 캐시 시간 초과 설정을 결합하면 최악의 시나리오는 시간 초과 기간 내에 데이터가 일관되지 않고 요청 쓰기 시간도 늘어나는 것입니다.

2. 두 번째 해결 방법: 비동기 업데이트 캐시(binlog 구독을 기반으로 한 동기화 메커니즘)

1. 전반적인 기술 아이디어:

MySQL binlog 증분 구독 소비 + 메시지 큐 + redis에 대한 증분 데이터 업데이트

1) Redis 읽기: 핫 데이터는 기본적으로 Redis

에 있습니다. 2) MySQL 작성: 추가, 삭제, 수정이 모두 MySQL에서 이루어집니다

3) Redis 데이터 업데이트: Redis

로 업데이트하기 위한 MySQ 데이터 작업 binlog 2.Redis 업데이트

1) 데이터 작업은 주로 두 가지 블록으로 나뉩니다.

하나는 전체 볼륨입니다(모든 데이터를 Redis에 동시에 쓰기)

하나는 증분(실시간 업데이트)

여기서 말하는 increment는 mysql의 변경 데이터를 업데이트, 삽입, 삭제하는 것을 의미하는 increment이다.

2) binlog를 읽은 후 이를 분석하고 메시지 큐를 사용하여 각 스테이션의 Redis 캐시 데이터를 푸시하고 업데이트합니다.

이러한 방식으로 MySQL에서 새로운 쓰기, 업데이트, 삭제 및 기타 작업이 발생하면 binlog 관련 메시지가 Redis로 푸시될 수 있으며 Redis는 binlog의 레코드를 기반으로 Redis를 업데이트합니다.

실제로 이 메커니즘은 MySQL의 마스터-슬레이브 백업 메커니즘과 매우 유사합니다. 왜냐하면 MySQL의 마스터-슬레이브 백업도 binlog를 통해 데이터 일관성을 달성하기 때문입니다.

여기에서는 canal(Alibaba의 오픈 소스 프레임워크)을 조합하여 사용할 수 있으며 이를 통해 MySQL의 binlog를 구독할 수 있습니다. Canal은 mysql의 슬레이브 데이터베이스의 백업 요청을 모방하므로 Redis의 데이터 업데이트가 동일한 효과를 얻습니다.

물론 여기에서 메시지 푸시 도구로 다른 제3자(kafka, RabbitMQ 등)를 사용하여 Redis에 업데이트를 푸시할 수도 있습니다.

위 내용은 Redis 캐시 및 MySQL 데이터 일관성 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!