Redisson provides two primary ways to interact with Redis maps:

1. RMap / RMapCache – directly interacts with Redis, network calls for every operation.
2. RLocalCachedMap – keeps a local copy of the map in memory, reducing network overhead while still synchronizing with Redis in the background.

This tutorial focuses on RLocalCachedMap, which is ideal for scenarios with multiple microservices or application instances that need fast local access and eventual consistency.

---

1. Overview of RLocalCachedMap

RLocalCachedMap is a map where:

• A local in-memory copy of the Redis hash is maintained per instance.
• Network calls are minimized; reading from local memory is fast.
• Updates are propagated asynchronously to Redis and optionally to other local caches.
• Useful in multi-instance applications where each instance frequently reads data.

Key Concepts

• Local copy: Each instance keeps its own copy of the map in memory.
• Asynchronous updates: Changes are sent to Redis and optionally propagated to other instances.
• Sink strategies: Determine how updates are handled across multiple instances.

---

2. Creating a Local Cached Map

import org.redisson.api.LocalCachedMapOptions;
import org.redisson.api.RLocalCachedMap;
import org.redisson.api.RedissonClient;

public class LocalCacheMapExample {

    private RLocalCachedMap<Integer, Student> studentsMap;

    public void setup(RedissonClient redisson) {
        // Configure local cache map options
        LocalCachedMapOptions<Integer, Student> options = LocalCachedMapOptions.defaults()
            .timeToLive(10, TimeUnit.SECONDS); // local copy TTL

        // Create the local cached map
        studentsMap = redisson.getLocalCachedMap(
            "studentsMap", 
            options
        );
    }
}

Explanation:

• timeToLive – how long the local copy is valid before being invalidated and refreshed from Redis.
• Key type: Integer, Value type: Student.
• Map updates propagate to Redis automatically.

---

3. Sink Strategies

Sink strategies determine how updates in one instance are reflected in others. There are three main types:

1. UPDATE (default)
   • Changes in one instance are propagated to Redis and other instances.
   • Other instances update their local caches automatically.
2. INVALIDATE
   • Other instances invalidate their local copy when an update occurs.
   • Next read triggers a refresh from Redis.
   • Reduces network overhead for high-frequency updates.
3. NONE
   • Local copies do not receive updates from other instances.
   • Useful for read-heavy caches where updates are rare or network interruptions are frequent.

---

4. Example: Multi-Instance Scenario

Imagine two observers (applications) sharing the same map.

Setup Observer 1

studentsMap.put(1, new Student("Alice", 15, "Atlanta"));
studentsMap.put(2, new Student("Jake", 20, "Miami"));

Setup Observer 2

// Observer 2 starts with the same initial map
studentsMap.put(1, new Student("Alice", 15, "Atlanta"));
studentsMap.put(2, new Student("Jake", 20, "Miami"));

Updates and Local Cache Behavior

1. With UPDATE strategy:
   • If Observer 1 updates Student 1’s age to 16, Observer 2 automatically receives the update in its local cache.
2. With INVALIDATE strategy:
   • Observer 2’s local copy of Student 1 is invalidated but not updated.
   • The next get(1) fetches the latest data from Redis.
3. With NONE strategy:
   • Observer 2’s local copy remains unchanged, regardless of Observer 1’s updates.
   • Useful when each instance can tolerate slightly stale data.

---

5. Handling Network Failures

RLocalCachedMap handles Redis downtime gracefully:

• Reads are served from the local cache even if Redis is temporarily unavailable.
• Updates are queued until connectivity is restored.
• Once Redis is back online:
  • Local caches are refreshed based on the sink strategy.
  • CLEAR strategy can be used to remove stale local data and fetch fresh data from Redis.

Example Scenario:

1. Observer 1 continues reading while Redis is down.
2. Observer 2 updates a student’s data.
3. Observer 1 serves its local cache until Redis is restored.
4. Once Redis reconnects, Observer 1 refreshes its local cache automatically.

---

6. Running a Local Cache Map Test

// Periodically print local cache values
ScheduledExecutorService scheduler = Executors.newScheduledThreadPool(1);
scheduler.scheduleAtFixedRate(() -> {
    System.out.println("Student 1: " + studentsMap.get(1));
    System.out.println("Student 2: " + studentsMap.get(2));
}, 0, 1, TimeUnit.SECONDS);

• Prints data every second.
• Demonstrates how local cache responds to updates and TTL expiration.

---

7. Summary

RLocalCachedMap provides:

• High-performance local caching with Redis as the backend.
• Flexible sink strategies for update propagation across instances.
• Robustness during network interruptions.
• TTL-based local cache invalidation for automatic refresh from Redis.

Use Cases:

• Multi-service applications where frequent reads occur.
• Applications needing temporary local copies to reduce network latency.
• Scenarios where consistency across instances can be tuned using sink strategies.

---

This setup allows multiple instances to work efficiently with local copies while ensuring eventual consistency with Redis.