preface

As for Redis’s “starting and closing”, I have already made a detailed exposition of the basic Redis – “starting” in five chapters. I believe that you can learn a lot from Redis regardless of whether you have touched it before. The content of the basic chapter, as the name implies, is just a foundation, mainly said the development of Redis and the basic data types of Redis, the content and the usual use of the association will be relatively large, not too difficult, I hope you can digest. Here are the plane tickets for the basics:

[From] Overview of Redis – take you through the past life of Redis

[正] Redis foundation – Basic data structure String, Hash

【 英 】Redis foundation – basic data structure List, Set

[正] Redis – Basic data structure ZSet, Bitmap…

[From] Redis Foundation – summary of basic data structure

In the “Commitment” part, I will focus on the principles of Redis and talk about some relatively advanced features, such as pub/ SUB (publish/subscribe), persistence, high performance features, transactions, memory reclamation, etc. In the next part, I will lay the groundwork for you. Let’s string together the content of each chapter, so I don’t want to take up your preface.

Anyway, let’s take a look today at the Redis publish/subscribe model.

The body of the

Publish/subscribe

Limitations of lists

Earlier we said that message queues can be implemented through rpush and LPOP of queues, but consumers need to constantly call LPOP to see if there are any messages waiting to be processed in the List (such as writing a while loop).

In order to reduce communication consumption, we can sleep() for a period of time and then consume, but there are two problems:

1. If producers can produce messages much faster than consumers can consume them, lists can take up a lot of memory.
2. The real-time performance of messages decreases;

The list also provides a blocking command: blpop, which blocks the connection if there are no elements to pop.

blpop queue 5
Copy the code

Message queues based on lists do not support one-to-many message distribution.

Publish and subscribe model

In addition to implementing message queues through lists, Redis also provides a set of commands to implement the publish/subscribe pattern. In this way, the sender and receiver are not directly related (achieving decoupling), and the receiver does not need to constantly try to get the message.

Subscribe to the channel

First of all, we have a bunch of channels, which we can also think of as queues.

Subscribers can subscribe to one or more channels.

Message publishers (producers) can publish messages to specific channels.

As soon as a message arrives on a channel, all subscribers to that channel will receive the message.

Note that the outgoing message is not persisted because it has been removed from the queue, so the consumer can only receive messages published after it started subscribing to the channel.

Let’s look at the use of the publish subscribe command.

Subscribers subscribe to channels: You can subscribe to more than one channel at a time, such as this client subscribing to 3 channels.

subscribe channel-1 channel-2 channel-3
Copy the code

Publishers can publish messages to specific channels (sending messages to multiple channels at once is not supported) :

publish channel-1 2673
Copy the code

Unsubscribe (cannot be used while subscribed) :

unsubscribe channel-1
Copy the code

Subscribe channels according to the Pattern

Support? And * placeholders. ? * indicates one character, and * indicates zero or more characters.

Consumer 1: Pay attention to sports information:

psubscribe *sport
Copy the code

Consumer side 2, follow all the news:

psubscribe news*
Copy the code

Consumer side 3: Pay attention to weather news:

psubscribe news-weather
Copy the code

Producer, publish 3 messages

publish news-sport yaoming
publish news-music jaychou
publish news-weather rain
Copy the code