Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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
- 다중 서버
- 예외처리
- 백준
- thundering herd
- 비관적 락
- expired key
- 이진탐색
- ddl-auto
- 트라이 자료구조
- prg패턴
- 타임아웃
- queue
- 벌크헤드패턴
- 슬라이스 테스트
- 자바
- session인증
- Stack
- 낙관적 락
- 베타락
- 이분탐색
- id생성
- 캐시 스탬피드
- BFS
- java
- Entity Manager
- 스택
- DP
- JPA
- 외부 서비스 장애
- 알고리즘
Archives
- Today
- Total
Coding 01
캐싱 본문
캐싱은 자주 사용하는 데이터를 빠르게 접근할 수 있는 임시 저장소에 보관하여 성능을 향상하는 기술이다.
캐싱 전략으로는 Cache-Aside(Lazy loading), Write-Through, Write-Behind(Write-Back), Read-Through가 있다.
Cache-Aside(Lazy Loading)
가장 기본적인 캐싱패턴으로, 데이터를 찾을 때 먼저 캐시를 확인하고 히트시 캐시에서 데이터를 불러오고, 미스 시 DB에서 조회 후 캐시에 저장한다.
필요한 데이터만 캐시에 저장되니 효율적으로 사용가능하지만, 캐시 미스 시 조회하는 지연 시간이 발생한다.
Write-Through
데이터를 쓸 때 DB와 캐시를 동시에 업데이트해준다. 원본 데이터에 변경이 생긴 경우, 매번 캐시에 그 데이터를 찾아 함께 변경한다.
캐시와 DB에 일관성이 생기지만, 쓰기 작업이 느리다.
Write-Behind (Write-Back)
데이터를 먼저 캐시에 쓰고, 나중에 배치로 DB에 저장한다.
쓰기가 매우 빠르지만, 데이터 유실 위험이 있다.
Read-Through
캐시가 직접 DB에서 데이터를 로드해서 관리한다.
Cache-Aside와 비슷하지만, 애플리케이션이 아닌 캐시가 데이터 로딩을 한다.
코드가 단순해질 수 있지만, 캐시 구현이 복잡해진다.
'기술면접' 카테고리의 다른 글
ACID (0) | 2025.01.23 |
---|---|
REST(Respresentational State Transfer) (0) | 2025.01.22 |
동시성(Concurrency)과 병렬성(Parallelism) (0) | 2025.01.20 |
로드 밸런싱 (0) | 2025.01.17 |
다중 서버 환경에서 세션 기반 인증 방식의 문제 (0) | 2025.01.16 |