MySQL 데이터를 Redis 캐시에 동기화하는 방법

1 Mysql은 데이터를 확인한 후 Redis에 동기적으로 씁니다.

단점 1: Redis에 대한 동기 쓰기 자체가 지연이 있기 때문에 인터페이스에 지연이 발생하고 Redis 쓰기에 실패하면 다시 시도해야 합니다. 다시 시도하세요. 시간이 더 걸릴 것입니다.

단점 2: 디커플링이 없습니다. redis가 충돌하면 스레드가 직접 차단됩니다.

단점 3: 누군가가 데이터베이스인 경우 해당 Redis를 수동으로 삭제하지 않으면 동기화할 수 없지만 Redis를 삭제하는 과정도 마찬가지입니다. 시차

2 MySQL은 데이터를 확인한 후 MQ를 전송하여 소비자 스레드에서 Redis를 동기화합니다

단점 1: MQ 레이어가 많아 동기화 지연 문제가 발생할 가능성이 높다는 의미입니다.

단점 2 : MQ의 가용성을 방지해야 합니다

단점 3: 사람이 데이터베이스라면 동기화할 수 없습니다

장점 1: 인터페이스 반환 지연 문제를 크게 줄일 수 있습니다

장점 2: MQ 자체에 재시도 메커니즘, 수동 작업 필요 없음 가서 재시도 코드 작성

장점 3: 분리, Mysql 쿼리와 Redis 동기화를 서로 간섭하지 않고 완전히 분리

3 Mysql Binlog 파일 구독(다음의 도움으로 수행 가능) Canal)

CanalServer는 MysqlServer 메인 라이브러리의 Binlog 파일을 구독합니다.

Canal은 시작 시 해당 메시지 MQ(RabbitMQ, RocketMQ, Kafka)를 구성합니다. Binlog 파일을 생성하면 변경된 SQL 문을 json 형식으로 변환하여 메시지로 사용합니다. 내용은 MQ로 전송됩니다

프로젝트에서 해당 MQ를 모니터링하는 한 Binlog 변경 내용을 얻을 수 있습니다. Json 데이터에는 CURD(Clear Operation Type)와 해당 데이터가 있습니다. 해당 데이터를 redis에 동기화하기만 하면 됩니다

단점 1: Binlog를 구독하는 운하의 전체 작업 과정은 단일 스레드이므로 초고동시성에도 불구하고 성능이 뛰어나지 않을 수 있습니다. 여러 개의 Canal과 여러 Consumer를 배포할 수 있지만, 반복적인 소비 문제를 피하고 멱등성 검증을 수행해야 한다는 점에 주의가 필요합니다

장점 1: 데이터베이스를 수동으로 변경하더라도 모니터링 및 동기화됩니다.

장점 2: 비동기식 동기화 , 인터페이스 반환에 추가 지연은 없습니다

4 지연된 이중 삭제

수정된 sql을 실행하기 전에 먼저 redis 데이터를 삭제하세요

업데이트 sql을 실행하세요

일정 시간 동안 지연

redis 데이터를 다시 삭제하세요

// 延迟双删伪代码
deleteRedisCache(key);   // 删除redis缓存
updateMysqlSql(obj);        // 更新mysql
Thread.sleep(100);           // 延迟一段时间
deleteRedisCache(key);   // 再次删除该key的缓存

단점: 이 지연 시간은 제어하기 어렵습니다. 지연 시간이 얼마나 오래 지속되는지 평가하기 어렵습니다.

지연 이중 삭제를 사용하지 않는 경우 캐시를 삭제한 다음 MySQL 데이터를 수정하면 됩니다. 이 두 단계만 진행하면 어떤 문제가 발생하나요?

5. 단일 요청, 단일 스레드는 문제가 없지만 높은 동시성 및 다중 스레딩에서는 문제가 발생합니다.

6. Thread1 스레드가 데이터를 업데이트하려는 경우 Thread1 스레드는 이때 Redis를 정리합니다. 이번에는 Thread2 스레드가 왔지만 Thread1은 mysql

8 업데이트를 완료하지 않았습니다. 이때 Thread2는 mysql을 확인한 다음 발견된 데이터를 캐시

9에 기록합니다. mysql 데이터를 수정할 시간이 없었기 때문에 이때 Thread2가 찾은 데이터는 [기존 데이터]이고, Thread2는 기존 데이터를 다시 Redis에 씁니다

10 이때 Thread3 스레드가 와서 쿼리를 하게 됩니다. Redis가 데이터가 있음을 발견하면 이때 [Thread3가 오래된 데이터를 발견함]을 직접 가져와서 이전 데이터와 함께 반환하는 것이 문제입니다

11. Thread2가 이전 데이터를 다시 쓰는 것을 방지하기 위한 것입니다. 지연된 이중 삭제를 사용하면 Thread3가 Redis를 쿼리할 때 여전히 null이고 mysql

12에서 최신 데이터를 가져옵니다. 따라서 일반적인 지연 시간은 전체가 되어야 합니다. Thread2가 캐시를 검사하여 mysql 데이터를 가져오고 이를 redis에 저장하는 데 걸리는 시간은 Thread1의 지연 시간이지만 Thread2의 처리 시간은 여러 요소의 영향을 받기 때문에 얼마나 오래 걸릴지 결정하기 어렵습니다.

5 지연된 이중 쓰기

// 延迟双写伪代码
updateMysqlSql(obj);        // 更新mysql
addRedis(key);   // 再次删除该key的缓存

위 코드 결함;

높은 동시성에서 두 개의 스레드 위 코드를 동시에 실행하여 mysql을 수정하면 수정 내용이 차단되어 Redis 간의 불일치가 발생할 수 있습니다. 그리고 Mysql data
T1 스레드는 updateMysqlSql 실행을 마치고 행 잠금을 해제합니다. 이때 T2 스레드는 updateMysqlSql 및 addRedis를 실행하고, 마지막으로 T1 addRedis를 실행하면 이 상황에서는 데이터베이스가 T2의 데이터로 변경됩니다. 스레드이지만 Redis는 T1 스레드의 데이터입니다
Optimization

// 完美延迟双写伪代码
开启事务
updateMysqlSql(obj);        // 更新mysql
addRedis(key);   // 再次删除该key的缓存
提交事务

위 코드 수정:

두 줄의 코드를 하나의 트랜잭션에 넣으세요. T1이 Mysql과 Redis 실행을 마치면 T2가 실행을 시작할 수 있습니다. , 따라서 데이터 일관성을 보장합니다. 분산 잠금을 사용하는 것이 좋습니다

이중 쓰기 단점: Mysql과 Redis는 단일 스레드입니다. 성능면에서는 좋지 않으니 사용을 권장하지 않습니다

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