쓰기를 캐시에만 반영하고 즉시 응답한 뒤, DB 기록은 나중에 모아서 하는 전략. Write-Behind라고도 한다.
동작
- ① 캐시에 쓰고 곧바로 완료 응답 ← 여기서 사용자 대기 끝
- ② 해당 항목을 dirty(더러움) 로 표시
- ③ 일정 시간·개수마다 모아서 DB에 반영
dirty 플래그는 "캐시에는 있는데 DB에는 아직 없는 값"이라는 표시다. CPU 캐시에서 그대로 온 개념이다.
왜 빠른가 — 쓰기 병합
같은 키에 여러 번 쓰면 마지막 값 하나만 DB로 나간다.
| 조회수 +1 을 1초에 1000번 | → | 캐시에서 1000번 증가 |
|---|---|---|
| → | DB에는 1번 UPDATE (1000 증가) | |
| DB 쓰기가 1000분의 1로 줄어든다. 이것이 write coalescing이다. |
대가 — 유실
DB에 내려가기 전에 캐시가 죽으면 그 사이 쓰기는 사라진다.
그래서 둘 중 하나를 택한다.
- 유실을 감당할 수 있는 데이터에만 쓴다 — 조회수, 좋아요 수, 최근 접속 시각
- 내구성 장치를 붙인다 — Redis AOF(모든 명령을 파일에 기록), 복제
AOF는 appendfsync everysec이 기본이라 최대 1초치는 유실될 수 있다.
always로 두면 안전하지만 매 쓰기마다 디스크에 동기화해 느려진다.
언제 쓰나
쓰기가 매우 빈번하고 약간의 유실을 허용할 수 있을 때. 결제·잔액처럼 유실이 치명적인 데이터에는 절대 쓰지 않는다.
실무에서 흔한 절충
카운터는 Redis에서 INCR (Write-Back 성격)
↓ 1분마다
배치가 DB에 동기화
↓
DB가 정합성의 최종 기준
중간에 죽어도 최대 1분치만 잃고, 다음 배치가 캐시의 현재값으로 덮어쓴다.
읽기 정책과 짝짓기
Write-Back은 보통 Read-Through(캐시가 미스 시 스스로 DB에서 읽어옴)와 함께 쓴다. 애플리케이션은 캐시만 상대하고 DB 접근은 캐시 계층이 전담하는 구조가 된다.