Redis

설치 운영

우분투에서 설치

sudo apt-get update
sudo apt-get install redis-server

 

트러블슈팅

docker안에서 host의 redis에 접근하도록 하기

실행할때 다음처럼 --network host만 붙여주면 된다.

#!/bin/bash

PORT=$1

docker run \
  --network host \
  -e SPRING_APPLICATION_JSON='{"server":{"port":'"$PORT"'}}' \
  -p $PORT:$PORT \
  auth-service

 

설계관점

 

유사한 목적(“캐시-미스 시 DB에서 데이터 가져와 캐시에 채우기”)을 갖고 있지만, 구현 주체와 흐름 제어가 다릅니다.

 

Read-Through vs Write Through

둘다 캐시라이브러리를 쓰는 형태

 

항목	Read-Through	Write-Through
읽기(Read)	애플리케이션이 cache.get(key)만 호출 – miss 시 캐시 라이브러리가 DB에서 가져와 자동으로 채워 줌	애플리케이션이 cache.get(key)만 호출 – miss 시 캐시→DB 채우기(읽기 방식은 동일)
쓰기(Write)	애플리케이션이 DB에 직접 쓰고, 캐시는 별도 무효화 로직(예: Cache-Aside) 필요	애플리케이션이 cache.put(key, value) 호출 – 캐시에 먼저 쓰고, 라이브러리가 동기적으로 DB에도 써 줌
앱 코드 관점	• Read: cache.get(key) • Write: db.save(...) + 별도 cache.del(key)	• Read: cache.get(key) • Write: cache.put(key, value) (내부에서 DB 쓰기까지 수행)

 

• Read-Through는 애플리케이션이 캐시에 get()만 호출하면 되고,
  쓰기는 보통 DB에 직접 쓰고 캐시 무효화를 따로 처리
• Write-Through는 애플리케이션이 읽을 땐 get(), 쓸 땐 put()을 호출하며,
  put()이 캐시와 DB 쓰기를 동기적으로 처리해 줌

 

Cache-Aside vs Read-Through

 

항목	Cache-Aside	Read-Through
핵심 아이디어	앱이 직접 “캐시 꺼내→DB 가져와→캐시 세팅”	캐시 라이브러리가 “get() 호출만으로 내부에서 DB 조회→캐시 세팅”
누가 제어하나	애플리케이션 코드	캐시 미들웨어 / 프레임워크
코드 호출 방식	cache.get → miss? db.query → cache.set	cache.get 만 호출
쓰기(무효화)	db.update 후 애플리케이션이 cache.del	보통 Write-Through와 결합해 cache.put→db.write
자동화 수준	수동 로직(직접 구현)	캐시 솔루션에 내장 (투명하게 작동)

 

결론:

• 목적은 같지만,
• Cache-Aside는 “앱이 직접 관리”
• Read-Through는 “라이브러리가 대신 관리”

 

 

Write-Through vs Write-Back

 

항목	Write-Through	Write-Back
핵심 아이디어	캐시에 쓰면 즉시 동기적으로 DB에도 쓰기	캐시에 먼저 쓰고, 나중에 배치나 트리거로 DB에 반영
쓰기 흐름	1. cache.put(key, value) 호출 2. 캐시 저장 완료 후 3. 즉시 DB 쓰기	1. cache.put(key, value) 호출 2. 캐시만 업데이트 3. 일정 시점에 Dirty-entry를 모아서 DB 쓰기
DB 쓰기 타이밍	동기적, 쓰기 호출 시점에 바로 반영	비동기적, 지연(예: TTL, 배치, evict 시점)에 반영
데이터 일관성 보장	강력(쓰기 직후 DB와 캐시 일치)	약함(아직 DB에 반영되지 않은 쓰기 데이터가 캐시에만 존재할 수 있음)
쓰기 레이턴시	상대적으로 높음(캐시＋DB 두 번 쓰기)	상대적으로 낮음(한 번만 캐시에 쓰기)
장애 복구 & 내구성	쓰기 실패 시 즉시 예외 처리 가능	캐시 장애나 장애 복구 시 Dirty 데이터 유실 위험
캐시 오염(Dirty) 관리	없음	“Dirty bit” 관리 필요 → evict, 주기적 flush 로직 구현
구현 복잡도	낮음(동기 쓰기만 구현)	높음(Dirty 식별·스케줄·재시도 로직 등 추가)
적합한 사용 사례	• 데이터 일관성이 최우선일 때 • 쓰기 빈도가 낮거나 허용 가능한 레이턴시일 때	• 쓰기 빈도가 매우 높고, 약간의 지연 반영을 허용할 때 • DB 부하 완화가 급선무일 때