Implementation Principles of Redis Pub/Sub (Ordinary Subscription)
This article explains how Redis implements the Pub/Sub messaging pattern by storing subscription relationships in hash‑based dictionaries, detailing the processing flow of SUBSCRIBE and PUBLISH commands, cluster propagation, and key limitations such as lack of persistence and client buffer constraints.
Redis Pub/Sub is a messaging pattern where publishers send messages to channels and subscribers receive them.
The Redis server stores subscription relationships in a dictionary (hash table) where the key is the channel name and the value is a linked list of client objects subscribed to that channel.
Each client also keeps a dictionary of the channels it subscribes to, enabling quick lookup of a client’s subscriptions.
When a SUBSCRIBE command is processed (function subscribeCommand in pubsub.c ), the server adds the channel‑client pair to the server‑wide hash and records the channel in the client’s pubsub_channels dictionary.
Publishing a message (function publishCommand in pubsub.c ) looks up the channel in server.pubsub_channels , iterates over the client list, and writes the message into each client’s reply buffer via addReplyPubsubMessage . If the server runs in cluster mode, clusterPropagatePublish forwards the message to replicas.
Important caveats:
Messages are not persisted; offline subscribers miss any messages sent while they are disconnected.
Each client’s reply buffer has a size limit; exceeding it forces the server to close the client connection, requiring the client to resubscribe.
Because of these characteristics, Redis Pub/Sub is unsuitable as a durable message queue.
Cognitive Technology Team
Cognitive Technology Team regularly delivers the latest IT news, original content, programming tutorials and experience sharing, with daily perks awaiting you.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.