[BE-433] [BE-445] [BE-460] [BE-465] 슬라이드 배너, 다른사람이 함께본 식당 Redis Cacheable 연동

[hmJin11]

이슈

BE-433
BE-445
BE-460
BE-465

내용

슬라이드배너, 다른사람이 함께본 식당 Redis Cacheable 연동

해당 API들 파라미터가 있어서 이 부분은 Job으로 할 때 파라미터 별로 db 전체를 조회해서 갱신 해줘야 함.
이러한 경우 어떻게 하면 좋을지 회의에서 의논해보면 좋을것 같음.
일단 sync = true 로 여러 요청이 들어와도 첫 사용자만 조회해서 캐시로 갱신해주는 로직으로 구현하였음.

@Cacheable(
            value = "AlsoViewedStoreList",
            key = "'alsoViewedStoreList_' + #id",
            cacheManager = "contentCacheManager",
            sync = true // Cache Stampede 방지 -> 단일 스레드로 직렬화 해서 여러 요청이 동시에 들어와도 DB 한번만 조회
    )

1️⃣ sync = true 활용

• @Cacheable(sync = true)는 캐시 miss 시 DB 조회를 단일 스레드로 직렬화해 줍니다.

• 즉, 동시에 여러 요청이 들어와도 DB는 한 번만 조회 → 나머지는 캐시 완료 후 반환

• 장점:

  • 코드가 간단

  • 별도 Job이나 분산 락 필요 없음

  • 실시간 변경이 반영된 최신 데이터 조회 가능

• 단점:

  • DB 조회가 오래 걸리면 요청 대기 시간이 늘어남

  • 완전히 초기 캐시(예: 서비스 시작 후)에는 첫 요청만 느릴 수 있음

---

2️⃣ Job 활용 실무

• Job은 캐시 warm-up, 정기 갱신, TTL 만료 대비용으로 많이 사용

• 예시:

  • 배너는 매일 새벽 5시에 DB를 조회해서 모든 placement 캐시 미리 채워둠

  • 사용자가 처음 접속할 때 “첫 조회 느림” 문제 방지

• 장점:

  • 초기 요청 시 DB hit 없음

  • TTL이 짧은 경우에도 항상 캐시가 존재

• 단점:

  • Job 코드/스케줄 관리 필요

  • 데이터가 작으면 오버헤드가 될 수 있음