We are now, simply, Redis
When sending and receiving messages between two or more clients, there are two
common ways of looking at how the messages are delivered. One method, called push
messaging, causes the sender to spend some time making sure that all of the recipients
of the message receive it. Redis has built-in commands for handling push messaging
called PUBLISH and SUBSCRIBE, whose drawbacks and use we discussed in chapter 3.2
The second method, called pull messaging, requires that the recipients of the message
fetch the messages instead. Usually, messages will wait in a sort of mailbox for the
recipient to fetch them.
Though push messaging can be useful, we run into problems when clients can’t
stay connected all the time for one reason or another. To address this limitation, we’ll
write two different pull messaging methods that can be used as a replacement for PUBLISH/
We’ll first start with single-recipient messaging, since it shares much in common
with our first-in, first-out queues. Later in this section, we’ll move to a method where
we can have multiple recipients of a message. With multiple recipients, we can replace
Redis PUBLISH and SUBSCRIBE when we need our messages to get to all recipients,
even if they were disconnected.
2 Briefly, these drawbacks are that the client must be connected at all times to receive messages, disconnections
can cause the client to lose messages, and older versions of Redis could become unusable, crash, or be killed
if there was a slow subscriber.
TRY REDIS ENTERPRISE CLOUD FREE
Redis Enterprise Cloud provides complete automation of day-to-day database operations. Start now with 30MB of free storage.
© 2021 Redis. Redis and the cube logo are registered trademarks of Redis Ltd.