Sharded Pub/Sub in Redis Cluster

Channels that live on one shard

In Redis Cluster, the classic PUBLISH is propagated to every node so that subscribers connected anywhere receive it. That is simple, but cluster bus traffic grows with the number of nodes, so classic Pub/Sub does not scale horizontally. Sharded Pub/Sub, introduced in Redis 7.0, assigns each channel to a hash slot exactly like a key, so it belongs to one shard (a primary and its replicas). Clients use SSUBSCRIBE and SPUBLISH, connecting to the shard that owns the channel; messages travel only within that shard. Throughput now scales with the number of shards, and you can co-locate related channels and keys with hash tags such as {room:42}:chat. Cluster-aware client libraries route sharded commands automatically and resubscribe when slots move during resharding or failover. Use sharded Pub/Sub for any new cluster deployment with significant message volume.

Sharded channels

Each channel hashes to one shard, so messages stay within that shard instead of flooding the cluster.

Sharded Pub/Sub commands

The channel name is hashed like a key; hash tags group related channels.

# subscriber (cluster-aware client or redis-cli -c)
redis-cli -c SSUBSCRIBE '{room:42}:chat'

# publisher
redis-cli -c SPUBLISH '{room:42}:chat' '{"from":"asha","text":"hi"}'

# which slot (and so which shard) owns the channel
redis-cli -c CLUSTER KEYSLOT '{room:42}:chat'

# list sharded channels on a node
redis-cli PUBSUB SHARDCHANNELS

Local announcements per building

Classic Pub/Sub in a cluster is announcing every message in every building of the campus. Sharded Pub/Sub sends each announcement only to the building where that room's members actually sit.

त्वरित जाँच: Why does sharded Pub/Sub scale better than classic Pub/Sub in Redis Cluster?

• Each channel belongs to one shard, so messages are not broadcast to every node
• It stores messages on disk
• It removes the need for subscribers
• It compresses all messages