Java多应用共享缓存方案及批量刷新需求咨询

Hey there, let's break down your problem and walk through practical, maintainable solutions that fit your needs.

Can we share an underlying cache across all 10 apps to sync refreshes? #

Absolutely! This is exactly what distributed caches are designed for. Instead of each app using its own private local cache (like Caffeine or Guava Cache), you can switch to a centralized distributed cache system such as Redis or Memcached.

All 10 apps would configure their Spring CacheManager to point to this shared distributed cache cluster. When you refresh or invalidate a cache entry in this centralized store, every app will automatically fetch the latest data on their next request—no need to update each app individually.

The best part? You won’t have to rewrite your existing @Cacheable annotation logic. Spring Cache abstracts the underlying cache provider, so switching to a RedisCacheManager (for example) just requires a few configuration changes in each app’s application.properties or configuration class.

How to implement your two core requirements #

1. Auto-refresh cache when MySQL table data changes #

You’re right that using MySQL triggers to execute Java code is a terrible idea—it creates tight coupling between your database and application layer, is hard to debug, and can degrade database performance. Instead, use a binlog listening approach:

• Use tools like Canal or Debezium to monitor MySQL’s binary log. These tools detect any insert/update/delete operations on your target metadata table in real time.
• Configure the tool to send a notification (e.g., to a message broker like Kafka or RabbitMQ) whenever a change is detected.
• Either have each app consume these notifications and invalidate the corresponding cache entries in the distributed cache, or use a dedicated service to handle the cache invalidation on behalf of all apps.

This approach is non-intrusive to your database and keeps your application logic decoupled.

2. Unified API for batch cache refresh #

With a distributed cache, this becomes trivial:

• Build a simple standalone Spring Boot service (or add an endpoint to an existing central service) that exposes a REST API endpoint (e.g., POST /refresh-metadata-cache).
• When this endpoint is called, it uses the distributed CacheManager to evict the relevant cache entries (using cacheManager.getCache("your-cache-name").evict("target-key")) or clear the entire cache (with clear() if appropriate).
• Since all apps share the same distributed cache, this single API call will invalidate the stale data for every application instantly.

If you absolutely can’t switch to a distributed cache (though I strongly recommend it), you’d need to:

• Add cache refresh endpoints to each of the 10 apps (exposing methods that call their local CacheManager to evict entries).
• Use service discovery (like Eureka or Nacos) to locate all running app instances.
• Have your unified API iterate over all discovered instances and call their refresh endpoints. However, this requires modifying each app to expose these endpoints, which you mentioned they currently don’t.

Final thoughts #

Your requirements are absolutely achievable—you just don’t need to use the problematic trigger approach. The distributed cache + binlog monitoring combo is the most scalable and maintainable solution here, as it eliminates the need to sync 10 separate private caches.

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