프로젝트에서 사용하는 멀티 레벨 캐시는 분산 캐시 Redis+ 로컬 캐시 카페인, 1레벨 캐시로 Caffeine을, 2레벨 캐시로 Redis를 사용합니다. 프로젝트에서 데이터에 액세스한 횟수를 기록하여 핫 데이터는 로컬 캐시에, 핫하지 않은 데이터는 Redis 캐시에 배치하며, 액세스 흐름은 다음과 같습니다:
여러 수준의 캐싱을 사용하면 Redis만으로도 초당 10w의 요청을 수신할 수 있고, 로컬 캐시는 초당 수백만 개의 요청을 수신할 수 있는 Redis 캐시보다 훨씬 높은 동시성을 견딜 수 있으며, 두 수준의 캐싱을 사용하여 액세스 효율성을 크게 높일 수 있다는 이점이 있습니다.
하지만 다단계 캐싱을 사용한 후 데이터 일관성 문제가 발생합니다:
Redis 캐시 및 MySQL 데이터 불일치: 데이터 일관성을 보장하기 위해 지연된 이중 삭제를 사용하거나, 보다 정확한 데이터 일관성이 필요한 경우 Canal을 사용하여 MySQL binlog 로그를 수신하여 데이터 일관성을 보장할 수 있습니다.
분산 환경에서는 여러 애플리케이션 간의 로컬 캐싱과 MySQL의 데이터 불일치:
MQ를 사용하여 데이터 일관성을 보장할 수 있습니다..애플리케이션 1이 데이터베이스 업데이트 요청을 받으면 로컬 캐시도 업데이트하고 다른 애플리케이션이 로컬 캐시를 업데이트할 수 있도록 업데이트 MQ 브로드캐스트 메시지를 보냅니다.
핫스팟 데이터는 어떻게 저장하나요?
실제로 기록 된 데이터에 대한 액세스 횟수이며, 액세스가 매우 많은 것으로 확인되면 로컬 레코드에서 해시 맵을 사용하여 저장하고 핫 데이터를 기록한 다음 모든 서비스가 로컬 캐시에 핫 데이터가 될 것임을 알릴 수 있습니다.
