Radis
Redis(레디스)는 Remote Dictionary Server의 약자로, 인메모리 데이터 구조 서버이며,
고성능의 키-값 저장소로서 주로 캐싱, 세션 관리, 실시간 분석 등에 사용된다
주요특징
1. In -meory database
모든 데이터를 메모리에 저장하고 처리하기 때문에 매우 빠른 응답 속도
Redis는 데이터를 메모리에 저장하고 처리하기 때문에, 디스크 I/O보다 훨씬 빠른 응답 속도를 제공 -> 실시간 애플리케이션에 매우 유리하다
- Millisecond Response (1ms = 0.001s)
Redis는 일반적으로 응답 시간이 밀리초 단위로 측정
-
Volatility of RAM: RAM은 휘발성 메모리
시스템이 재시작되면 RAM에 저장된 모든 데이터가 사라진다
하지만 Redis는 AOF(Append Only File)와 RDB(Redis Database) 스냅샷 같은 퍼시스턴스 메커니즘을 통해 데이터를 디스크에 저장하여 이러한 단점을 보완 -
Data Types: Redis는 다양한 데이터 타입을 지원하여 다양한 요구사항에 대응할 수 있다
Strings: 가장 기본적인 데이터 타입으로, 일반적으로 캐시나 카운터에 사용됩니다.
Hashes: 필드와 값의 쌍으로 구성된 맵으로, 객체를 저장하는 데 유용합니다.
Lists: 연결 리스트로, 순서가 있는 데이터의 저장과 처리가 필요할 때 사용됩니다.
Sets: 중복을 허용하지 않는 집합으로, 유일한 요소의 컬렉션을 관리할 때 유용합니다.
Sorted Sets: 점수와 함께 저장된 요소의 집합으로, 순위나 우선순위를 관리할 때 사용됩니다.2. Persistent on Disk
1) RDB 스냅샷
RDB(Redis Database)는 특정 시점의 데이터 상태를 디스크에 저장
스냅샷 방식은 설정된 간격에 따라 메모리의 모든 데이터를 바이너리 파일로 덤프
덤프(dump)는 데이터베이스나 다른 시스템에서 특정 시점의 데이터를 파일로 저장하는 과정
- 장점:
특정 시점의 데이터 전체를 저장하므로 복구가 빠르다
파일 크기가 상대적으로 작아질 수 있다 - 단점:
설정된 간격 사이에 발생한 데이터 변경은 저장되지 않는다
데이터 손실 가능성이 존재
2) AOF(Append Only File)
AOF 방식은 모든 쓰기 명령어를 로그 파일에 순차적으로 기록
Redis가 재시작될 때 이 로그 파일을 다시 실행하여 데이터 복구
- 장점:
더 빈번하게 데이터를 기록하므로 데이터 손실 가능성이 적다
데이터의 모든 변경 사항을 기록(history 를 쌓는다) - 단점:
로그 파일이 커질 수 있으며, 더 많은 디스크 공간을 필요로 한다
복구 시간이 길어질 수 있다
3) 두 방식을 함께 사용
원래 기본은 RDB만 활성화 되어지만, 중요한 데이터라면 함께 사용하는 것을 더 추천한다
Redis는 RDB와 AOF 방식을 함께 사용하여 성능과 데이터 안전성을 균형 있게 유지
RDB 스냅샷은 빠른 복구를 위해, AOF는 더 적은 데이터 손실을 보장하기 위해 사용
Redis는 두 방식의 조합을 통해 데이터 영속성을 강화할 수 있다
3. 싱글 쓰레드
한 번에 하나의 명령만 처리할 수 있는 구조를 의미
여러 클라이언트가 동시에 명령을 보내더라도 Redis는 순차적으로 이를 처리
- 그림에서 도착한 순서대로 4->2->3->1 로 순차적으로 처리한다
싱글 쓰레드의 장점
-
단순성:
멀티 쓰레드 환경에서는 쓰레드 간의 동기화 문제, 데드락 등이 발생할 수 있다
싱글 쓰레드는 이러한 복잡성을 제거한다 -
빠른 처리 속도:
Redis는 메모리 기반 데이터 저장소이기 때문에, CPU 연산보다 메모리 I/O가 병목 현상이 되기 쉽다.
싱글 쓰레드로도 충분히 빠른 성능을 보장 -
예측 가능한 성능:
멀티 쓰레드 환경에서는 컨텍스트 스위칭에 따른 오버헤드가 발생하지만, 싱글 쓰레드는 이를 피할 수 있어 더 예측 가능한 성능을 제공
싱글 쓰레드의 단점
- CPU 활용 한계: 다중 코어를 효과적으로 활용하지 못하므로 CPU 집약적인 작업에서 한계를 보일 수 있다
- 단일 작업의 병목 현상: 특정 명령이 오래 걸리면 다른 명령의 처리가 지연될 수 있다
✅ Redis 6에서의 변화
Redis 6 버전부터는 Threaded I/O 기능을 도입하여 네트워크 I/O 작업을 별도의 쓰레드에서 처리하여 메인 쓰레드의 부담을 줄이는 방식을 사용해 단일 작업의 병목 현상의 한계를 보완할 수 있게 되었다
Threaded I/O의 장점
-
향상된 성능:
네트워크 I/O 작업이 별도의 쓰레드에서 처리되기 때문에, Redis의 처리 성능이 향상
특히, 많은 클라이언트가 동시에 연결되어 있을 때 유리 -
CPU 활용도 증가:
여러 쓰레드를 통해 멀티 코어 CPU의 리소스를 더 효율적으로 사용할 수 있다
4. Pub/Sub 메시징 시스템
Redis의 Pub/Sub(퍼블리셔-서브스크라이버) 모델은 메시지를 게시하는 퍼블리셔와 그 메시지를 구독하는 서브스크라이버 간의 비동기 통신을 지원
메시징 큐와 유사하게 동작하며, 다양한 애플리케이션에서 실시간 메시징을 가능하게 한다
-
채널(Channel): 퍼블리셔와 서브스크라이버가 메시지를 주고받는 가상의 경로
퍼블리셔는 채널에 메시지를 게시하고, 서브스크라이버는 해당 채널을 구독하여 메시지를 받는다 -
퍼블리셔(Publisher): 메시지를 생성하여 특정 채널에 게시하는 역할
-
서브스크라이버(Subscriber): 특정 채널을 구독하여 해당 채널에 게시되는 메시지를 실시간으로 받는 역할
특징
-
실시간 메시징: Pub/Sub 모델은 메시지가 게시되면 즉시 서브스크라이버에게 전달되므로 실시간 통신이 가능
-
비동기 통신: 퍼블리셔와 서브스크라이버는 비동기적으로 동작하여 서로의 상태에 독립적
-
다대다 통신: 하나의 퍼블리셔가 여러 서브스크라이버에게 메시지를 전달할 수 있고, 하나의 서브스크라이버가 여러 퍼블리셔의 메시지를 받을 수 있다
Radis Docker 환경에서 실행하기
1. docker 에 redis Pull
docker pull redis:6.2 docker에 radis 이미지를 풀을 받는다
2. redis 실행
docker run --rm -it -d -p 6379:6379 redis:6.2-d: 백그라운드에서 실행 (터미널을 닫아도 실행된다)
6379:6379 Port로 맵핑을 해줘야한다
3. Docker 컨테이너 내부의 Redis CLI를 실행하는 명령어
docker exec -it [container Id] redis-cli ping을 보내면 pong이 오는 걸 확인 할 수 있고,
info
명령어를 치면 아래 처럼 redis 정보들을 확인 할 수 있다
이제 Redis 컨테이너에 접속하여 Redis 명령어를 직접 입력하고 실행할 수 있다
4. monitor
docker exec -it [container Id] redis-cli monitorredis 컨테이너에서 실행하고 있는 명령어의 로그를 모니터할 수 있다
출처: 시그니처 백엔드 Path 초격차 패키지 Online.
