46

What are the pros and cons of each? Please advice when to use one and not the other.

Tando
  • 715
  • 1
  • 7
  • 16

1 Answers1

89

Data storage

Pub/Sub is a Publisher/Subscriber platform, it's not data storage. Published messages evaporate, regardless if there was any subscriber.

In Redis Streams, stream is a data type, a data structure on its own right. Messages or entries are stored in memory and stay there until commanded to be deleted.

Sync/Async communication (Push/Pull)

Pub/Sub is synchronous communication (push protocol). All parties need to be active at the same time to be able to communicate. Here Redis is a pure synchronous messaging broker.

Redis Streams allow for both synchronous (XREAD with BLOCK and the special $ ID is a push protocol) and asynchronous communication (regular XREAD is a pull protocol). XREAD with BLOCK is like Pub/Sub, but with the ability to resume on disconnection without losing messages.

Delivery Semantics

Pub/Sub is At-most-once, i.e. "fire and forget".

Redis Streams allows for both At-most-once or At-least-once (explicit acknowledgement sent by the receiver)

Blocking mode for consumers

Pub/Sub is blocking-mode only. Once subscribed to a channel, the client is put into subscriber mode and it cannot issue commands (except for [P]SUBSCRIBE, [P]UNSUBSCRIBE, PING and QUIT), it has become read-only.

Redis Streams allows consumers to read messages in blocking mode or not.

Fan-out

Pub/Sub is fan-out only. All active clients get all messages.

Redis Streams allows fan-out (with XREAD), but also to provide a different subset of messages from the same stream to many clients. This allows scaling message processing, by routing different messages to different workers, in a way that it is not possible that the same message is delivered to multiple consumers. This last scenario is achieved with consumer groups.

Redis Streams provide many more features, like time-stamps, field-value pairs, ranges, etc. It doesn't mean you should always go for Streams. If your use-case can be achieved with Pub/Sub, it is better for you to use Pub/Sub then. With Streams, you have to care for memory usage.

LeoMurillo
  • 6,048
  • 1
  • 19
  • 34
  • Excellent answer! There're two minor problems: 1. since Redis might lose data when it's down, so Redis Stream cannot guarantee at-least-once. 2. when client subscribes to a channel, it can still issue some commands, such as UNSUBSCRIBE, PING, QUIT... – for_stack Dec 31 '19 at 08:28
  • 3
    Thanks for this and the rest of the help that you've been rendering lately here :) – Itamar Haber Dec 31 '19 at 14:18
  • 1
    @MarcusSmith this is about Redis Pub Sub, not about Google Pub Sub – LeoMurillo Mar 02 '21 at 16:26
  • @LeoMurillo My apologies! I definitely read this as Google Pub/Sub. Probably because my mind was on Google Pub/Sub at the time. I will edit my comment to reflect an alternative suggest for Google Pub/Sub instead of calling your answer incorrect. – Marcus Smith Mar 03 '21 at 17:59
  • 1
    Maybe alternatively look at Google Pub/Sub (as it solves some of the concerns here). 1. data doesn't "just evaporate" even if it hasn't been acknowledged. It does expire after 7 days, good for high-volume communication layer. 2.Google Pub/Sub is At-least-once and has the SLA to ensure that. 3. Google Pub/Sub also has filtering so that subscribers don't get everything. Ultimately Redis is more than a communication layer and offers different options based on your needs, where Google Pub/Sub is a very good communication layer, and just that. See [Google Pub/Sub](https://cloud.google.com/pubsub) – Marcus Smith Mar 03 '21 at 18:08
  • 1
    Just as an observation @LeoMurillo, data loss is largely dependent on how Redis is configured. There are multiple options; AOF, snapshots, Active-Active or master/slave clustering, Redis on flash, etc., that allow you to control data replication to meet the specific tolerance needs of your application. – InfoSponge Oct 28 '21 at 21:54
  • @InfoSponge true, yet somewhat orthogonal to the question. Most of those configurations affect replication or durability of keys, not affecting pubsub. For strong durability, worth looking at https://aws.amazon.com/memorydb/ – LeoMurillo Oct 28 '21 at 23:27
  • @LeoMurillo That's a fair point, my comment wasn't actually addressing the original question. I have no idea what prompted my response, honestly, other than a previous conversation regarding durability in Redis. I'll pay more attention next time. – InfoSponge Oct 30 '21 at 18:05