0Pricing
Caching Strategies: Redis + CDN + Edge Computing · Lezione

Redis Pub/Sub per l'invalidazione

Esplori l'uso di Redis Publish/Subscribe per invalidare in tempo reale la cache tra più istanze dell'applicazione.

Redis Pub/Sub per l'invalidazione è una lezione Caching Strategies: Redis + CDN + Edge Computing gratuita su CoddyKit. Questa è la lezione 3 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento Caching Strategies: Redis + CDN + Edge Computing, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso Caching Strategies: Redis + CDN + Edge Computing include 4 lezioni in totale.

Parti di questa lezione non sono ancora state tradotte e vengono mostrate in inglese.

Real-time Cache Updates

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.

Beyond Time-To-Live (TTL)

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.

The Publisher Role

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.

The Subscriber Role

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 Pub/Sub Commands

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.

Publishing a Cache Invalidation

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.

import redis.clients.jedis.Jedis;

public class CachePublisher {
  public static void main(String[] args) {
    // Connect to Redis (default localhost:6379)
    Jedis jedis = new Jedis("localhost", 6379);

    String channel = "product-updates";
    String message = "invalidate:product:456"; // Key to invalidate

    // Publish the message
    jedis.publish(channel, message);
    System.out.println("Published: '" + message + "' to channel '" + channel + "'");

    // Close the connection
    jedis.close();
  }
}

Setting Up a Cache Subscriber

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.

import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPubSub;

public class CacheSubscriberSetup {
  public static void main(String[] args) {
    System.out.println("Preparing Redis Pub/Sub subscriber...");

    // Define your listener logic
    JedisPubSub listener = new JedisPubSub() {
      @Override
      public void onMessage(String channel, String message) {
        System.out.println("Received: '" + message + "' on channel '" + channel + "'");
        // Here, you would implement your cache invalidation logic
        // e.g., myLocalCache.remove(message.split(":")[1]);
      }

      @Override
      public void onSubscribe(String channel, int subscribedChannels) {
        System.out.println("Successfully subscribed to: " + channel);
      }
      // Other methods like onUnsubscribe, onPMessage, etc., can be overridden
    };

    // In a real application, you'd run:
    // try (Jedis jedis = new Jedis("localhost", 6379)) {
    //   jedis.subscribe(listener, "product-updates"); // This blocks!
    // }
    System.out.println("Subscriber listener defined. To truly listen, run a blocking subscribe call.");
    System.out.println("This runnable example exits to demonstrate setup.");
  }
}

End-to-End Invalidation Flow

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.

Designing Invalidation Messages

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.

Pros and Cons of Pub/Sub

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.

Pub/Sub Invalidation Quiz

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

Pub/Sub for Fresh Data

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.

Domande Frequenti

La lezione «Redis Pub/Sub per l'invalidazione» è gratuita?

Sì — il testo completo di «Redis Pub/Sub per l'invalidazione» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso Caching Strategies: Redis + CDN + Edge Computing, passa a CoddyKit PRO. Il corso Caching Strategies: Redis + CDN + Edge Computing include 4 lezioni in totale.

Cosa imparerò in «Redis Pub/Sub per l'invalidazione»?

Esplori l'uso di Redis Publish/Subscribe per invalidare in tempo reale la cache tra più istanze dell'applicazione. Eserciti Caching Strategies: Redis + CDN + Edge Computing con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.

Ho bisogno di esperienza per iniziare Caching Strategies: Redis + CDN + Edge Computing?

Non è richiesta alcuna esperienza precedente. Caching Strategies: Redis + CDN + Edge Computing su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 3 di 4.

Quanto tempo richiede la lezione «Redis Pub/Sub per l'invalidazione»?

La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.

Posso scrivere ed eseguire codice in questa lezione Caching Strategies: Redis + CDN + Edge Computing?

Sì. Ogni lezione Caching Strategies: Redis + CDN + Edge Computing include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.

Tutte le lezioni di questo corso

  1. Persistenza e alta disponibilità di Redis
  2. Caching distribuito con Redis
  3. Redis Pub/Sub per l'invalidazione
  4. Redis Cluster e sharding
← Torna a Caching Strategies: Redis + CDN + Edge Computing