일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
Tags
- db
- it
- ubuntu
- Spring Batch
- tool
- Gradle
- linux
- MySQL
- java
- Spring Boot
- ReactJS
- jenkins
- elasticsearch
- php
- Design Patterns
- javascript
- IntelliJ
- JVM
- jsp
- redis
- Oracle
- devops
- AWS
- Spring
- Git
- Web Server
- 요리
- 맛집
- laravel
- springboot
Archives
- Today
- Total
아무거나
Cache 적용 패턴 및 관리 전략 본문
반응형
Cache 적용 패턴 및 관리 전략
읽기 캐시 전략
- Cache-Aside
- 캐시는 데이터베이스와 직접 연결되지 않고, 애플리케이션이 주체가 되며 보편적으로 많이 사용되는 캐시 전략,
읽기 요청에 적합
- 방식
(1) 캐시에 데이터가 존재하는지 확인
(2) 데이터가 존재하면 캐시 데이터 반환
(3) 데이터가 존재하지 않으면 애플리케이션에서 DB 에 데이터 요청 후 캐시에 저장하고 데이터를 반환
- 캐시는 데이터베이스와 직접 연결되지 않고, 애플리케이션이 주체가 되며 보편적으로 많이 사용되는 캐시 전략,
- Read-Through
- 애플리케이션이 캐시를 직접 바라본다. 즉, 캐시가 주 데이터스토어로 인식되며 데이터베이스로 동기화하는 몫은 캐시에 위임,
읽기 요청에 적합
- 최초 호출 시 캐시에 데이터가 없으므로 첫 요청시 캐시가 갱신되게 대응 (Ex: Cache Warm up 스케쥴 작업 등..)
- 방식
(1) 캐시에 데이터 요청
(2) 캐시에 데이터가 있으면 캐시 데이터 반환
(3) 캐시에 데이터가 없으면 DB 에서 조회한 후 캐시에 저장 후 캐시 데이터 반환
- 애플리케이션이 캐시를 직접 바라본다. 즉, 캐시가 주 데이터스토어로 인식되며 데이터베이스로 동기화하는 몫은 캐시에 위임,
쓰기 캐시 전략
- Write-Through
- Read-Through 와 마찬가지로 캐시가 주 데이터스토어의 역할을 수행하며 데이터베이스로 동기화하는 몫은 캐시에 위임된다. 캐시와 데이터를 모두 기록하기 때문에 신뢰성이 높아지며 장애발생시 데이터 유실할 가능성을 낮춰주나 캐시와 데이터베이스 두 곳에 모두 기록해야하므로 쓰기 레이턴시가 증가하는 단점이 있다. 또한
동기화까지 완료한 후에 데이터를 반환하기 때문에 캐시를 항상 최신 상태로 유지할 수 있으나, 이후에 읽히지 않을 데이터도 넣어두는 리소스 낭비가 발생할 수 있다.
- 방식
(1) 캐시에 데이터를 추가하거나 업데이트
(2) 캐시가 DB 에 동기식으로 데이터 갱신
(3) 캐시 데이터를 반환
- Read-Through 와 마찬가지로 캐시가 주 데이터스토어의 역할을 수행하며 데이터베이스로 동기화하는 몫은 캐시에 위임된다. 캐시와 데이터를 모두 기록하기 때문에 신뢰성이 높아지며 장애발생시 데이터 유실할 가능성을 낮춰주나 캐시와 데이터베이스 두 곳에 모두 기록해야하므로 쓰기 레이턴시가 증가하는 단점이 있다. 또한
- Write-Around
- 쓰기 요청이 캐시를 거치지 않고, 데이터베이스에 직접 전달된다. 캐시에 데이터가 저장되는 시점은 캐시에 요청이 되고, miss 발생시 읽은 데이터만 캐시에 로딩되므로
기록하는 데이터가 자주 사용되지 않을 경우에 적합, 그러나 캐시가 Expire 되기 전까지 DB 와 다른 데이터를 갖고 있는 단점이 있음
- 방식
(1) 데이터 추가/업데이트 요청이 들어오면 DB 에만 데이터 반영
(2) 쓰기 작업에서 캐시는 건들지 않고 읽기 작업 시 Cache Miss 가 발생하면서 캐시에 업데이트 됨
- 쓰기 요청이 캐시를 거치지 않고, 데이터베이스에 직접 전달된다. 캐시에 데이터가 저장되는 시점은 캐시에 요청이 되고, miss 발생시 읽은 데이터만 캐시에 로딩되므로
- Write-Behind (Write-Back)
- 쓰기 요청은 캐시까지만이고, 별도의 서비스등을 통해 캐시의 내용이 나중에 데이터베이스로 동기화 된다. (async), 캐시의 flush 정책(LRU, FIFO, LIFO 등) 에 따라 데이터가 데이터베이스로 저장된다.
쓰기 요청이 많은 경우에 적합하다. (데이터를 모아놓았다가 한번에 DB 에 업데이트 하므로 쓰기비용을 절약할 수 있음) 단, 데이터를 모아뒀다가 한 번에 기록하므로 그 사이에 장애가 발생하면 데이터 유실이 발생
- 방식
(1) 캐시에 데이터를 추가하거나 업데이트
(2) 캐시 데이터 반환
(3) 캐시에 있던 데이터는 이후에 별도 서비스 (이벤트 큐 등) 을 통하여 DB 에 업데이트
- 쓰기 요청은 캐시까지만이고, 별도의 서비스등을 통해 캐시의 내용이 나중에 데이터베이스로 동기화 된다. (async), 캐시의 flush 정책(LRU, FIFO, LIFO 등) 에 따라 데이터가 데이터베이스로 저장된다.
- Refresh Ahead
- 자주 사용되는 데이터에 대해 캐시가 만료되기 전에 미리 TTL 을 갱신한다. (캐시 MISS 발생 후 다시 데이터를 로딩하는 낭비를 막을 수 있음)
참고
반응형
'Data Store > Redis' 카테고리의 다른 글
Redis 관련 내용 정리 (3) | 2024.10.05 |
---|---|
자주 쓰는 명령어 정리 (0) | 2019.12.24 |
redis 서버 설정 redis.conf (0) | 2019.12.24 |
redis 서버 설정 redis.conf (0) | 2019.12.22 |
자주 쓰는 명령어 정리 (0) | 2019.12.22 |
Comments