Redis Pub/Sub vs Redis Streams

Source: Dev.to

Source: …

Redis Pub/Sub와 Redis Streams란?

Redis Pub/Sub — Fire‑and‑Forget 메시징

발행자는 채널에 메시지를 보냅니다.
구독자는 발행 시점에 연결되어 있을 때만 메시지를 받습니다.
메시지 저장, 재시도, 재생 메커니즘이 없습니다.

주요 특징

Pub/Sub이 적합한 경우

• 실시간 UI 업데이트(대시보드, 실시간 커서, 존재 여부)
• 놓친 메시지가 허용되는 채팅 시스템
• 연결된 클라이언트에 시스템 상태를 방송

핵심 제한점

구독자가 연결이 끊기거나, 느리거나, 충돌하면 메시지는 영원히 사라집니다.

Redis Streams — 내구성 있는 이벤트 로그

Redis Streams는 지속적인, 추가 전용 로그를 도입하여 신뢰할 수 있는 이벤트 처리를 가능하게 합니다. 메시지는 Redis에 저장되고, 소비자는 자신의 속도에 맞춰 소비합니다.

핵심 개념

• Stream – 메시지의 순서가 있는 로그
• Message ID – 단조로운 고유 식별자
• Consumer Group – 여러 소비자 간의 협조된 소비
• ACK – 성공적인 처리 확인
• PEL (Pending Entries List) – 확인되지 않은 메시지 추적

주요 특징

Streams가 적합한 경우

• 작업 큐와 백그라운드 워커
• 이벤트 기반 마이크로서비스
• 감사 로그와 이벤트 소싱
• 복구와 재시도가 필요한 시스템

나란히 비교

Pub/Sub 내부 작동 방식

1. 구독자가 연결하고 채널을 구독합니다.
2. 발행자가 메시지를 발행합니다.
3. Redis가 즉시 메시지를 모든 활성 구독자에게 푸시합니다.

구독자가 그 순간에 연결되어 있지 않으면, 메시지는 삭제됩니다. 백프레셔 처리가 없으며 메시지 히스토리도 없습니다.

Redis Streams가 내부적으로 작동하는 방식

# Producer appends a message
XADD mystream * field1 value1 field2 value2

# Consumer reads messages (group mode)
XREADGROUP GROUP mygroup consumer1 COUNT 10 STREAMS mystream >

# Consumer acknowledges processing
XACK mystream mygroup 1526985054069-0

• Redis는 고유한 ID와 함께 메시지를 저장합니다.
• 소비자는 XREAD 또는 XREADGROUP을 사용해 메시지를 읽습니다.
• 확인되지 않은 메시지는 복구를 위해 PEL에 남아 있습니다.

Streams는 Kafka나 SQS와 유사하게 동작하지만, 완전히 Redis에 내장되어 있습니다.

Delivery Guarantees Explained

Pub/Sub — At‑Most‑Once

• 메시지는 0번 또는 1번 전달됩니다.
• 재시도 없음, 확인도 없음.
• 비핵심 데이터에 가장 적합합니다.

Streams — At‑Least‑Once

• 메시지가 영구 저장됩니다.
• 처리를 재시도할 수 있습니다.
• 소비자는 중복 가능성을 처리해야 합니다.

Scaling Considerations

Pub/Sub

• 매우 빠름.
• 최소 메모리 오버헤드.
• 구독자 수가 증가함에 따라 팬‑아웃 비용이 증가합니다.

Streams

• 높은 메모리 사용량.
• 컨슈머 그룹이 부하를 분산합니다.
• 수평 확장 및 내결함성을 지원합니다.

Decision Rules (Use This in Real Projects)

실제 예시

알림

• 온라인 사용자만 중요합니다 → Pub/Sub
• 모든 사용자가 메시지를 받아야 합니다 → Streams

주문 처리 파이프라인

• 재고, 청구, 배송 조정 → Streams

일반적인 실수

• Pub/Sub를 작업 큐로 사용하는 것 ❌
• Pub/Sub에서 내구성을 기대하는 것 ❌
• Streams에서 중복 처리를 무시하는 것 ❌
• 오래된 스트림 항목을 절대 정리하지 않는 것 ❌

요약

Redis는 두 가지 메시징 패러다임을 제공합니다:

• Pub/Sub — 간단하고 빠르며 일시적
• Streams — 내구성 있고 신뢰할 수 있으며 재생 가능

편의성이 아니라 전달 보장, 장애 내성, 그리고 시스템 복잡성을 기준으로 선택하세요.

경험 법칙:

• 메시지 손실이 허용되는 경우 → Pub/Sub
• 메시지 손실이 허용되지 않는 경우 → Streams

추가 읽을거리

• Redis Pub/Sub 문서
• Redis Streams 문서
• Redis 메시징 패턴에 대한 시스템 설계 비교