이중 쓰기 일관성은 데이터베이스의 데이터를 업데이트할 때 Redis의 데이터도 동기식으로 업데이트되어야 함을 의미합니다. Redis를 사용하여 데이터를 읽는 프로세스입니다. 사용자가 데이터에 액세스하면 먼저 캐시에서 데이터를 읽습니다. 캐시에 데이터가 없으면 캐시에 있는 데이터가 사용자에게 직접 반환됩니다. 캐시에 있는 경우 데이터베이스를 먼저 쿼리하고 쿼리된 데이터를 캐시에 저장한 다음 사용자에게 반환합니다.
1. 캐시를 먼저 업데이트한 다음 데이터베이스를 업데이트하세요
2. 데이터베이스를 먼저 업데이트한 다음 캐시를 업데이트하세요
3. 데이터베이스를 업데이트하세요
4 , 데이터베이스를 먼저 업데이트한 후 캐시를 삭제하세요
1. 캐시를 먼저 업데이트한 후 데이터베이스를 업데이트하세요
문제는 캐시가 성공적으로 업데이트되었지만 데이터베이스 업데이트가 실패하면 캐시가 손상됩니다.
2 먼저 데이터베이스를 업데이트한 다음 캐시를 업데이트하세요.
동시성이 높으면 다음과 같은 상황이 발생할 수 있습니다. 스레드 A가 데이터베이스를 업데이트했습니다. 네트워크 또는 기타 이유로 인해 스레드 A가 데이터베이스를 업데이트하지 않은 경우, 이때 프로세스 B는 데이터베이스를 업데이트하고 캐시를 업데이트합니다. 프로세스 A가 캐시를 업데이트하면 트랜잭션 손실 상황처럼 스레드 B의 캐시 업데이트가 손실됩니다
3. 캐시를 먼저 삭제한 다음 데이터베이스를 업데이트하세요
이 전략은 캐시를 피할 수 있습니다. 전략 2에서는 손실이 발생하지만 동시성이 아무리 높더라도 불일치가 발생합니다. 예를 들어 스레드 A는 쓰기 작업을 수행합니다. 먼저 캐시를 삭제하고 데이터베이스 업데이트를 준비합니다. 이때 데이터베이스를 쿼리하고 쿼리된 이전 값을 캐시에 저장합니다. 그런 다음 스레드 A는 데이터베이스 업데이트가 완료된 후 다시 데이터베이스와 캐시가 일치하지 않게 됩니다. 해결 방법: A만 다시 스레드하면 됩니다. 데이터베이스 업데이트를 완료한 후 약간의 지연을 두고 캐시를 다시 삭제합니다. 이를 지연된 이중 삭제라고도 합니다. 여기서 지연 시간은 비즈니스 읽기 작업 시간보다 커야 합니다.
4 먼저 데이터베이스를 업데이트한 다음 캐시를 삭제하세요.
동시성이 아무리 높아도 불일치가 발생합니다. 예를 들어 스레드 A가 데이터를 읽고 캐시에 쓰기를 준비하는 경우 스레드 B는 업데이트 데이터베이스에 액세스한 후 캐시가 삭제됩니다. 이때 스레드 A는 이전 값을 캐시에 씁니다. 그러나 쓰기 작업이 읽기 작업보다 오래 걸리기 때문에 이러한 일이 발생할 확률은 상대적으로 낮습니다. 해결책: 지연된 이중 삭제는 여전히 문제입니다. 캐시 삭제에 실패하면 어떻게 해야 합니까? 물론, 다시 삭제하고 루프에서 계속 삭제해야 합니까? 삭제에 실패한 후 삭제할 키를 대기열에 넣은 다음 삭제가 성공할 때까지 반복적으로 삭제를 시도할 수 있습니다.
위 내용은 mysql과 redis 간의 이중 쓰기 일관성 보장의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!