Redis Pub/Sub ทำงานอย่างไร?

Question

Accepted Answer

**Pub/Sub** (Publish/Subscribe) เป็นรูปแบบการส่งข้อความของ Redis ที่ **publisher** ส่งข้อความไปยัง **channel** และ **subscriber** รับข้อความจาก channel ที่พวกเขา subscribe อยู่ — โดยที่ publisher และ subscriber ไม่รู้จักกัน มันรองรับการส่งข้อความแบบเรียลไทม์และการสื่อสารแบบแยกส่วนระหว่าง service

## โมเดล 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.
```

Publisher ใช้ `PUBLISH` ไปยัง channel ส่วน subscriber ใช้ `SUBSCRIBE` ไปยัง channel และรับข้อความแบบเรียลไทม์ พวกมัน **แยกส่วนกัน** — publisher ไม่รู้ว่าใคร (ถ้ามี) กำลังฟังอยู่

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

## ข้อจำกัดสำคัญ: 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.
```

## เมื่อต้องการความน่าเชื่อถือ: ใช้ 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 รองรับ **การส่งข้อความแบบเรียลไทม์** ที่ publisher broadcast ไปยัง channel และ subscriber รับทันที โดย publisher และ subscriber **แยกส่วนกัน** (ไม่รู้จักกัน) — รองรับ use case เช่น การแจ้งเตือนแบบเรียลไทม์ chat การอัปเดต dashboard แบบสด และการสื่อสารระหว่าง service แบบแยกส่วน (มักจับคู่กับ WebSocket เพื่อ push การอัปเดตไปยัง browser)

สิ่งนี้ทำให้ Redis เป็นตัวเลือกที่ง่ายและรวดเร็วสำหรับฟีเจอร์ broadcast แบบเรียลไทม์

อย่างไรก็ตาม **ประเด็นที่สำคัญที่สุด** คือการเข้าใจ **ข้อจำกัด fire-and-forget** ของ Pub/Sub: มันเป็น at-most-once delivery — ข้อความถึงเฉพาะ subscriber ที่เชื่อมต่ออยู่ ณ ขณะนั้น และ subscriber ที่ offline จะ **พลาดข้อความถาวร** (ไม่มี persistence, replay, acknowledgment หรือการรับประกันการส่ง)

นี่เป็นข้อจำกัดสำคัญ: Pub/Sub ไม่เหมาะเมื่อการส่งที่น่าเชื่อถือหรือประวัติข้อความสำคัญ และการไม่เข้าใจสิ่งนี้นำไปสู่บั๊กข้อความสูญหาย

การรู้ทางเลือก — **Redis Streams** (คงทน อิงตาม log พร้อม consumer group และ acknowledgment) หรือ broker เฉพาะทาง (Kafka, RabbitMQ) สำหรับการส่งข้อความที่น่าเชื่อถือ — และเลือก Pub/Sub เฉพาะสำหรับการ broadcast แบบเรียลไทม์ที่ยอมให้พลาดข้อความได้ สะท้อนถึงวิจารณญาณที่ดี

เนื่องจากการส่งข้อความแบบเรียลไทม์เป็นความต้องการที่พบบ่อย และเนื่องจาก Redis Pub/Sub มอบโซลูชันที่ง่ายสำหรับสิ่งนี้แต่มีข้อจำกัดด้านความน่าเชื่อถือที่สำคัญ (ต้องใช้ Streams หรือ broker เมื่อต้องการการรับประกัน) การเข้าใจ Pub/Sub — วิธีทำงาน use case และโดยเฉพาะข้อจำกัด fire-and-forget และเมื่อใดควรใช้ Streams แทน — จึงเป็นความรู้ที่มีคุณค่าและเกี่ยวข้องเชิงปฏิบัติสำหรับการสร้างฟีเจอร์เรียลไทม์อย่างถูกต้อง ที่การเข้าใจข้อจำกัดสำคัญพอ ๆ กับการเข้าใจความสามารถ