Redis 동작 원리 & data structure & Back up!

1. Redis 는 어떻게 동작할까?

     : Redis 핵심 서버 엔진은 단일 쓰레드, 논블로킹 이벤트 루프로 동작

     ( 클라이언트 요청 → 이벤트 루프 → 명령 실행 → 응답 하는 구조임)

  

     - 이벤트 루프란?

(출처: Redis Single-Threaded Architecture: The Key to Its Lightning-Fast Performance)

 

 

       1) 클라이언트가 요청을 보냄 → 소켓 이벤트 감지

       2) 이벤트 루프가 해당 명령을 싱글 스레드에서 바로 실행

           (대부분의 명령은 메모리 연산이므로 바로 처리 가능)

       3) 처리 결과를 바로 클라이언트 소켓에 기록 (별도 스레드 없이도 논블로킹 소켓 사용 가능)

       4) 이벤트 루프는 다음 이벤트(클라이언트 요청, 타이머, 내부 이벤트 등)로 넘어감

 

       

"이러한 구조때문에 rua script 를 최소화 해서 사용 필요"

왜?

1) Lua 스크립트도 Redis 단일 이벤트 루프에서 실행 됨
2) 즉, 스크립트가 복잡하거나 오래 걸리는 연산이면 이벤트 루프가 막혀서 다른 클라이언트 요청이 대기 함
3) 전체 Redis 처리량 감소
4) 지연(latency) 증가

 

 

 

2. Redis 의 구조에서 오는 장점

     - 단일 스레드라 race condition 걱정 없음

        (쓰기 명령은 순차 처리, 읽기 명령도 순차 처리)

     - 복잡한 락 없이 높은 성능, 예측 가능한 처리

 

 

3. Sentinel VS Cluster

 

 

(출처: https://architecturenotes.co/p/redis)

 - redis sentinel 구조는 sentinel node를 추가를 두어 단일 마스터에 여러 슬레이브 구조로써,

    마스터 또는 각 슬레이브에 장애 발생 시 sentinel node 에서 이를 계속 모니터닝 후 master 교체(failover)

    및 자동복구 하는 체계로 구성되어 있다.

 - 방면, Cluster 구조는 멀티 마스터의 구조(샤드구조)가 가능하고 sentinel 보다 더욱 복잡하고 규모가

    큰 HA(고가용성)을 지원한다.

 

 

4. Redis data stucture 

https://redis.io/technology/data-structures/

(출처: https://architecturenotes.co/p/redis)

 

5. Redis Backup (Persistence)

    - AOF만으로 운영하기

       1) appendonly yes 설정 → Redis는 모든 쓰기 연산을 append-only log에 기록.

       2) 서버가 죽더라도 → 재시작 시 appendonly.aof 파일을 읽어서 데이터를 그대로 복구.

            ( 즉, RDB를 꺼도 데이터 유실 최소화 가능.

              → AOF 백업 방식의 경우 모든 write 과 update 에 대해 기록 하기 때문에 일정간격마다

                  현 data 전체를 snapshot 으로 저장하는 RDB 방식보다 유실이 적음) 

       3) AOF Rewrite (용량 관리) 설정 

            : AOF는 계속 append만 하다 보니 파일 크기가 커짐.

            → Redis는 rewrite (재작성) 기능을 제공(AOF 단점 보완)

                 : 오래된 로그를 압축해서 현재 상태만 반영하는 작은 AOF 파일로 교체.

                 BGREWRITEAOF 명령어 or 자동 설정 (auto-aof-rewrite-percentage, auto-aof-rewrite-min-size).