🌈 캐시를 사용하는 이유
나중에 요청올 결과를 미리 저장해두었다가 빠르게 서비스를 해주는 것을 의미한다. 캐시는 메모리를 사용해서 디스크 기반 데이터베이스보다 빠르게 데이터를 반환할 수 있다.

✅ 캐시 대상이 되는 데이터

• 단순한 정보
• 반복적으로 동일하게 제공되는 정보
• 정보의 변경주기가 빈번하지 않고, 단위처리 시간이 오래걸리는 정보
• 정보의 최신화가 반드시 실시간으로 이뤄지지 않아도 서비스 품질에 영향을 거의 주지 않는 정보

배치전략

대표적으로 Look aside 패턴과 Write Back 패턴이 많이 쓰인다.

Look aside Cache

반복적인 읽기에 적합
레디스에 장애가 생기더라도 DB에서 데이터를 가져올 수 있음.
Cache와 DB에 저장된 데이터가 서로 다를 수 있음.
일반적으로 가장 많이 쓰는 패턴

Write Back

모든 데이터를 캐시에 먼저 쓰고 특정 시간 마다 DB에 저장하는 방식
단점: 캐시 장애 시 데이터가 사라질 가능성
유용한 경우: 로그 저장 시 캐시에 먼저 밀어넣고 특정 시간마다 DB에 저장하는 경우

Write Through

DB에 작성할 때마다 캐시에 데이터를 추가하거나 업데이트하는 방식
캐시의 데이터를 항상 최신 상태로 유지할 수 있다.
자주 사용되지 않는 데이터까지 캐시에 저장되어 리소스 낭비와 write 작업 부하가 발생할 수 있어 TTL을 사용하여 사용되지 않는 데이터를 삭제하는것이 좋다.

Read Through

Look aside 방식과 비슷하지만 DB에서 직접 Cache Store를 업데이트 한다.

Collection

레디스는 다양한 자료구조를 지원한다. 자료구조가 Atomic 하기 대문에 Race Condition을 피할 수 있다.(발생할 가능성은 있음.)

많이 쓰이는 곳

• 인증 토큰등을 저장(Strings 또는 Hash)
• Ranking 보드(Sorted Set)
• 유저 API Limit

Strings

📌 가장 일반적인 형태로, key - value로 저장하는 형태이다.
사용법

set <key> <value>
get <key>

mset <key1> <value1> <key2> <value2> ...
mget <key1> <key2> ... <keyN>

List

처음과 끝에 데이터를 넣고 빼는 속도가 빠르지만 중간에 데이터를 삽입하거나 삭제해야 하는 경우는 사용하지 않는게 좋다.

Lpush <key> <A>
Rpush <key> <B>
Lpush <key> <C>
Rpush <key> <D, A>

-> Key: (C, A ,B, D, A)

LPOP <key>
RPOP <key>

Set

📌 데이터가 있는지 없는지 체크하는 용도이다. (특정 유저를 follow 하는 목록을 저장하는 경우 유니크한 value를 위해 사용하기 용이)

SADD <key> <value> # value가 이미 key에 있으면 추가x
SMEMBERS <key>  # 모든 value를 돌려줌
SISMEMBER <key> <value> # value가 존재하면 1, 아니면 0

Sorted Sets

📌 랭킹에 따라서 순서가 바뀌길 바랄 때
유저 랭킹 보드로 사용할 수 있음.

ZADD <key> <score> <value>

# 해당 index 범위값 모두 돌려줌
# Zrange key 0 -1  모든 범위
ZRANGE <key> <startindex> <endindex>

Zreverange <key> <startindex> <endindex>

ZrangeByscore

❗️score는 double 타입이기 때문에 값이 정확하지 않을 수 있다.

Hash

key 밑에 sub key가 존재

Hget <key> <subkey>
Hgetall <key>
Hmset <key> <subkey1> <value1> <subkey2> <value2>

주의 사항

• 하나의 컬렌션에 너무 많은 아이템을 담으면 좋지 않다. -> 10000개 이하 몇천개 수준으로 유지하는게 좋음

• Expire는 Collection의 item 개별로 걸리지 않고 전체에 대해서 걸림
  즉 해당 10000개의 아이템을 가진 Collection에 expire가 걸려있다면 그 시간 후에 10000개의 아이템이 모두 삭제.

• O(N) 관련 명령어는 주의하기

• 메모리 관리를 잘하자
  -> physical memory이상을 사용하면 문제 발생, swap이 한번이라도 발생하면 계속 swap이 일어나서 해당 메모리 page 접근시 마다 늦어진다. Maxmemory를 설정하더라도 더 사용할 가능성이 크다.

  메모리 관리

• 메모리 파편화가 발생할 수 있음.

• 큰 메모리를 사용하는 instance 하나보다는 적은 메모리를 사용하는 instance 여러개가 운영에는 안전하다.

Spring의 Caching 기능

SpringBoot기반 Redis Cache 사용법

• 스프링 부트 의존성 라이브러리 추가
• Redis 커넥션 정보 설정
• SpringBoot 메인 클래스에 캐시 사용 알려주기
• 사용한 method에 어노테이션 달아주기

Spring Cache는 AOP를 이용하여 다양한 캐시 기능을 일관성 있게 사용할 수 있도록 해준다.

• 캐시 등록 / 조회: @Cachable
  보통 메소드 단위로 적용한다. 캐시에 데이터가 없을 경우에는 메소드가 실행되어 메서드 로직을 실행한 후 캐시에 데이터를 추가하고, 캐싱 ㅔ데이터가 있으면 캐시의 데이터를 반환한다.

• 캐시 저장: @CachePut
  메서드의 로직을 실행하고 실행결과를 캐시에 저장한다.

• 캐시 삭제: @CacheEvict
  캐시 이름을 넣어주면 메서드가 실행 될 때 캐시의 내용이 제거된다. 파라미터로 allEntries는 전체 캐시를 지울지 여부를 선택할 수 있다.

  ---

  우아한 레디스 세미나 영상

  Redis란 무엇일까?

  개발자를 위한 레디스 튜토리얼