Redis’s Pub/Sub (Publish/Subscribe) model operates on the principle of messaging wherein message senders, known as publishers, don’t target messages directly at specific recipients, or subscribers. Instead, the system revolves around channels, where messages are published, and subscribers express their interest in specific channels, receiving only the messages pertinent to them. This separation between senders and receivers enhances the adaptability and scalability of distributed systems, offering increased flexibility in their operations.
Pub/Sub in Redis is lightweight, fast, and operates asynchronously. It’s often used for real-time messaging, chat applications, notifications, and broadcasting messages to multiple clients or services.
Key Components
Publishers: They send messages to channels. Publishers are not aware of subscribers; they just publish messages to specific channels.
Subscribers: They subscribe to one or more channels and receive messages sent to those channels.
Channels: Channels are used as the routing mechanism for messages. Messages published to a channel are received by all subscribers of that channel.
Messages: These are the units of data being transmitted. They can be strings, numbers, or any other valid Redis data type.
For example, I will create two subscribers and one publisher. The channel is called MSG. Once the Publisher published a message, the two subscribers will receive it.
The two white shells are subscribers and the black shell is the publisher. The message “hey hey you you” communicated by the channel “MSG“.
If the publisher sent a message via other channel, will the subscribers receive it?
In the example, the publisher sent a message “hey hey” via channel “message” and you probably noticed that the subscribers did not receive the message and the response is (integer 0),which means there is 0 subscriber for the channel “message“. No one is listening this channel, so no one receives the message.
Another example, once the publisher sent the message “second msg” via channel “MSG“, the two subscribers received it immediately.
Pattern Matching
The Redis Pub/Sub implementation supports pattern matching. Subscribers may subscribe to glob-style patterns to receive all the messages sent to channel names matching a given pattern.
For example, there are many topics for news such as sports, movie, etc. We can use PSUBSCRIBE to subscribe to all channels matching the pattern news.*
pmessageindicates the type of message – pattern matched message.news.*indicates the message pattern.news.Tech,news.game,news.sportare the actual channel name where the message was published.- The last line is the content of message itself.
If we don’t want to receive this type of messages any more, we can use PUNSUBSCRIBE to cancel the subscription.
#In the subscriber shell
127.0.0.1:6379> PUNSUBSCRIBE news.*
1) "punsubscribe"
2) "news.*"
3) (integer) 0
#In the publisher shell
127.0.0.1:6379> PUBLISH news.movie "Barbie"
(integer) 0 # there is no subscriber any more
127.0.0.1:6379>
Broadcast
In the context of Pub/Sub in Redis, “broadcast” refers to the act of sending a message to all subscribers of a particular channel. When a message is published to a channel, Redis distributes that message to all clients that are subscribed to that channel. This mechanism allows for broadcasting messages to multiple subscribers simultaneously without the need for the publisher to know about or address each individual subscriber.
Key Components
Chat Applications: Broadcasting messages to all users in a chat room.
Notifications: Sending notifications to multiple clients or services subscribed to a particular topic.
Event Broadcasting: Informing all interested parties about a particular event or update.
Distributed Systems Coordination: Propagating updates or changes across different components of a distributed system.
In Redis, broadcasting is achieved simply by publishing a message to a specific channel using the PUBLISH command. All subscribers of that channel will receive the message asynchronously.
For example, I create two subscribers for a broadcast called broadcast_channel and one publisher, which is the black shell. When the publish sent one message via the broadcast, the two subscribers receive it. Then I cancelled one subscription by using UNSUBSCRIBE, only one subscribe received the second message. The number of subscribers in the publisher’s shell updated, too.
