Redis, Redis Pub/Sub, Redis Stream( VS Kafka)

1️⃣ Redis(Remote Dictionary Server)란 무엇인가?

= 키-값(key-value) 구조로 데이터를 저장하는 인메모리 데이터 저장소.

Redis의 특징

항목	설명
인메모리	디스크 대신 메모리에 저장해서 빠른 속도
Persistence 지원	필요하면 디스크에 주기적으로 저장 가능 (AOF, RDB)
다양한 자료구조	String, List, Set, Sorted Set, Hash, HyperLogLog 등
싱글 스레드 기반	I/O 멀티플렉싱으로 고성능 유지 (논블로킹)
Pub/Sub 지원	메시지 브로커처럼 채널 기반 발행/구독 가능
간단한 설치 및 사용	몇 줄 명령어로 바로 사용 가능

 

2️⃣ Redis가 동작하는 원리

1. 인메모리 저장

• 모든 데이터는 RAM(메모리)에 저장.
• → 읽기/쓰기가 수천~수만 QPS(초당 쿼리 수)로 엄청 빠르다.

2. 싱글 스레드 기반 I/O 멀티플렉싱

• Redis 서버 프로세스는 하나의 스레드로 동작.
• 하지만 내부적으로 epoll 같은 기술로 여러 클라이언트 연결을 동시에 처리.

3. 영속성(Persistence)

• 메모리에만 있으면 전원 꺼지면 데이터 손실.
• 그래서 Redis는 두 가지 방식으로 디스크에 저장 가능
  • RDB (Redis Database Backup): 특정 시점 스냅샷 저장
  • AOF (Append Only File): 모든 명령어 기록 후 복구
• 설정에 따라 "메모리 + 디스크"를 조합해서 안정성을 확보까지 가능

4. 복제와 클러스터링

• Replication: 하나의 Redis 서버를 다른 서버가 복제해서 백업 서버로 유지 가능 (Master-Slave 구조)
  • Master: 데이터를 읽고 쓰는 기본 Redis 서버.
  • Replica(Slave): Master 서버의 데이터를 그대로 복제해 읽기 전용으로 유지.
  • → Master가 데이터를 변경하면 그 변경 사항을 Replica에게 자동 전파.
  • 읽기 부하 분산 가능 (Replica에서도 읽기 허용 가능).
  • 장애 복구 시, Replica를 승격해 Master로 만들 수 있음(replicaof no one 명령 사용).
  • 주의할 점은 Replication은 비동기라서, Master 장애 시 데이터 유실 가능성 있음.
• Cluster: 여러 Redis 인스턴스를 샤딩해서(키 분산) 더 큰 데이터를 처리 가능
  • 하나의 논리적 Redis를 여러 서버로 나눔.
    • 서버를 여러 개로 나눠서 더 많은 데이터를 저장
    • 단일 Redis 서버는 메모리 한계(예: 50GB, 100GB)가 있는데, ➔ Cluster는 서버 여러 대로 분산하니까 이론적으로 수백 GB, 수 TB 메모리까지 확장 가능
  • 키를 해시(Hash Slot)로 변환해서, 그 해시값에 따라 특정 노드에 저장. → 읽기/쓰기 처리량 증가
    • Redis Cluster는 0~16383까지 총 16384개의 해시 슬롯을 가짐.
    • 각 노드가 자기 슬롯만 담당하니까, 동시에 여러 노드가 병렬로 읽기/쓰기를 처리함.
  • 클라이언트가 키를 Redis Cluster에 요청하면, Cluster는 해당 키의 해시 슬롯을 계산해서 정해진 노드로 바로 라우팅. 각 노드는 자기 담당 슬롯의 키만 저장하고 관리함.
  • 각 노드는 자신의 Replica를 가질 수 있음

5. 자료구조

• Redis는 단순한 String 말고도 다양한 자료구조를 지원 가능

자료구조	설명	예시
String	가장 기본적인 값	"user:1:name" = "Yunbin"
List	순서가 있는 값들의 리스트	메시지 큐
Set	중복 없는 집합	유저가 가입한 그룹들
Sorted Set (ZSet)	점수에 따라 정렬되는 집합	랭킹 시스템
Hash	필드-값 쌍 저장	유저 정보 (name, age, etc)
HyperLogLog	대략적인 카운팅용	유니크 방문자 수 계산

 

3️⃣ Redis Stream

Redis Stream은 시간 순서대로 정렬된 데이터 레코드를 저장하고 관리하는 Redis의 데이터 타입이다. 각각의 레코드는 고유한 ID(타임스탬프 기반)를 가지며, 데이터는 "키-필드(field)-값(value)" 쌍 형태로 저장된다.

✅ Stream은 메시지 큐, 이벤트 로그, 데이터 파이프라인 등에 적합하며, 읽기/쓰기, 소비 그룹(Consumer Group)을 통한 병렬 처리, 메시지 보관 및 재처리 기능을 제공한다.

Redis Streams VS Kafka

• Redis Streams는 최대 길이(메시지 개수)를 지정할 수 있다. Kafka는 byte 또는 ms로 크기를 지정한다.
  • Redis Streams는 스트림 안에 "메시지 개수" 기준으로 관리 (예: 10만 개 넘으면 오래된 메시지를 자동 삭제)
  • Kafka는 "디스크 용량(byte)" 이나 "시간(ms)" 기준으로 관리. (예: 7일 지나면 메시지를 삭제하거나, 토픽 저장 크기가 1GB 넘으면 삭제)
• Redis Streams는 Hash 처럼 데이터를 저장하고 사용한다. Kafka는 직렬화 가능한 모든 형태로 지정할 수 있다.
  • Redis Streams는 기본적으로 Hash Map(키-값 쌍) 구조
  • Kafka는 메시지 본문을 자유롭게 Byte 배열로 다룸 → (JSON, Avro, Protobuf, 아무거나 직렬화해서 보낼 수 있음)
• 가장 다른점은 레디스의 컨슈머 그룹은 파티션의 존재 유무라고 볼 수 있다. 스트림처리에 있어 1개의 큐에 여러 컨슈머가 붙어서 데이터를 동시처리하는 것이다. 이런 방식은 데이터 처리 순서를 보장할 수 없다.
  1. Kafka
     • "파티션"은 토픽(Topic)을 여러 조각으로 나눈다. 즉, "토픽 = 여러 파티션들의 집합”
       • 병렬 쓰기 가능
       • ➔ 여러 Producer가 동시에 다른 파티션에 쓸 수 있어. (성능 올라감)
       • 병렬 읽기 가능
       • ➔ 여러 Consumer가 서로 다른 파티션을 나눠 읽을 수 있어. (소비 속도 빨라짐)
       • 확장성
       • ➔ 나중에 파티션 수를 늘리면 시스템을 수평 확장할 수 있어.
       • 부하 분산
       • ➔ 데이터가 한 군데 몰리지 않고 퍼지니까, 부하가 분산됨.
  2. Redis Stream
     • Redis Stream은 기본적으로 "하나의 스트림”, Consumer Group이 여러 개 있으면 메시지를 분담해서 읽는 구조.
       • 전체 순서가 흐트러질 위험
       • 예를 들어

         순서	메시지
         1	A 주문
         2	B 주문
         3	C 주문

       그런데 두 명의 Consumer가 읽으면...
       • Consumer 1: C 주문 먼저 처리 (빨리 읽음)
       • Consumer 2: A 주문 늦게 처리 (느리게 읽음)
       ➡️ 순서가 A → B → C가 아니라, C → A → B가 될 수도 있음!

👉 금융, 주문, 재고 등은 "처리 순서"가 중요한 시스템에서 장애가 발생할 수 있다.

 

4️⃣ Redis Pub/Sub

레디스 Pub/Sub은 레디스 큐, 스트림과 다르게 모든 구독자(subscriber)에게 메시지를 던지는 시스템이다. 즉, 데이터를 저장하는게 아니기 때문에 구독자가 없으면 데이터는 사라진다. publish 명령어로 데이터를 보내고 subscribe 명령으로 데이터를 받는다.

✅ 누군가 그 채널에 메시지를 발행(PUBLISH) 하면, 그 채널을 구독(SUBSCRIBE) 한 모든 클라이언트가 실시간으로 받아본다.

 

👉 실시간 푸시만 필요하면 Pub/Sub를 활용해서 빠른 속도로 해결 가능하다.

 

끝.