레디스 캐시 전략

1. Cache Aside

조회시 캐시 조회
실패시 DB에 조회 후 캐시에 데이터를 저장
 

2. Read Through

조회시 캐시 조회, 캐시어사이드와 비슷하지만 DB를 조회하는 주체가 다르다.
캐시 어사이드는 앱이 DB를 조회하지만 리드 스로우는 캐시가 DB를 조회하여 캐시가 커넥션을 가지고 있어야한다.
캐시가 장애나면 DB에 접근이 불가능하다 거의 쓰이지 않음
이때 캐시는 DB의 프록시역할

 

3. Write Back

저장시 캐시에 먼저 저장하고 캐시에 있는 데이터를 배치로 DB에 저장
캐시 오류 발생시 데이터 영구 소실
 

4. Write Through

저장시 캐시에 저장하고 DB에 즉시저장.
항상 동기화 되어있다. 두번의 쓰기가 일어나 빈번한 수정이 발생하면 성능 이슈 발생가능

 

5. Write Around

저장할 때 캐시에는 저장하지 않고 DB에만 저장
캐시 어사이드 전략과 자주 같이 활용 됨
데이터 불일치 일어날수있음
 

6. Cache Invalidation

데이터 수정시 캐시의 데이터 무효화
무효화 작업이 빈번하게 발생하면 성능이 저하될수 있다. 캐시 데이터가 항상 최신 상태로 유지
 

조합

1. Cache Aside +Write Around

일반적으로 가장 자주 쓰임

Cache Aside와 Write Around를 같이 쓸 때 한계점

write around 전략은 db의 데이터만 수정하기 때문에 기존에 저장된 레디스의 값과 다를 수 있다. 캐시된 데이터와 DB 데이터가 일치하지 않을 수 있다
 
 

극복방법

데이터를 수정할 때 동시에 업데이트 시키면 성능적으로 느려진다
그래서 캐시를 적용할 데이터를 선별해야함
1. 자주 조회되는 데이터
2. 잘 변하지 않는 데이터
3. 실시간으로 정확하게 일치하지 않아도 되는 데이터
 
TTL기능을 활용하여 적절한 주기로 데이터를 동기화시켜야 함
일정시간이 지나면 데이터가 캐시에서 삭제 됨. 특정 사용자가 조회하는 순간 Cache Miss가 발생되고 DB에서 새로 조회해서 레디스에 데이터를 넣는다 즉 데이터가 새롭게 갱신되는 효과가 있다.
 
캐시에 저장할 수 있는 공간이 비교적 작은것도 TTL 통해 보완가능
 
 

2. Read Through + Write Around

항상 DB에 쓰고 캐시에서 DB에서 읽어 완벽한 정합성 보장
 

3. Read Through + Write Through

항상 캐시에 먼저 쓰므로 읽을 때 최신 캐시 보장
항상 캐시에서 DB로 보내서 데이터 정합성 보장