Cache architecture design & Spring's abstract architecture for Cache

Table of contents

Cache architecture design

JSR107

JSR107 core interface

JSR107 icon

Spring's abstract architecture for Cache

introduce

@Cacheable

@CachePut

@CacheEvict

@CacheConfig

---

• Cache architecture design

• JSR107

• First, let's take a look at the JSR107 specification
• JSR is the abbreviation of Java Specification Requests, the Java specification request, as the name implies, submits the Java specification
• JSR-107 is the specification on how to use the cache. It is an interface specification provided by java. It is similar to the JDBC specification. There is no specific implementation. The specific implementation is these caching solutions such as ehcache

• JSR107 core interface

• Java Caching (JSR-107) defines five core interfaces, namely CachingProvider, CacheManager, Cache, Entry and Expiry
  • CachingProvider (cache provider): create, configure, obtain, manage and control multiple CacheManagers
  • CacheManager (cache manager): Create, configure, obtain, manage and control multiple uniquely named Cache, Cache exists in the context of CacheManager; a CacheManager corresponds to only one CachingProvider
  • Cache (cache): It is managed by CacheManager, which manages the life cycle of Cache. Cache exists in the context of CacheManager, which is a data structure similar to map, and temporarily stores the value indexed by key; a Cache is only used by one CacheManager owned by
  • Entry (cache key-value pair): is a key-value pair stored in the Cache
  • Expiry (cache aging): Each entry stored in the Cache has a defined validity period; once this time is exceeded, the entry will automatically expire. After the expiration, the entry will not be able to access, update and delete operations; the cache validity period can be passed ExpiryPolicy settings

• JSR107 icon

  

• There can be multiple cache providers (CachingProvider) in an application, and one cache provider can obtain multiple cache managers (CacheManager)
• A cache manager manages different caches (Cache), each cache key-value pair (Entry), each entry has an expiration date (Expiry)
• The relationship between the cache manager and the cache is somewhat similar to the relationship between the connection pool and the connection in the database
• Dependencies that need to be imported to use JSR-107:

  

• Spring's abstract architecture for Cache

• introduce

• Important cache annotations and several important concepts provided by Spring:

  

• The method of use is to add the @EnableCaching annotation to the startup class to enable the caching function
• Then you can use the above annotations on the method to use the cache
• Here are a few important notes to explain

• @Cacheable

• Cache the result of the method operation, and when the same data is obtained later, it will be obtained directly from the cache without calling the method
• An example of use is as follows:

  

• Attributes of the @Cacheable annotation:

  

• Notice:
  • Neither the condition nor the unless condition will be cached
  • When using asynchronous mode for caching (sync=true): the unless condition will not be supported
• The available SpEL expressions are listed in the table below:

  

• @CachePut

• Description: It not only calls the method, but also updates the cache data, generally used for update operations
• When updating the cache, it must have the same cache name and the same key as the cache you want to update (similar to the same data in the same table)
• Examples are as follows:

  

• @CacheEvict

• Description: Clear the cache. When clearing the cache, specify the name and key of the cache, which is equivalent to telling the database which data in which table to delete. The key defaults to the value of the parameter
• Note: the allEntries attribute refers to whether to clear all key-value pairs in the specified cache. The default is false. When it is set to true, all key-value pairs in the cache will be cleared. It can be used with the key attribute.
• beforeInvocation refers to clearing the specified cache before the @CacheEvict annotated method call, the default is false, that is, clearing the cache after the method call
• When set to true, the cache will be cleared before the method call (the difference between clearing the cache before or after the method call is whether there will be an exception when the method is called. If there is no exception, there is no difference between the two settings. If there is an exception, set to Clearing the cache after the method call won't work because the method call failed)
• Example:

  

• @CacheConfig

• Function: Mark on the class to extract the public configuration of the cache-related annotations. The extractable public configurations include the cache name, primary key generator, etc. (as shown in the attributes in the annotation):

  

• Example: After specifying the name of the cache through the cacheNames attribute of @CacheConfig, other cache annotations in this class do not need to write value or cacheName, and will use the name as the value of value or cacheName, and of course follow the principle of proximity: