[Chapter 10] 레디스 EXPIRED를 초과한 데이터는 어떤 원리로 지워질까?

[Irisation23]

생각보다 프로그래밍을 하다보면, 이처럼 시간을 기준으로 삼아 여러 행위를 하는 경우가 많이 있다고 생각이 됩니다.

예로 들면 카카오의 선물하기 1년 후 환불정책 등등을 예로 들어보겠습니다.
e.g) A가 2023년 11월 25일 22:21에 B에게 10,000짜리 선물 함 이때 기준은 1년이 2024년 11월 25일 22:21에 해당 상품이 환불이 되는 것인지?

위의 예시 처럼 시점을 잡고, 다음 이벤트(시간이 만료되어 환불금을 B에게 지급함)를 발생시키는 행위는 내가 실행한 어떤 행위(선물)가 차후에 일어날 일(환불)을 통제한다라고 생각이 됩니다.

책의 예제에 다음과 같은 코드가 있습니다.

public void put(HotelCacheKey key, HotelCacheValue value) {
  hotelCacheOperation.set(key, value, Duraion.ofSeconds(24 * 60 * 60);
}

여기서 말하고 있는 Duraion.ofSeconds(24 * 60 * 60) 이라는 설정은

Q. 내가 데이터를 생성한 시점(한국의 시간) 의 시간인지? 아니면 표준시(e.g 영국 시간 등등)를 적용한것인지? 아니면 내 로컬 컴퓨터에 설정한 시간인지? 등등이 궁금합니다.

[corock]

우선 책에서 소개한 ValueOperations 인터페이스의 Duration.ofSeconds(24L * 60L * 60L) 위치는 timeout 에 해당하고,
이 timeout 은 실제로 레디스 데이터베이스에 데이터를 생성한 시점부터 일 겁니다. (cf. https://redis.io/commands/setex)

그런데 이 discussion 에서 예시로 나온 카카오의 선물하기 환불 정책의 경우, 구현한 기술 셋과 정책에 따라 무궁무진할 겁니다.
책의 예시를 백분 활용해 볼 수 있는 경우는 아래와 같은 조건이 있을 때 정도 같습니다.

1. 레디스를 이용한다.
2. 마침 정책도 데이터를 생성한 시점으로부터 정확히 1년이 지난 시점에 환불한다.
3. 기간을 연장할 수 없다.

한편, 레디스를 사용하지 않는(?) 곳이 있을 수도 있고, 어떤 곳은 일자를 기준으로 배치 정책으로 풀어내는 곳도 있을 겁니다.
댓글 작성하면서 제일 깔끔한 건 선물하기로 유명한 곳 중 하나를 골라 가서 경험해 보는 게 아닐까 라는 생각이 드네요 :)

[JoisFe]

넵 관점이 특정 시각 부터가 아니라
그냥 데이터 넣어진 시점 부터 얼마 후

[Irisation23]

금주 Check Point

• 레디스로 처리할 수도 있지만, RDB를 배치 처리할 수 있음
• 무분별한 배치는 관리가 어려울 수 있음 (배치를 많이 돌린다면 전문팀이 구성되어야 할 수 있다고 생각함)