Redis Pub/Subはどのように動作しますか？

Question

Accepted Answer

**Pub/Sub**（Publish/Subscribe）はRedisのメッセージングパターンで、**パブリッシャー**が**チャネル**にメッセージを送信し、**サブスクライバー**がサブスクライブしているチャネルからメッセージを受け取ります。パブリッシャーとサブスクライバーは互いを知ることはありません。リアルタイムメッセージングと、サービス間の疎結合通信を実現します。

## Pub/Subモデル

```bash
# Subscriber listens on a channel
SUBSCRIBE news                    # subscribe to the "news" channel

# Publisher sends a message to the channel (in another connection)
PUBLISH news "Breaking story!"    # all subscribers to "news" receive this instantly

# Pattern subscriptions (wildcards)
PSUBSCRIBE news.*                 # subscribe to news.sports, news.tech, etc.
```

パブリッシャーがチャネルに`PUBLISH`し、サブスクライバーがチャネルに`SUBSCRIBE`してリアルタイムにメッセージを受け取ります。それらは**疎結合**です。パブリッシャーは誰が（もしくは誰も）リッスンしているかを知りません。

## ユースケース

```text
✓ REAL-TIME notifications — push events to interested services/clients instantly
✓ Chat / messaging — broadcast messages to subscribers
✓ Live updates — dashboards, feeds, multiplayer (broadcast state changes)
✓ Decoupling services — services communicate via channels without direct coupling
✓ Often paired with WebSockets (Redis pub/sub → server → WebSocket → browser)
```

## 重要な制限：ファイア・アンド・フォーゲット

```text
⚠️ Redis Pub/Sub is FIRE-AND-FORGET (at-most-once delivery):
  → Messages are delivered ONLY to subscribers connected AT THAT MOMENT.
  → If a subscriber is offline/disconnected, it MISSES the message (no storage/replay).
  → No persistence, no acknowledgment, no delivery guarantee.
→ NOT suitable when you need reliable delivery or message history.
```

## 信頼性が必要な場合：Streamsを使用

```text
For RELIABLE messaging (persistence, replay, consumer groups, acknowledgments):
  → use Redis STREAMS (a durable, log-based structure) instead of Pub/Sub
  → or a dedicated message broker (Kafka, RabbitMQ)
Pub/Sub → simple real-time broadcast where missing messages is acceptable
Streams → when you need durability and delivery guarantees
```

## なぜ重要なのか

Redis Pub/Subを理解することは、**リアルタイムメッセージングと疎結合通信**にとって価値があり、有用な知識です。しかし、同様に重要なのは、その制限を理解して適切に使用することです。

Pub/Subは、パブリッシャーがチャネルにブロードキャストし、サブスクライバーが即座に受け取る**リアルタイムメッセージング**を実現します。パブリッシャーとサブスクライバーは**疎結合**（互いに認識しない）です。これにより、リアルタイム通知、チャット、ライブダッシュボード更新、疎結合サービス通信（ブラウザに更新をプッシュするためにWebSocketと組み合わせることが多い）といったユースケースが実現します。

これにより、Redisはリアルタイムブロードキャスト機能の単純で高速なオプションになります。

しかし、**最も重要な点**は、Pub/Subの**ファイア・アンド・フォーゲット制限**を理解することです。これは最大1回配信で、メッセージはその時点で接続しているサブスクライバーのみに到達し、オフラインのサブスクライバーは**メッセージを永遠に見落とします**（永続性、リプレイ、確認応答、配信保証がない）。

これは重要な制約です。Pub/Subは信頼性の高い配信またはメッセージ履歴が重要な場合には不適切であり、このことを理解していないとメッセージ喪失のバグにつながります。

代替手段を知ること（信頼性の高いメッセージングのための**Redis Streams**（耐久性があり、ログベースで、コンシューマーグループと確認応答がある）またはKafka、RabbitMQなどの専用ブローカー）、そしてメッセージ喪失が許容可能な単純なリアルタイムブロードキャストでのみPub/Subを選択することは、適切な判断を反映しています。

リアルタイムメッセージングは一般的なニーズであり、Redis Pub/Subはそれに対する単純なソリューションを提供しますが、重要な信頼性制限があるため（保証が必要な場合はStreamsまたはブローカーが必要）、Pub/Sub（それがどのように動作するか、ユースケース、特にファイア・アンド・フォーゲット制限とStreamsをいつ使用すべきか）を理解することは、リアルタイム機能を正しく実装するための価値的で実践的な知識です。制限を理解することは、機能を理解することと同じくらい重要です。