Redis Pub/Sub hoạt động như thế nào?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) là pattern nhắn tin của Redis nơi **publisher** gửi message tới các **channel** và **subscriber** nhận message từ các channel mà chúng đã subscribe — mà publisher và subscriber không biết về nhau. Nó cho phép nhắn tin real-time và giao tiếp tách rời giữa các service.

## Mô hình Pub/Sub

```bash
# Subscriber lắng nghe trên một channel
SUBSCRIBE news                    # subscribe channel "news"

# Publisher gửi một message tới channel (trên một connection khác)
PUBLISH news "Breaking story!"    # tất cả subscriber của "news" nhận được ngay lập tức

# Pattern subscription (wildcard)
PSUBSCRIBE news.*                 # subscribe news.sports, news.tech, v.v.
```

Publisher `PUBLISH` tới một channel; subscriber `SUBSCRIBE` các channel và nhận message theo thời gian thực. Chúng **tách rời** — publisher không biết ai (nếu có) đang lắng nghe.

## Các use case

```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)
```

## Hạn chế quan trọng: fire-and-forget

```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.
```

## Khi cần độ tin cậy: dùng 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
```

## Tại sao điều này quan trọng

Hiểu Redis Pub/Sub là giá trị cho **nhắn tin real-time và giao tiếp tách rời**, nên đó là kiến thức hữu ích — nhưng quan trọng là hiểu các hạn chế của nó cũng quan trọng không kém để dùng nó đúng cách.

Pub/Sub cho phép **nhắn tin real-time** nơi publisher broadcast tới các channel và subscriber nhận ngay lập tức, với publisher và subscriber **tách rời** (không biết về nhau) — phục vụ các use case như thông báo real-time, chat, cập nhật dashboard trực tiếp, và giao tiếp service tách rời (thường ghép với WebSocket để đẩy cập nhật tới trình duyệt).

Điều này khiến Redis trở thành một lựa chọn đơn giản, nhanh cho các tính năng broadcast real-time.

Tuy nhiên, **điểm quan trọng nhất** là hiểu **hạn chế fire-and-forget** của Pub/Sub: nó là at-most-once delivery — message chỉ đến các subscriber đang kết nối tại thời điểm đó, và subscriber offline **vĩnh viễn bỏ lỡ message** (không có persistence, replay, acknowledgment, hay đảm bảo gửi).

Đây là một ràng buộc cốt yếu: Pub/Sub không phù hợp khi gửi tin tin cậy hay lịch sử message quan trọng, và không hiểu điều này dẫn đến các lỗi mất message.

Biết các phương án thay thế — **Redis Streams** (bền, dựa trên log, với consumer group và acknowledgment) hoặc broker chuyên dụng (Kafka, RabbitMQ) cho nhắn tin tin cậy — và chỉ chọn Pub/Sub cho broadcast real-time đơn giản nơi việc bỏ lỡ message chấp nhận được phản ánh phán đoán đúng đắn.

Vì nhắn tin real-time là nhu cầu phổ biến, và vì Redis Pub/Sub cung cấp một giải pháp đơn giản cho nó nhưng với các hạn chế độ tin cậy quan trọng (cần Streams hoặc broker khi cần đảm bảo), hiểu Pub/Sub — cách nó hoạt động, các use case, và đặc biệt là hạn chế fire-and-forget cùng khi nào dùng Streams thay thế — là kiến thức giá trị, có liên quan về mặt thực hành để triển khai các tính năng real-time đúng cách, nơi hiểu hạn chế cũng quan trọng như hiểu khả năng.