wiki Cache Aside(Lazy Loading)
- 캐시 미스가 발생하면, 어플리케이션에서 원본을 조회해 캐시를 채우고 반환합니다.
- 만약 수많은 요청들이 동시에 캐시 미스를 확인하고 캐시 적재를 시도하게 되면 캐시 스탬피드 현상이 일어나게 됩니다.
- 원본과 데이터 불일치 가능성이 있습니다.
Read Through
- 캐시 미스가 발생하면, 캐시 서비스에서 원본을 조회해 캐시를 채웁니다.
- 원본과 데이터 불일치 가능성이 있습니다.
원본과의 데이터 불일치를 해소할 수 있는 캐싱 전략
Write Through
- 변경이 생기면, 캐시 서비스에서 캐시를 원본과 함께 변경합니다.
- 쓰기 지연 시간이 증가할 수 있습니다.
AWS의 DynamoDB Accelerator(DAX)는 write through, read through 방식을 함께 사용합니다.
write through 방식이지만 DAX는 분산 캐시이기 때문에, 클러스터가 액세스한 노드에 따라 서로 다른 값을 수신할 수 있습니다. (링크)
Write Behind (Write Back) 방식
- 원본이 변경되면, 캐시를 먼저 수정하고 이후 비동기로 묶어서 원본을 수정합니다.
- 캐시에서 오류가 발생하면 데이터를 영구 소실할 수 있습니다.
오류가 발생해도 복구가 가능할 수 있는 Redis
fork() 시스템 호출을 이용해 메인 Redis 프로세스와 동일한 (공유된) 물리 메모리에 맵핑된 가상 메모리를 가진 새로운 프로세스를 생성합니다. 이 보조 프로세스는 메모리의 내용을 디스크에 덤프합니다.
위와 같이 redis에는 저장된 데이터를 특정 주기로 디스크에 영속화하는 기능이 있기 때문에, 서버에 치명적인 문제가 발생하더라도 복구 가능할 수 있습니다.
Cache Invalidation 방식
- 원본이 변경되면, 캐시를 만료시킵니다.
(실무에서 사용했던) Django의 cachalot 라이브러리는 cache invalidation 방식
- cachalot 라이브러리는 개별 객체가 아닌 테이블을 무효화시키기 때문에, 콜드 테이블이거나 분당 50회 미만으로 업데이트 되는 핫 테이블의 경우에 적합합니다.
