Сохранение сообщений в потоках

In messaging systems, persistence means messages aren't lost, even if the recipient isn't ready to receive them immediately.

Think of it like leaving a note on a fridge instead of shouting it to someone who might not be home. The note stays until it's read.

This is crucial for reliability in many applications.

Unlike some other Redis messaging features, Redis Streams are designed to be persistent. Every message (entry) you add to a stream is stored in Redis.

This storage acts like an append-only log. New entries are always added to the end, creating a historical record of events.

Every entry in a Redis Stream gets a unique Entry ID. This ID is automatically generated by Redis and consists of two parts:

• Timestamp (milliseconds): The time the entry was added.
• Sequence Number: A counter for entries added within the same millisecond.

Example: 1678886400000-0

We use the XADD command to add new entries to a stream. The * tells Redis to auto-generate the Entry ID, ensuring uniqueness and proper ordering.

Each entry also holds field-value pairs, like a mini-hash.

To read entries from a stream, we use the XREAD command. You specify the stream name and the ID from which to start reading.

Crucially, reading an entry does not remove it from the stream. It stays there for other consumers or for future review.

This is where Redis Streams significantly differ from Redis Pub/Sub (Publish/Subscribe).

• Streams: Messages are persistent. They are stored and can be read multiple times, even by consumers who connect later.
• Pub/Sub: Messages are ephemeral. They are delivered once to active subscribers and then disappear.

With Pub/Sub, if no client is subscribed to a channel when a message is published, that message is simply lost. There's no backlog or history.

It's like a live broadcast: if you're not tuned in, you miss it. This is great for real-time notifications where history isn't needed.

The automatically generated Entry IDs in Redis Streams guarantee strict chronological order. Messages are always stored and retrieved in the exact order they were added.

This is vital for applications where the sequence of events matters, such as logging, auditing, or event sourcing.

Choose Redis Streams when you need:

• Reliable Event Logs: A complete, ordered history of events.
• Message Replay: Ability for new consumers to process past events.
• Auditing & Analytics: Historical data for analysis.
• Decoupled Microservices: Services can process events at their own pace.

You're building an application that needs to ensure every event is processed, even if a consumer is temporarily offline. Which Redis feature is best suited for this requirement?

In this lesson, we explored the crucial aspects of Redis Streams: message persistence and guaranteed ordered delivery.

• Streams store all entries, forming an immutable log.
• Each entry has a unique, time-based ID ensuring strict order.
• This persistence and ordering are key differentiators from Redis Pub/Sub, making Streams ideal for reliable event processing and historical data.