Redis Pub/Sub은 어떻게 동작하나요?

Question

Accepted Answer

**Pub/Sub**(Publish/Subscribe)은 Redis의 메시징 패턴으로, **발행자**가 **채널**에 메시지를 보내고 **구독자**가 구독한 채널에서 메시지를 받습니다 — 발행자와 구독자가 서로를 알지 못한 채로 말입니다. 서비스 간 실시간 메시징과 분리된 통신을 가능하게 합니다.

## Pub/Sub 모델

```bash
# 구독자가 채널을 청취
SUBSCRIBE news                    # "news" 채널 구독

# 발행자가 채널에 메시지 전송 (다른 연결에서)
PUBLISH news "Breaking story!"    # "news"의 모든 구독자가 즉시 수신

# 패턴 구독 (와일드카드)
PSUBSCRIBE news.*                 # news.sports, news.tech 등 구독
```

발행자는 채널에 `PUBLISH`하고; 구독자는 채널을 `SUBSCRIBE`하여 실시간으로 메시지를 받습니다. 이들은 **분리**되어 있습니다 — 발행자는 누가(있다면) 청취하는지 모릅니다.

## 사용 사례

```text
✓ 실시간 알림 — 관심 서비스/클라이언트에 이벤트를 즉시 푸시
✓ 채팅 / 메시징 — 구독자에게 메시지 브로드캐스트
✓ 실시간 업데이트 — 대시보드, 피드, 멀티플레이어 (상태 변경 브로드캐스트)
✓ 서비스 분리 — 직접 결합 없이 채널로 서비스 통신
✓ WebSocket과 자주 결합 (Redis pub/sub → 서버 → WebSocket → 브라우저)
```

## 중요한 제한: fire-and-forget

```text
⚠️ Redis Pub/Sub은 FIRE-AND-FORGET (at-most-once 전달):
  → 메시지는 그 순간 연결된 구독자에게만 전달됨.
  → 구독자가 오프라인/연결 끊김이면 메시지를 놓침 (저장/재생 없음).
  → persistence 없음, 확인 없음, 전달 보장 없음.
→ 신뢰성 있는 전달이나 메시지 이력이 필요할 때 부적합.
```

## 신뢰성이 필요할 때: Stream 사용

```text
신뢰성 있는 메시징(persistence, 재생, consumer group, 확인)을 위해:
  → Pub/Sub 대신 Redis STREAM(내구성 있는 로그 기반 구조) 사용
  → 또는 전용 메시지 브로커 (Kafka, RabbitMQ)
Pub/Sub → 메시지 손실이 허용되는 단순 실시간 브로드캐스트
Stream → 내구성과 전달 보장이 필요할 때
```

## 왜 중요한가

Redis Pub/Sub을 이해하는 것은 **실시간 메시징과 분리된 통신**에 가치가 있으므로 유용한 지식입니다 — 하지만 결정적으로, 그 제한을 이해하는 것이 이를 적절히 쓰는 데 똑같이 중요합니다.

Pub/Sub은 발행자가 채널에 브로드캐스트하고 구독자가 즉시 받는 **실시간 메시징**을 가능하게 하며, 발행자와 구독자가 **분리**(서로를 모름)되어 — 실시간 알림, 채팅, 실시간 대시보드 업데이트, 분리된 서비스 통신(브라우저에 업데이트를 푸시하기 위해 WebSocket과 자주 결합) 같은 사용 사례를 지원합니다.

이로써 Redis는 실시간 브로드캐스트 기능을 위한 간단하고 빠른 선택지가 됩니다.

하지만 **가장 중요한 점**은 Pub/Sub의 **fire-and-forget 제한**을 이해하는 것입니다: at-most-once 전달이며 — 메시지는 그 순간 연결된 구독자에게만 도달하고, 오프라인 구독자는 **메시지를 영구히 놓칩니다**(persistence, 재생, 확인, 전달 보장 없음).

이는 결정적인 제약입니다: Pub/Sub은 신뢰성 있는 전달이나 메시지 이력이 중요할 때 부적합하며, 이를 이해하지 못하면 메시지 손실 버그로 이어집니다.

대안 — 신뢰성 있는 메시징을 위한 **Redis Stream**(내구성, 로그 기반, consumer group과 확인 포함)이나 전용 브로커(Kafka, RabbitMQ) — 을 알고, 메시지 손실이 허용되는 단순 실시간 브로드캐스트에만 Pub/Sub을 선택하는 것은 건전한 판단을 반영합니다.

실시간 메시징은 흔한 요구이고, Redis Pub/Sub이 이에 간단한 해법을 제공하지만 중요한 신뢰성 제한이 있어(보장이 필요하면 Stream이나 브로커 필요) 있으므로, Pub/Sub — 동작 방식, 사용 사례, 특히 fire-and-forget 제한과 언제 대신 Stream을 쓸지 — 을 이해하는 것은 실시간 기능을 올바르게 구현하는 데 가치 있고 실무적으로 관련된 지식이며, 여기서는 제한을 이해하는 것이 기능을 이해하는 것만큼 중요합니다.