缓存知识薄弱者咨询：多Spring MVC应用共享大Map数据最优方案

Hey there! Let's dig into your problem of sharing a large-scale Map across multiple Spring MVC applications. Since you mentioned you're less familiar with caching tech, I'll break this down clearly with practical, Spring-friendly solutions—starting with the best overall approach, then covering all other viable optimal options.

Hands down, Redis is the go-to choice here, especially for large-volume Map data. It's an in-memory data store built for distributed scenarios, integrates seamlessly with Spring, and handles big datasets efficiently. Here's how to implement it in your Spring MVC apps:

1. Add Spring Data Redis Dependency
   Pop this into your pom.xml (Maven) or build.gradle (Gradle):

   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-data-redis</artifactId>
   </dependency>
   

2. Configure Redis Connection
   Set up your Redis server details in application.properties:

   spring.redis.host=your-redis-server-ip
   spring.redis.port=6379
   spring.redis.password=your-password (if set)
   spring.redis.jedis.pool.max-active=20
   

3. Map-like Operations with Redis Hash
   Redis' Hash structure is perfect for mimicking a Java Map—each Hash key is your Map's key, and the Hash value is your Map's value. For large data, use efficient serialization (like Jackson or ProtoBuf) to reduce memory footprint:

   @Service
   public class SharedMapService {
       @Autowired
       private StringRedisTemplate redisTemplate;
       private final ObjectMapper objectMapper = new ObjectMapper();
   
       public void putToSharedMap(String key, Object value) throws JsonProcessingException {
           String jsonValue = objectMapper.writeValueAsString(value);
           redisTemplate.opsForHash().put("large-shared-map", key, jsonValue);
       }
   
       public Object getFromSharedMap(String key) throws JsonProcessingException {
           String jsonValue = (String) redisTemplate.opsForHash().get("large-shared-map", key);
           return objectMapper.readValue(jsonValue, Object.class); // Replace with your actual type
       }
   }
   

4. Key Considerations

   • For extra-large datasets, use a Redis Cluster with sharding to distribute data across nodes.
   • Enable Redis compression (like LZF) to cut down on network bandwidth and memory usage.
   • Set a TTL (time-to-live) only if your data needs to expire—otherwise, leave it as persistent.

Depending on your specific constraints (like budget, update frequency, or persistence needs), these alternatives work great too:

- Distributed Memory Grid (Hazelcast/Ignite) #

If you don't want to manage a separate Redis server, Hazelcast is an embedded distributed cache that lets Spring MVC apps form a cluster and share an IMap directly. It's ideal for real-time sharing and supports transactions.

• Quick Setup: Add Hazelcast dependency, configure a cluster in hazelcast.xml, then inject HazelcastInstance to get the shared map:

  @Service
  public class HazelcastSharedMapService {
      @Autowired
      private HazelcastInstance hazelcastInstance;
  
      public IMap<String, Object> getSharedMap() {
          return hazelcastInstance.getMap("large-shared-map");
      }
  }
  

• Pros: No separate server required, seamless Spring integration.
• Cons: Cluster node management can get complex for very large datasets; each app node uses local memory for the map.

- Shared Database + Local Caching #

If you need persistent storage for your Map, store key-value pairs in a database table (e.g., MySQL with columns key and value), then use a local cache (Caffeine or Guava Cache) in each Spring MVC app to reduce database hits.

• Implementation: Use Spring's @Cacheable annotation with Caffeine, and set up a scheduled job to refresh the cache periodically:

  @Service
  public class DbSharedMapService {
      @Autowired
      private KeyValueRepository repository;
      @Cacheable(value = "sharedMapCache")
      public Object getValue(String key) {
          return repository.findByKey(key).getValue();
      }
  
      @Scheduled(fixedRate = 3600000) // Refresh every hour
      @CacheEvict(value = "sharedMapCache", allEntries = true)
      public void refreshCache() {}
  }
  

• Pros: Data is persisted, easy to set up if you already have a database.
• Cons: Cache refresh introduces latency; database can become a bottleneck with frequent updates.

- Distributed File System + Local Cache #

For rarely updated large Maps, serialize the entire Map (using MessagePack for efficiency) and store it in a distributed file system like MinIO or HDFS. Each Spring MVC app loads the file into local cache on startup and refreshes it on a schedule.

• Pros: Low cost, no extra database/cache server needed.
• Cons: Not suitable for frequent updates; each app uses local memory for the full map.

- Spring Cloud Config (for Static/Low-Update Maps) #

If your Map is essentially static configuration (e.g., lookup tables that change once a month), store it as a YAML/JSON file in Spring Cloud Config. Each app pulls the config on startup and can refresh it via Spring Cloud Bus when updates happen.

• Pros: Fully integrated with Spring ecosystem, zero custom code needed.
• Cons: Only for low-update frequency scenarios; not ideal for dynamic data.

内容的提问来源于stack exchange，提问作者Avyaan