Pub/sub
Subscriptions, cancellations and releases implement the Publish/Subscribe message paradigm (quoted from Wikipedia), where the sender (publisher) is not planning to send a message to a specific recipient (subscriber). Instead of distributing the messages to different channels, you don't need to know what subscribers subscribe to them. Subscribers are interested in one or more channels, just receive messages of interest and do not need to know what publishers are publishing them. This decoupling between publishers and Subscribers can lead to greater scalability and a more dynamic network topology.
F to subscribe to Foo and bar, the client issues a subscription channel name:
SUBSCRIBE foo bar
Messages sent to these channels by other clients will be pushed to all subscribed clients.
A client subscribing to one or more channels does not have to issue commands, although he can subscribe to and unsubscribe from other channels. The response to the subscription and unsubscribe is encapsulated in the message being sent so that the client only needs to read a continuous message flow, where the first element represents the message type.
Format of the push message
The message is a multi-block response with three elements.
The first element is a message type:
subscribe
: Indicates that we successfully subscribed to the channel provided by the second element of the response. The third parameter represents the number of channels that we subscribe to now.
unsubscribe
: Indicates that we successfully unsubscribe to the channel provided by the second element of the response. The third parameter represents the number of channels we currently subscribe to. When the last parameter is 0, we no longer subscribe to any channel. When we are outside the Pub/sub state, the client can issue any Redis command.
message
: This is the result of a publishing command issued by another client. The second element is the name of the source channel, and the third parameter is the content of the actual message.
Message Protocol Example
SUBSCRIBE first second*3$9subscribe$5first:1*3$9subscribe$6second:2
At this point, we issue a publish operation on the channel name second from another client:
> PUBLISH second Hello
This is the first client to receive:
*3$7message$6second$5Hello
The client now cancels the subscription to all channels with the unsubscribe command without any parameters:
UNSUBSCRIBE*3$11unsubscribe$6second:1*3$11unsubscribe$5first:0
Pattern Matching Subscription
The pub/sub implementation of Redis supports pattern matching. A client can subscribe to a full-style pattern to receive all messages from a channel that can match to a given pattern.
Like what:
PSUBSCRIBE news.*
will receive all messages sent to News.art.figurative, News.music.jazz, and so on, all modes are valid, so multiple wildcard characters are supported.
PUNSUBSCRIBE news.*
The client that matches the pattern will be unsubscribed, and this call does not affect other subscriptions.
Messages that are treated as pattern matching results are sent in different formats:
- The message type is pmessage: This is the result of the Publish command issued by another client, matching a pattern matching subscription. The first element is the original matching pattern, the third element is the original channel name, and the last element is the actual message content.
Similarly, the system defaults SUBSCRIBE and Unsubscribe, Psubscribe and Punsubscribe commands are used like Psubscribe and punsubscribe when sending messages of SUBSCRIBE and Unsubscrib types e-like message format.
Simultaneous matching of patterns and channel subscription messages
The client may receive a message multiple times if it subscribes to multiple patterns that match the same published message, or it subscribes to a pattern and channel that matches simultaneously to a message. Just like the following example:
SUBSCRIBE fooPSUBSCRIBE f*
In the above example, if a message is sent to Foo, the client receives two messages: A message type, a pmessage type.
The significance of pattern matching statistics
In subscribe, unsubscribe, Psubscribe, and Punsubscribe message types, the last parameter is the number of subscriptions that are still active. This number is the total number of channels and modes that the client still subscribes to. The client exits the Pub/sub state only when the number of unsubscribe channels and modes drops to 0 o'clock.
Examples of programs:
Peter Noordhuis provides a great example of creating multi-user high-performance web chats using Eventmachine and Redis.
Client Library Implementation Tips
Because all the received messages contain the original subscription leading to the message delivery (which is the channel, the Pmessage type is the original mode), the client library may bind the original subscription to the callback method (possibly anonymous function, block, function pointer), using hash table. When a message is received, it is possible to find a time complexity of O (1) to pass the message to the registered callback.
Redis Tutorial 03--redis Publish/Subscribe (PUB/SUB)