Pub/Sub Commands

​

SUBSCRIBE

SUBSCRIBE channel [channel ...]

redis-cli> SUBSCRIBE news weather
1) "subscribe"
2) "news"
3) (integer) 1
1) "subscribe"
2) "weather"
3) (integer) 2

• Enters pub/sub mode (client can only use pub/sub commands)
• Receives messages as arrays: [“message”, channel, payload]
• Subscription count increases with each channel

​

UNSUBSCRIBE

UNSUBSCRIBE [channel ...]

redis-cli> UNSUBSCRIBE news
1) "unsubscribe"
2) "news"
3) (integer) 1

redis-cli> UNSUBSCRIBE
1) "unsubscribe"
2) "weather"
3) (integer) 0

• Without arguments, unsubscribes from all channels
• Client exits pub/sub mode when subscription count reaches 0

​

PSUBSCRIBE

PSUBSCRIBE pattern [pattern ...]

redis-cli> PSUBSCRIBE news.* sports.*
1) "psubscribe"
2) "news.*"
3) (integer) 1
1) "psubscribe"
2) "sports.*"
3) (integer) 2

• Pattern messages include the pattern that matched: [“pmessage”, pattern, channel, payload]
• A message can match multiple patterns (delivered once per pattern)
• Glob syntax: * = any characters, ? = single character, [abc] = character set

​

PUNSUBSCRIBE

PUNSUBSCRIBE [pattern ...]

redis-cli> PUNSUBSCRIBE news.*
1) "punsubscribe"
2) "news.*"
3) (integer) 1

redis-cli> PUNSUBSCRIBE
1) "punsubscribe"
2) "sports.*"
3) (integer) 0

​

PUBLISH

PUBLISH channel message

redis-cli> PUBLISH news.tech "AI breakthrough announced"
(integer) 3
redis-cli> PUBLISH private.logs "Error: connection timeout"
(integer) 0

• Returns immediately after delivering to all subscribers
• Does not wait for subscribers to process the message
• Fire-and-forget semantics (no persistence or delivery guarantees)

​

Message Format

​

Channel Messages

1) "message"
2) "news.tech"
3) "AI breakthrough announced"

​

Pattern Messages

1) "pmessage"
2) "news.*"
3) "news.tech"
4) "AI breakthrough announced"

​

Subscription Confirmations

1) "subscribe"
2) "news.tech"
3) (integer) 1

1) "psubscribe"
2) "news.*"
3) (integer) 1

​

Pub/Sub Mode

​

Entering Pub/Sub Mode

• Cannot execute regular commands (GET, SET, etc.)
• Can only use: SUBSCRIBE, UNSUBSCRIBE, PSUBSCRIBE, PUNSUBSCRIBE, PING, QUIT
• Connection becomes push-based (receives messages asynchronously)

​

Exiting Pub/Sub Mode

• Call UNSUBSCRIBE without arguments to unsubscribe from all channels
• Call PUNSUBSCRIBE without arguments to unsubscribe from all patterns
• When subscription count reaches 0, client can execute regular commands again

​

Performance Characteristics

​

Throughput

• Single publisher: 1M+ messages/sec per shard
• Multiple publishers: Linear scaling with shards
• Fan-out: Minimal overhead per subscriber

​

Latency

• Intra-shard: Less than 100µs publish-to-delivery
• Cross-shard patterns: Less than 500µs (replicated to all shards)
• Network RTT: Adds ~1ms for remote clients

​

Scalability

• Channels: Unlimited (hash-partitioned across shards)
• Subscribers per channel: Thousands with minimal overhead
• Pattern subscriptions: Replicated to all shards (use sparingly)

​

Use Cases

​

Real-Time Notifications

# Publisher: send user notifications
redis-cli> PUBLISH user:123:notifications "New message from Alice"

# Subscriber: receive notifications
redis-cli> SUBSCRIBE user:123:notifications
1) "message"
2) "user:123:notifications"
3) "New message from Alice"

​

Event Broadcasting

# Publisher: broadcast system events
redis-cli> PUBLISH events.system "Server restarting in 5 minutes"

# Subscribers: listen for all events
redis-cli> PSUBSCRIBE events.*
1) "pmessage"
2) "events.*"
3) "events.system"
4) "Server restarting in 5 minutes"

​

Chat Application

# Publisher: send chat message
redis-cli> PUBLISH room:general:chat "Alice: Hello everyone!"

# Subscribers: listen to chat room
redis-cli> SUBSCRIBE room:general:chat
1) "message"
2) "room:general:chat"
3) "Alice: Hello everyone!"

​

Cache Invalidation

# Publisher: notify cache invalidation
redis-cli> PUBLISH cache.invalidate "users:123"

# Subscribers: listen for invalidation events
redis-cli> SUBSCRIBE cache.invalidate
1) "message"
2) "cache.invalidate"
3) "users:123"

​

Sharding Behavior

​

Channel Subscriptions

• Channels are hash-partitioned across shards
• Each channel is handled by exactly one shard
• Subscribers connect to the shard that owns their channel
• PUBLISH routes to the correct shard automatically

​

Pattern Subscriptions

• Patterns are replicated to all shards
• Pattern subscribers receive messages from all shards
• Higher memory overhead for pattern subscriptions
• Use specific channels when possible for better performance

​

Reliability Guarantees

​

Message Delivery

• At-most-once: Messages not persisted, lost if no subscribers
• Best-effort: Delivered to all active subscribers at publish time
• No replay: Subscribers only receive messages sent after subscription

​

Ordering

• Per-channel: Messages delivered in publish order
• Cross-channel: No ordering guarantees
• Pattern subscriptions: Order preserved within each matching channel

​

Failure Handling

• Publisher failure: Messages lost, no retry
• Subscriber disconnect: Misses messages while disconnected
• Server restart: All subscriptions and in-flight messages lost

​

Comparison with Redis

• Identical command syntax and behavior
• Same message format
• Compatible wire protocol (RESP2)
• Drop-in replacement for Redis pub/sub clients

• Sharded pub/sub (better multi-threaded performance)
• Lower latency for intra-shard messages
• Pattern subscriptions have higher overhead (replicated to all shards)
• No PUBSUB command (introspection) yet