Redis

Redis

• 데이터의 원래 소스보다 더 빠르게 액세스할 수 있는 임시 데이터 저장소
• 주로 변하지 않는 데이터, 반복적으로 액세스하는 같은 데이터를 캐시에 저장
• 단순한 key-value 구조
• In-memory 데이터 저장소
  • 서버 재시작 시 모든 데이터 유실
  • 복제 기능을 사용해도 실수 발생 시 데이터 복원 불가💀
  • Redis를 캐시 이외의 용도로 사용한다면 적절한 데이터 백업이 필요
• 데이터를 영구 저장하는 방법
  • RDB
    • 바이너리 파일 형태로 저장된다.
    • 저장 당시 메모리에 있는 데이터 그대로를 사진 찍듯이 snapshot 방식으로 저장
    • 자동 👉 redis.conf 파일에서 SAVE 옵션(시간 기준)
    • 수동 👉 BGSAVE 커맨드를 이용해 cli 창에서 수동으로 RDB 파일 저장
      • SAVE 커맨드는 절대 사용 ❌
  • AOF(Append Only File)
    • 모든 명령어를 다 저장
    • Redis 프로토콜 형태로 저장된다.
    • 자동 👉 redis.conf 파일에서 auto-aof-rewrite-percentage 옵션(크기 기준)
    • 수동 👉 BGREWRITEAOF 커맨드를 이용해 CLI 창에서 수동으로 AOF 파일 재작성

 

Caching Strategies

• 읽기 전략
  • Look-Aside(Lazy Loading)
    •  Redis가 죽더라도 DB에서 데이터를 가져오면 되기 때문에 서비스가 죽지 않는다.
      • ⚠️ 하지만, 갑자기 DB로 트래픽이 많이 몰릴 수 있다.
        • 이럴 때는 미리 DB에서 Cache로 데이터를 넣어주는 Cache Warming 방식을 사용할 수 있다.
    • ⭐ 기본적으로 Cache에서 데이터를 가져오고 없으면 DB에서 가져온다. 
    • Cache Miss
      • Cache에 데이터가 없으면 DB에서 가져온다.
    • Cache Hit
      • Cache에 있는 데이터를 가져온다.
• 쓰기 전략
  • Write-Around
    • DB에만 데이터를 저장
    • Cache Miss가 발생하면 Cache에 DB에 있는 데이터를 저장 ➡️ 데이터 정합성 문제
  • Write-Through
    • DB에 데이터를 저장할 때 Cache에도 저장 ➡️ 상대적으로 느린 속도, 리소스 낭비

 

 

Redis의 자료 구조

• Counting하기
  •  Strings
    • 단순 증감 연산
      • INCR / INCRBY / INCRBYFLOAD / HINCRBY / HINCRBYFLOAT / ZINCRBY
  • Bits
    • 데이터 저장공간 절약
    • 정수로 된 데이터만 카운팅 가능
  • HyperLogLogs
    • 대용량 데이터를 카운팅 할 때 적절
    • set과 비슷하지만 저장되는 용량이 12KB 고정되어 매우 작다.
    • 저장된 데이터는 다시 확인 불가능
  • Messaging하기
    • Lists
      • Blocking 기능을 이용해 Event Queue로 사용
      • 키가 있을 때만 데이터 저장 가능
        • LPUSHX / RPUSHX
        • ex) 이미 캐싱되어 있는 피드에만 신규 트윗을 저장
          • 트위터에서는 RPUSHX를 사용해서 피드에 새로운 데이터가 있을 때 추가
    • Streams
      • 로그를 저장하기 가장 적절한 자료구조
      • append-only
      • 시간 범위로 검색 / 신규 추가 데이터 수신 / 소비자별 다른 데이터 수신(소비자 그룹)

 

 

 

---

참고 👇

https://www.youtube.com/watch?v=92NizoBL4uA