Please enable JavaScript.

Coggle requires JavaScript to display documents.

피드화면 Caching에 왜 Redis를 사용했나요? - Coggle Diagram

- - - - 데이터를 읽어오는 과정에서 Input/Output 작업으로 인한 병목 현상이 발생하며, 복잡한 JOIN 연산은 응답 속도를 크게 저하시킴
    - - 트래픽이 몰리면 DB 서버를 스케일업(수직확장)하는데 한계가 있고, 스케일아웃(수평확장)은 구조가 매우 복잡함
  - - - 디스크 I/O 없이 메모리에서 바로 데이터를 읽어와 압도적으로 빠른 응답 속도를 보장
    - - 정해진 스키마 없이 다양한 형태의 데이터를 빠르게 저장하고 조회하는 데 유리
    - - 트래픽 증가 시 서버를 추가하는 방식으로 손쉽게 시스템 전체의 처리량을 늘릴 수 있음
  - - - Look-Aside(Lazy Loading) 전략을 기본으로 사용
        
        새로운 게시물 작성과 같이 중요한 업데이트 발생 시 관련 사용자들의 피드 캐시를 능동적으로 갱신(Cache Eviction/Update)해주는 전력을 혼합
- - - - Read (데이터 조회)
        
        애플리케이션은 먼저 Redis(Cache)에 피드 데이터가 있는지 확인
        
        (Cache Hit)데이터가 있으면 Redis에서 바로 데이터를 읽어 사용자에게 반환 (매우 빠름)
        
        (Cache Miss)데이터가 없으면 RDBMS(DB)에서 피드 데이터를 조회
        
        DB에서 가져온 데이터를 Redis에 저장하여 다음 요청을 대비
        
        사용자에게 데이터를 반환
      - Write(데이터 변경 / 생성)
        
        새로운 게시물이 작성돠면 먼저 RDBMS(DB)에 데이터를 저장
        
        그 후 이 게시물이 포함될 피드의 캐시(Redis)를 삭제(Evict)하거나 갱신(Update)하여 데이터의 일관성을 유지
- - - - Strings, Lists,Sorted Sets, Hashes
    - - 피드를 구현하는데 있어 '치트키'같은 역할
        
        게시물 ID를 점수(Score)로 타임스탬프를 사용하여 저장
        
        별도의 복잡한 로직 없이도 시간순으로 정렬된 피드 목록을 매우 빠르고 효율적으로 가져올 수 있음