e-Book - Redis in Action

This book covers the use of Redis, an in-memory database/data structure server.
  • Foreword
  • Preface
  • Acknowledgments
  • About this Book
  • About the Cover Illustration
  • Part 1: Getting Started
  • Part 2: Core concepts
  • Part 3: Next steps
  • Appendix A
  • Appendix B
  • Buy the paperback

    6.5 Pull messaging

    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/
    SUBSCRIBE.

    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.