일반적으로 데이터베이스 접근 부담을 줄이기 위해 Redis Cache를 우선적으로 사용하게 됩니다. 그러나 다음과 같은 상황도 발생합니다. 많은 수의 사용자가 시스템에 액세스하면 먼저 캐시에 쿼리를 수행하고 캐시에 데이터가 없으면 데이터베이스에 쿼리한 다음 데이터를 캐시에 업데이트합니다. 그리고 데이터베이스의 데이터가 변경된 경우 Redis로 동기화해야 합니다. 동기화 과정에서 MySQL과 Redis 간의 데이터 일관성이 보장되어야 합니다. 이 동기화 과정에서 짧은 데이터 지연이 발생하는 것은 정상입니다. 그러나 결국에는 mysql과 캐시 사이의 일관성을 보장하는 것이 필요합니다.
//我们通常使用redis的逻辑
//通常我们是先查询reids
String value = RedisUtils.get(key);
if (!StringUtils.isEmpty(value)){
return value;
}
//从数据库中获取数据
value = getValueForDb(key);
if (!StringUtils.isEmpty(value)){
RedisUtils.set(key,value);
return value;
}지연 이중 삭제 전략은 분산 시스템에서 일관성을 유지하기 위해 데이터베이스 저장 및 캐시 데이터에 대한 일반적인 전략이지만 강력한 일관성은 아닙니다. 실제로 어떤 솔루션을 사용하든 Redis의 더티 데이터 문제는 피할 수 없습니다. 이 문제를 완전히 해결하려면 동기화 잠금 및 해당 비즈니스 로직 수준을 사용하여 해결해야 합니다.
일반적으로 데이터베이스 데이터를 업데이트할 때 Redis에 캐시된 데이터를 동기화해야 하므로 일반적으로 두 가지 해결 방법을 제공합니다.
첫 번째 해결 방법: 업데이트 작업을 먼저 수행한 다음 캐시 지우기를 수행합니다.
두 번째 옵션: 먼저 캐시 삭제를 수행한 다음 업데이트 작업을 수행합니다.
그러나 이 두 솔루션은 동시 요청에서 다음과 같은 문제가 발생하기 쉽습니다
첫 번째 솔루션의 단점: 요청 1이 데이터베이스 업데이트 작업을 수행한 후 캐시 삭제가 수행되기 전에 요청 2가 들어옵니다. 이때 캐시에 있는 데이터는 아직 삭제되지 않은 오래된 데이터이므로 데이터에 문제가 발생합니다. 그러나 t1이 캐시 삭제 작업을 수행한 후에는 후속 요청에서 캐시를 쿼리할 수 없습니다. 그런 다음 이를 캐시로 업데이트합니다.
t1 스레드가 db를 먼저 업데이트합니다.
t2 스레드 쿼리가 캐시에 도달하고
t1 스레드가 db를 업데이트했는데, 5밀리초 후에 캐시가 삭제될 것으로 예상됩니다. 다른 스레드의 5밀리초 이내의 키에 대한 쿼리 캐시 결과는 여전히 이전 데이터이지만 5밀리초 이후의 쿼리 캐시 결과는 비어 있으며, 최신 db 결과가 Redis에 다시 동기화됩니다.
프로젝트 지연은 매우 흔한 일이므로 이러한 지연이 비즈니스에 미치는 영향은 실제로 매우 제한적입니다. 그런데 이런 일이 발생하고 캐시 삭제에 실패하면 어떻게 될까요?
1. 계속 재시도하세요----http 프로토콜 인터페이스에 있는 경우 인터페이스를 호출하면 응답 시간 초과가 발생합니다. 2. 또는 비동기적으로 mq를 통해 동기화합니다. 두 번째 솔루션의 단점: 요청 1이 캐시를 삭제했지만 아직 데이터 업데이트 작업을 수행하지 않은 경우 요청 2가 들어와 데이터베이스의 이전 데이터를 쿼리하고 이를 Redis에 기록하므로, 데이터베이스 및 Redis 데이터.
RedisUtils.del(key);// 先删除缓存 updateDB(user);// 更新db中的数据 Thread.sleep(N);// 延迟一段时间，在删除该缓存key RedisUtils.del(key);// 先删除缓存
위 내용은 Redis 지연 이중 삭제 전략을 사용하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
