การเผยแพร่และสมัครรับข้อมูลในรีดิสเพื่อทำให้แคชเป็นโมฆะ

Imagine you have multiple copies of your application running, all using a local cache. When data changes in the database, how do you tell all these application instances to update their caches immediately?

Redis Publish/Subscribe (Pub/Sub) is a powerful messaging pattern that allows you to send real-time notifications to multiple clients, making it perfect for distributed cache invalidation.

While Time-To-Live (TTL) is great for automatically expiring old data, it doesn't guarantee instant freshness. If critical data changes, you don't want to wait for the TTL to expire.

Pub/Sub provides a way to force immediate invalidation. When data is updated in your primary data store (like a database), one application instance can broadcast a message, and all other instances listening will receive it and invalidate their specific cache entries.

In the Pub/Sub model, a Publisher is an entity (like one of your application instances) that sends messages to a specific channel.

• When a significant data change occurs (e.g., a product's price is updated in the database), the application instance that made the change acts as a publisher.
• It doesn't care who receives the message, only that it's sent to the designated channel.

A Subscriber is an entity (another application instance) that listens for messages on one or more specific channels.

• All other application instances would be subscribers to the 'cache-invalidation' channel.
• When a message arrives on a channel they're subscribed to, they receive it and can then react, for example, by removing the corresponding item from their local cache.

Redis provides two main commands for Pub/Sub:

• PUBLISH channel message: Sends message to the specified channel. All subscribers to that channel will receive it.
• SUBSCRIBE channel [channel ...]: This client subscribes to one or more channels. Once subscribed, it will continuously listen for messages.

Remember, Pub/Sub messages are fire-and-forget; Redis doesn't store them.

Here's how an application instance can publish an invalidation message using Java and the Jedis client. This example sends a message to invalidate a specific product.

Subscribers use a special listener class to handle incoming messages. The onMessage method is where your invalidation logic goes.

Note: The jedis.subscribe() call is blocking and keeps the connection open to listen. In a real app, this runs in a dedicated thread.

Let's see the full picture:

1. App A updates a product in the database.
2. App A publishes an invalidation message ('invalidate:product:456') to the 'product-updates' channel in Redis.
3. Redis receives the message and broadcasts it to all clients subscribed to 'product-updates'.
4. App B, App C (and App A itself if subscribed) receive the message.
5. Each app's subscriber logic removes 'product:456' from its local cache, ensuring fresh data on next request.

What should you include in your invalidation message?

• Specific Key: 'invalidate:user:123' is ideal for precise invalidation.
• Category: 'invalidate:all:products' for broader invalidation (use with caution).
• Timestamp/Version: Can help subscribers decide if their cached data is older than the update.

Keep messages concise. Subscribers should have enough info to know what to invalidate.

Benefits:

• Real-time: Immediate cache updates across instances.
• Decoupled: Publishers don't need to know about subscribers.
• Scalable: Redis handles message distribution efficiently.

Considerations:

• No Persistence: If a subscriber is offline, it misses messages.
• At-Most-Once: Redis Pub/Sub doesn't guarantee delivery. For critical systems, consider other messaging patterns or a combination.

You've learned how Redis Pub/Sub helps with real-time cache invalidation. Let's test your understanding!

Great job! You've explored how Redis Publish/Subscribe is a vital tool for maintaining data freshness in distributed caching environments.

• Pub/Sub allows real-time broadcasting of invalidation messages.
• Publishers send messages, and subscribers listen to channels.
• This pattern enables immediate cache updates across all application instances when data changes, improving consistency and user experience.
• While powerful, remember its 'fire-and-forget' nature and consider persistence needs for critical systems.