Menu
What are the pros and cons of each? Please advice when to use one and not the other.
374
Conceptually, a Stream in Redis is a list where you can append entries. Each entry has a unique ID and a value. The ID is auto-generated by default, and it includes a timestamp. The value is a hash. You can query ranges or use blocking commands to read entries as they come.
Redis Pub/Sub is the oldest style of messaging pattern supported by Redis and uses a data type called a “channel,” which supports typical pub/sub operations, such as publish and subscribe. It's considered loosely coupled because publishers and subscribers don't know about each other.
Pub/Sub is a scalable, durable event ingestion and delivery system. Dataflow compliments Pub/Sub's scalable, at-least-once delivery model with message deduplication, exactly-once processing, and generation of a data watermark from timestamped events.
Redis Pub/Sub implements the messaging system where the senders (in redis terminology called publishers) sends the messages while the receivers (subscribers) receive them. The link by which the messages are transferred is called channel. In Redis, a client can subscribe any number of channels.
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.
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.
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)
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.
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.
92
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
