Open In App

Complete Guide to Redis Publish Subscribe

Redis Publish-Subscribe (Pub/Sub) is a messaging pattern in Redis that allows one-to-many communication. It involves publishers and subscribers, where publishers send messages (also known as “events“) to channels, and subscribers receive messages from channels they are interested in. Pub/Sub is used for building real-time applications, message broadcasting, and event-driven architectures.

Redis Pub/Sub

Key Concepts and Components

Publishers and Subscribers

Publishers: These are clients that send messages to specific channels.
Subscribers: These are clients that receive messages from specific channels. Subscribers can subscribe to one or more channels.



Channels

Channels are the communication pathways in Redis Pub/Sub. Messages are published to specific channels, and subscribers listen to messages on one or more channels. Channels are identified by names, e.g., “news,” “chatroom,” “events,” etc. When a message is published on a channel, all subscribers in that channel receive the message.

Publish-Subscribe Model

In the Publish-Subscribe model, publishers and subscribers are decoupled. Publishers are unaware of the subscribers, and vice versa. Publishers publish messages to channels without knowing who, if anyone is listening. Subscribers receive messages from channels without knowing who, if anyone is publishing.



Message Queue

Redis Pub/Sub can be used as a simple message queue. Publishers push messages onto channels, and subscribers process these messages. This is useful for background job processing or task distribution.

Message Ordering

Redis guarantees the order in which messages are received by subscribers within the same channel. Messages are delivered in the order they were published.

Message Persistence

Messages in Redis Pub/Sub are not persistent. Once a message is sent and received by all subscribers, it is not stored in Redis. If a subscriber is not connected when a message is published, it will not receive that message.

Unsubscribing

Subscribers can unsubscribe from channels to stop receiving messages from those channels. Subscribers can also unsubscribe from all channels.

Pattern Subscriptions

Redis supports pattern subscriptions, where subscribers can subscribe to channels using wildcard patterns. For example, a subscriber can subscribe to all channels starting with “chat:” by subscribing to “chat:*.”

Persistence vs. Real-Time

Redis Pub/Sub is not designed for message persistence or storage. It’s primarily used for real-time messaging and communication. If message persistence is required, consider using other Redis data structures like lists or streams.

Scalability

Redis Pub/Sub is lightweight and highly scalable. It can handle a large number of publishers and subscribers efficiently.

How Redis Pub/Sub Works?

Redis Pub/Sub, short for Publish/Subscribe, is a messaging pattern that allows communication between multiple Redis clients. It enables one-to-many and many-to-many communication, where one or more publishers send messages to channels, and one or more subscribers receive these messages from channels. Redis Pub/Sub is a powerful feature for building real-time applications, chat systems, notifications, and more. Here’s an in-depth explanation of how Redis Pub/Sub works:

Redis Pub/Sub

Publishing Messages

Publishers use the PUBLISH command to send messages to channels. The syntax is as follows:

PUBLISH channel message

Example:

PUBLISH chat:general “Hello, everyone!”

Note: In this example, the message “Hello, everyone!” is sent to the “chat:general” channel.

Subscribing to Channels

Subscribers use the SUBSCRIBE command to start listening to one or more channels. The syntax is as follows:

SUBSCRIBE channel [channel …]

channel: The name of the channel to subscriber is going to subscribe.

Example:

SUBSCRIBE chat:general

Note: In this example, the subscriber starts listening to the “chat:general” channel.

Receiving Messages

Once a subscriber is subscribed to one or more channels, it enters a listening state. As messages are published to the subscribed channels, they are pushed to the subscribers. Subscribers receive messages asynchronously as they are published.

When a message is received, it includes the following information:

Example:

messagechannel: chat:generaldata: “Hello, everyone!”

Unsubscribing

Subscribers can unsubscribe from specific channels using the UNSUBSCRIBE command. The syntax is similar to SUBSCRIBE:

UNSUBSCRIBE channel [channel …]

Example:

UNSUBSCRIBE chat:general

Note: In this example, the subscriber stops listening to the “chat:general” channel.

Patterns and Multiple Subscriptions:

Redis allows subscribers to use patterns when subscribing to channels. The PSUBSCRIBE command is used for pattern-based subscriptions. Patterns are specified using wildcards, such as * and ?. Subscribers will receive messages from all channels matching the specified pattern.

Example:

PSUBSCRIBE chat:*

In this example, the subscriber listens to all channels that match the “chat:*” pattern. Multiple subscribers can listen to the same channel simultaneously. When a message is published to that channel, all subscribers receive a copy of the message.

Message Delivery:

Messages sent by publishers to channels are typically delivered to all subscribers listening to those channels. Redis guarantees that messages are delivered in the order they are published within a single channel and if a subscriber is temporarily unavailable (e.g., disconnected), it won’t receive messages sent during that period. However, Redis does not persist messages, so they are not recoverable once delivered.

Scalability and Persistence:

Redis Pub/Sub is a lightweight messaging system suitable for real-time applications. However, it’s important to note that Redis does not persist Pub/Sub messages by default. If you require message persistence or more advanced features, consider using additional technologies or combining Redis Pub/Sub with other Redis features.

Use Cases for Redis Pub/Sub

Benefits for Redis Pub/Sub

Key commands, syntax, and examples for Redis Publish-Subscribe

1. SUBSCRIBE

Subscribes to one or more channels to receive messages from those channels.

Syntax:

SUBSCRIBE channel [channel …]

Example:

SUBSCRIBE news sports

Output:

subscribe news subscribe sports

2. UNSUBSCRIBE

Unsubscribes from one or more channels. If no channels are provided, the client unsubscribes from all channels.

Syntax:

UNSUBSCRIBE [channel …]

Example:

UNSUBSCRIBE news sports

Output:

unsubscribe news unsubscribe sports

3. PUBLISH

Publishes a message to a specific channel, and all subscribers to that channel receive the message.

Syntax:

PUBLISH channel message

Example:

PUBLISH news “Breaking news: Redis is awesome!”

Output:

(integer) 1 (The number of subscribers to the channel)

4. PSUBSCRIBE

Subscribes to channels based on a pattern. It allows subscribing to multiple channels that match the specified pattern.

Syntax:

PSUBSCRIBE pattern [pattern …]

Example:

PSUBSCRIBE news.*

Output:

psubscribe news.*

5. PUNSUBSCRIBE

Unsubscribes from channels matching the specified pattern(s).

Syntax:

PUNSUBSCRIBE [pattern …]

Example:

PUNSUBSCRIBE news.*

Output:

punsubscribe news.*

6. PUBSUB CHANNELS

Lists the active channels matching the optional pattern.

Syntax:

PUBSUB CHANNELS [pattern]

Example:

PUBSUB CHANNELS news sports*

Output:

news sports

7. PUBSUB NUMSUB

Returns the number of subscribers for one or more specified channels.

Syntax:

PUBSUB NUMSUB [channel …]

Example:

PUBSUB NUMSUB news sports

Output:

1 1

Redis Pub/Sub Applications

Real Time notification application:

A real-time notification application is a common use case for Redis Pub/Sub (Publish/Subscribe) due to its ability to deliver messages instantly to multiple subscribers. In a real-time notification system, Redis Pub/Sub can be used to broadcast notifications to online users or connected clients whenever specific events occur.

Components of a Real-Time Notification Application:

  1. Publishers: These are components of your application responsible for generating events or notifications. They publish these events to specific channels or topics.
  2. Subscribers: Subscribers are users or client applications interested in receiving notifications about specific events. They subscribe to channels or topics of interest.
  3. Redis Server: Redis acts as the central messaging broker. It manages channels, messages, and the communication between publishers and subscribers.

How Redis Pub/Sub Powers Real-Time Notifications:

1. Channel Creation

In a real-time notification application, channels are created to represent different types of events or notifications. For example, you might have channels for user sign-ins, new messages, friend requests, and more.

2. Publishing Events

When an event occurs, the relevant part of your application publishes a message to the appropriate channel using the PUBLISH command in Redis. The message typically contains information about the event or notification.

PUBLISH channel_name message_data

3. Subscribing to Channels

Users or client applications subscribe to the channels they are interested in. For example, a user might subscribe to the “friend_requests” and “new_messages” channels.

SUBSCRIBE channel_name

4. Receiving Notifications

Once subscribed, users receive notifications in real-time whenever a message is published to the channels they are subscribed to. Redis automatically delivers messages to all connected subscribers of a channel.

5. Unsubscribing

Users can unsubscribe from channels when they are no longer interested in receiving notifications about specific events. This reduces unnecessary message delivery.

UNSUBSCRIBE channel_name

6. Pattern Subscriptions:

Redis also supports pattern subscriptions. Users can subscribe to channels using wildcards to receive notifications that match a specific pattern. For instance, subscribing to “user_*” would match all channels related to user events.

PSUBSCRIBE pattern

Real Time Sensor Updates application:

Redis Pub/Sub has a real-world application called “Real-Time Sensor Updates”. Redis Pub/Sub is implemented in this application to support distributed real-time communication and data distribution between sensors (producers) and consumers or data processing systems (subscribers). Let’s take a closer look at this application:

Application Overview:

How Redis Pub/Sub is Used:

Key Components:

Workflow

Sensor Data Collection

Subscriber Interest

Based on their interests, consumer apps or systems subscribe to the Redis channels. For instance, a temperature monitoring dashboard may simply subscribe to the “temperature-sensors” channel, whereas an analytics engine may subscribe to all sensor data channels.

Real-Time Data Delivery

As soon as sensor data is published to a channel, Redis ensures that all subscribers to that channel receive the data in real-time. This allows consumers to react immediately to changes in sensor readings.

Data Processing and Visualization

Scalability and Distribution

Redis Pub/Sub scales horizontally, allowing you to add more sensors and subscribers as your system grows. You can also use Redis Sentinel or Redis Cluster to achieve high availability and fault tolerance.

How Redis Publish Subscribe works in Chat Applications?

A typical Redis Pub/Sub use case is for chat applications. Through text-based messaging, these programmes enable real-time communication between users. Redis Pub/Sub is essential for facilitating the transmission of instant messages and maintaining a responsive chat experience. Here’s a detailed explanation of how chat programmes use Redis Pub/Sub:

How Redis Pub/Sub is Used:

Redis Pub/Sub is employed in chat applications to achieve real-time messaging. Here’s how it works:

Key Components:

Workflow:

Conclusion

Redis Pub/Sub is a valuable feature for implementing real-time and event-driven communication in Redis-based applications. It’s lightweight, easy to set up, and suitable for various use cases where asynchronous messaging is needed. However, understanding its capabilities and limitations is essential to make informed decisions when designing your messaging architecture.


Article Tags :