聊一聊JAVA中的缓存规范 —— 虽迟但到的JCache API与天生不俗的Spring Cache

系统管理员 2023-10-03 21:08 15阅读 0赞

##  ##

### 为何需要规范 ###

上一章中构建的最简化版本的缓存框架，虽然可以使用，但是也存在一个问题，就是它对外提供的实现接口都是框架根据自己的需要而自定义的。这样一来，项目集成了此缓存框架，后续如果想要更换缓存框架的时候，业务层面的改动会比较大。 —— 因为是自定义的框架接口，无法基于`里氏替换`原则来进行灵活的更换。

在业界各大厂商或者开源团队都会构建并提供一些自己实现的缓存框架或者组件，提供给开发者按需选择使用。如果大家都是各自**闭门造车**，势必导致业务中集成并使用某一缓存实现之后，想要更换缓存实现组件会难于登天。

![format_png][]

千古一帝秦始皇统一天下后，颁布了*书同文、车同轨*等一系列法规制度，使得所有的车辆都遵循统一的轴距，然后都可以在官道上正常的通行，大大提升了流通性。而正所谓“国有国法、行有行规”，为了保证缓存框架的通用性、提升项目的可移植性，JAVA行业也迫切需要这么一个**缓存规范**，来约束各个缓存提供商给出的缓存框架都遵循相同的规范接口，业务中按照标准接口进行调用，无需与缓存框架进行深度耦合，使得缓存组件的更换成为一件简单点的事情。

在JAVA的缓存领域，流传比较广泛的主要是`JCache API`和`Spring Cache`两套规范，下面就一起来看下。

![format_png 1][]

### 虽迟但到的JSR107 —— JCache API ###

提到JAVA中的“行业规矩”，`JSR`是一个绕不开的话题。它的全称为`Java Specification Requests`，意思是**JAVA规范提案**。在该规范标准中，有公布过一个关于JAVA缓存体系的规范定义，也即`JSR 107`规范（*JCache API*），主要明确了JAVA中基于内存进行对象缓存构建的一些要求，涵盖内存对象的*创建*、*查询*、*更新*、*删除*、*一致性保证*等方面内容。

**JSR107**规范早在`2012年`时草案就被提出，但却直到`2014年`才正式披露首个规范版本，也即`JCache API 1.0.0`版本，至此JAVA领域总算是有个正式的关于缓存的官方规范要求。

#### 揭秘JSR107 —— JCache API内容探究 ####

**JSR107**规范具体的要求形式，都以接口的形式封装在`javax.cache`包中进行提供。我们要实现的缓存框架需要遵循该规范，也就是需要引入*javax.cache*依赖包，并实现其中提供的相关接口即可。对于使用maven构建的项目中，可以在`pom.xml`中引入javax.cache依赖：

<dependency>
        <groupId>javax.cache</groupId>
        <artifactId>cache-api</artifactId>
        <version>1.1.1</version>
    </dependency>
    复制代码

在`JCache API`规范中，定义的缓存框架相关接口类之间的关系逻辑梳理如下：

![format_png 2][]

我们要实现自己的本地缓存框架，也即需要实现上述各个接口。对上述各接口类的含义介绍说明如下：

<table> 
 <thead> 
  <tr> 
   <th>接口类</th> 
   <th>功能定位描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>CachingProvider</td> 
   <td><strong>SPI接口</strong>，缓存框架的加载入口。每个<code>Provider</code>中可以持有1个或者多个<code>CacheManager</code>对象，用来提供不同的缓存能力</td> 
  </tr> 
  <tr> 
   <td>CacheManager</td> 
   <td>缓存管理器接口，每个缓存管理器负责对具体的缓存容器的创建与管理，可以管理1个或者多个不同的<code>Cache</code>对象</td> 
  </tr> 
  <tr> 
   <td>Cache</td> 
   <td><code>Cache</code>缓存容器接口，负责存储具体的缓存数据，可以提供不同的容器能力</td> 
  </tr> 
  <tr> 
   <td>Entry</td> 
   <td><code>Cache</code>容器中存储的<code>key-value</code>键值对记录</td> 
  </tr> 
 </tbody> 
</table>

作为通用规范，这里将`CachingProvider`定义为了一个**SPI接口**（`Service Provider Interface`，服务提供接口），主要是借助JDK自带的服务提供发现能力，来实现按需加载各自实现的功能逻辑，有点`IOC`的意味。这样设计有一定的好处：

*  **对于框架**：

需要遵循规范，提供上述接口的实现类。然后可以实现热插拔，与业务解耦。

*  **对于业务**：

先指定需要使用的`SPI`的具体实现类，然后业务逻辑中便无需感知缓存具体的实现，直接基于`JCache API`通用接口进行使用即可。后续如果需要更换缓存实现框架，只需要切换下使用的`SPI`的具体实现类即可。

根据上述介绍，一个基于**JCache API**实现的缓存框架在实际项目中使用时的对象层级关系可能会是下面这种场景（假设使用*LRU策*略存储部门信息、使用*普通策略*存储用户信息）：

![format_png 3][]

那么如何去理解`JCache API`中几个接口类的关系呢？

几个简单的说明：

1.  **CachingProvider**并无太多实际逻辑层面的功能，只是用来基于SPI机制，方便项目中集成插拔使用。内部持有CacheManager对象，实际的缓存管理能力，由CacheManager负责提供。
2.  **CacheManager**负责具体的缓存管理相关能力实现，实例由`CachingProvider`提供并持有，CachingProvider可以持有一个或者多个不同的`CacheManager`对象。这些CacheManager对象可以是相同类型，也可以是不同类型，比如我们可以实现2种缓存框架，一种是`基于内存`的缓存，一种是`基于磁盘`的缓存，则可以分别提供两种不同的*CacheManager*，供业务按需调用。
3.  **Cache**是CacheManager负责创建并管理的具体的缓存容器，也可以有一个或者多个，如业务中会涉及到为用户列表和部门列表分别创建独立的`Cache`存储。此外，Cache容器也可以根据需要提供不同的Cache容器类型，以满足不同场景对于缓存容器的不同诉求，如我们可以实现一个类似`HashMap`的普通键值对Cache容器，也可以提供一个基于`LRU`淘汰策略的Cache容器。

至此呢，我们厘清了**JCache API**规范的大致内容。

![format_png 4][]

#### 插叙 —— SPI何许人也 ####

按照`JSR107`规范试编写缓存具体能力时，我们需要实现一个**SPI接口**的实现类，然后由JDK提供的加载能力将我们扩展的缓存服务加载到JVM中供使用。

提到*API*我们都耳熟能详，也就是我们常规而言的接口。但说起**SPI**也许很多小伙伴就有点陌生了。其实SPI也并非是什么新鲜玩意，它是*JDK内置*的一种服务的**提供**与**发现**、**加载**机制。按照JAVA的面向对象编码的思想，为了降低代码的耦合度、提升代码的灵活性，往往需要利用好`抽象`这一特性，比如一般会比较推荐基于接口进行编码、而尽量避免强依赖某个具体的功能实现类 —— 这样才能让构建出的系统具有更好的扩展性，更符合面向对象设计原则中的`里式替换`原则。SPI便是为了支持这一诉求而提供的能力，它允许将接口具体的实现类交由业务或者三方进行独立构建，然后加载到JVM中以供业务进行使用。

为了这一点，我们需要在`resource/META-INF/services`目录下新建一个文件，文件名即为SPI接口名称`javax.cache.spi.CachingProvider`，然后在文件内容中，写入我们要注入进入的我们自己的**Provider**实现类：

![format_png 5][]

这样，我们就完成了将我们自己的`MyCachingProvider`功能注入到系统中。在业务使用时，可以通过`Caching.getCachingProvider()`获取到注入的自定义**Provider**。

public static void main(String[] args) {
        CachingProvider provider =  Caching.getCachingProvider();
        System.out.println(provider);
    }
    复制代码

从输出的结果可以看出，获取到了自定义的Provider对象：

com.veezean.skills.cache.fwk.MyCachingProvider@7adf9f5f
    复制代码

获取到`Provider`之后，便可以进一步的获取到`Manager`对象，进而业务层面层面可以正常使用。

![format_png 4][]

#### JCache API规范的实现 ####

**JSR**作为JAVA领域正统行规，制定的时候往往考虑到各种可能的灵活性与通用性。作为JSR中根正苗红的`JCache API`规范，也沿袭了这一风格特色，框架接口的定义与实现也非常的丰富，几乎可以扩展自定义任何你需要的处理策略。 —— 但恰是这一点，也让其整个框架的接口定义过于**重量级**。对于缓存框架实现者而言，遵循`JCache API`需要实现众多的接口，需要做很多额外的实现处理。

比如，我们实现`CacheManager`的时候，需要实现如下这么多的接口：

public class MemCacheManager implements CacheManager {
        private CachingProvider cachingProvider;
        private ConcurrentHashMap<String, Cache> caches;
        public MemCacheManager(CachingProvider cachingProvider, ConcurrentHashMap<String, Cache> caches) {
            this.cachingProvider = cachingProvider;
            this.caches = caches;
        }
        @Override
        public CachingProvider getCachingProvider() {
        }
        @Override
        public URI getURI() {
        }
        @Override
        public ClassLoader getClassLoader() {
        }
        @Override
        public Properties getProperties() {
        }
        @Override
        public <K, V, C extends Configuration<K, V>> Cache<K, V> createCache(String s, C c) throws IllegalArgumentException {
        }
        @Override
        public <K, V> Cache<K, V> getCache(String s, Class<K> aClass, Class<V> aClass1) {
        }
        @Override
        public <K, V> Cache<K, V> getCache(String s) {
        }
        @Override
        public Iterable<String> getCacheNames() {
        }
        @Override
        public void destroyCache(String s) {
        }
        @Override
        public void enableManagement(String s, boolean b) {
        }
        @Override
        public void enableStatistics(String s, boolean b) {
        }
        @Override
        public void close() {
        }
        @Override
        public boolean isClosed() {
        }
        @Override
        public <T> T unwrap(Class<T> aClass) {
        }
    }
    复制代码

长长的一摞接口等着实现，看着都**令人上头**，作为缓存提供商，便需要按照自己的能力去实现这些接口，以保证相关缓存能力是按照规范对外提供。也正是因为JCache API这种不接地气的表现，让其虽是JAVA 领域的正统规范，却经常被*束之高阁*，沦落成为了一种名义规范。业界主流的本地缓存框架中，比较出名的当属`Ehcache`了（当然，`Spring4.1`中也增加了对JSR规范的支持）。此外，**Redis**的本地客户端`Redisson`也有实现全套JCache API规范，用户可以基于Redisson调用JCache API的标准接口来进行缓存数据的操作。

![format_png 4][]

#### JSR107提供的注解操作方法 ####

前面提到了作为供应商想要实现*JSR107*规范的时候会比较复杂，需要做很多自己的处理逻辑。但是对于业务使用者而言，JSR107还是比较贴心的。比如JSR107中就将一些常用的API方法封装为`注解`，利用注解来大大简化编码的复杂度，降低缓存对于业务逻辑的*侵入性*，使得业务开发人员可以更加专注于业务本身的开发。

`JSR107`规范中常用的一些缓存操作注解方法梳理如下面的表格：

<table> 
 <thead> 
  <tr> 
   <th>注解</th> 
   <th>含义说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>@CacheResult</td> 
   <td>将指定的<code>key</code>和<code>value</code>映射内容存入到缓存容器中</td> 
  </tr> 
  <tr> 
   <td>@CachePut</td> 
   <td>更新指定缓存容器中指定<code>key</code>值缓存记录内容</td> 
  </tr> 
  <tr> 
   <td>@CacheRemove</td> 
   <td>移除指定缓存容器中指定<code>key</code>值对应的缓存记录</td> 
  </tr> 
  <tr> 
   <td>@CacheRemoveAll</td> 
   <td>字面含义，移除指定缓存容器中的所有缓存记录</td> 
  </tr> 
  <tr> 
   <td>@CacheKey</td> 
   <td>作为接口参数前面修饰，用于指定特定的入参作为缓存<code>key</code>值的组成部分</td> 
  </tr> 
  <tr> 
   <td>@CacheValue</td> 
   <td>作为接口参数前面的修饰，用于指定特定的入参作为缓存<code>value</code>值</td> 
  </tr> 
 </tbody> 
</table>

上述注解主要是添加在方法上面，用于自动将方法的入参与返回结果之间进行一个映射与自动缓存，对于后续请求如果命中缓存则直接返回缓存结果而无需再次执行方法的具体处理，以此来提升接口的响应速度与承压能力。

比如下面的查询接口上，通过`@CacheResult`注解可以将查询请求与查询结果缓存起来进行使用：

@CacheResult(cacheName = "books")
    public Book findBookByName(@CacheKey String bookName) {
        return bookDao.queryByName(bookName);
    }
    复制代码

当**Book**信息发生变更的时候，为了保证缓存数据的准确性，需要同步更新缓存内容。可以通过在更新方法上面添加`@CachePut`接口即可达成目的：

@CachePut(cacheName = "books")
    public void updateBookInfo(@CacheKey String bookName, @CacheValue Book book) {
        bookDao.updateBook(bookName, book);
    }
    复制代码

这里分别适用了`@CacheKey`和`@CacheValue`指定了需要更新的缓存记录key值，以及需要将其更新为的新的value值。

同样地，借助注解`@CacheRemove`可以完成对应缓存记录的删除：

@CacheRemove(cacheName = "books")
    public void deleteBookInfo(@CacheKey String bookName) {
        bookDao.deleteBookByName(bookName)
    }
    复制代码

![format_png 4][]

### 爱屋及乌 —— Spring框架制定的Cache规范 ###

JSR 107（JCache API）规范的诞生可谓是一路坎坷，拖拖拉拉直到**2014**年才发布了首个`1.0.0`版本规范。但是在JAVA界风头无两的**Spring**框架早在`2011`年就已经在其3.1版本中提供了缓存抽象层的规范定义，并借助Spring的优秀设计与良好生态，迅速得到了各个软件开发团体的青睐，各大缓存厂商也陆续提供了符合`Spring Cache`规范的自家缓存产品。

**Spring Cache**并非是一个具体的缓存实现，而是和JSR107类似的一套*缓存规范*，基于注解并可实现与Spring的各种高级特性无缝集成，受到了广泛的追捧。各大缓存提供商几乎都有基于Spring Cache规范进行实现的缓存组件。比如后面我们会专门介绍的`Guava Cache`、`Caffeine Cache`以及同样支持JSR107规范的`Ehcache`等等。

得力于Spring在JAVA领域无可撼动的地位，造就了**Spring Cache**已成为JAVA缓存领域的“事实标准”，深有“*功高盖主*”的味道。

#### Spring Cache使用不同缓存组件 ####

如果要基于`Spring Cache`规范来进行缓存的操作，首先在项目中需要引入此规范的定义：

<dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-cache</artifactId>
    </dependency>
    复制代码

这样，在业务代码中，就可以使用Spring Cache规范中定义的一些注解方法。前面有提过，*Spring Cache只是一个规范声明*，可以理解为一堆接口定义，而并没有提供具体的接口功能实现。具体的功能实现，由业务根据实际选型需要，引入相应缓存组件的jar库文件依赖即可 —— 这一点是Spring框架中极其普遍的一种做法。

假如我们需要使用`Guava Cache`来作为我们实际缓存能力提供者，则我们只需要引入对应的依赖即可：

<dependency>
        <groupId>com.google.guava</groupId>
        <artifactId>guava</artifactId>
        <version>30.1.1-jre</version>
    </dependency>
    复制代码

这样一来，我们便实现了使用Guava cache作为存储服务提供者、且基于Spring Cache接口规范进行缓存操作。Spring作为JAVA领域的一个相当优秀的框架，得益于其优秀的**封装**设计思想，使得更换缓存组件也显得非常容易。比如现在想要将上面的*Guava cache*更换为`Caffeine cache`作为新的缓存能力提供者，则业务代码中将依赖包改为Caffeine cache并简单的做一些细节配置即可：

<dependency>
        <groupId>com.github.ben-manes.caffeine</groupId>
        <artifactId>caffeine</artifactId>
        <version>3.1.1</version>
    </dependency>
    复制代码

这样一来，对于业务使用者而言，可以方便的进行缓存具体实现者的替换。而作为缓存能力提供商而言，自己可以轻易的被同类产品替换掉，所以也鞭策自己去提供更好更强大的产品，巩固自己的地位，也由此促进整个生态的**良性演进**。

![format_png 4][]

#### Spring Cache规范提供的注解 ####

需要注意的是，使用Spring Cache缓存前，需要先手动开启对于缓存能力的支持，可以通过`@EnableCaching`注解来完成。

除了 *@EnableCaching* ，在Spring Cache中还定义了一些其它的常用注解方法，梳理归纳如下：

<table> 
 <thead> 
  <tr> 
   <th>注解</th> 
   <th>含义说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>@EnableCaching</td> 
   <td>开启使用缓存能力</td> 
  </tr> 
  <tr> 
   <td>@Cacheable</td> 
   <td>添加相关内容到缓存中</td> 
  </tr> 
  <tr> 
   <td>@CachePut</td> 
   <td>更新相关缓存记录</td> 
  </tr> 
  <tr> 
   <td>@CacheEvict</td> 
   <td>删除指定的缓存记录，如果需要清空指定容器的全部缓存记录，可以指定<code>allEntities=true</code>来实现</td> 
  </tr> 
 </tbody> 
</table>

具体的使用上，其实和JSR107规范中提供的注解用法相似。

当然了，JAVA领域缓存事实规范地位虽已奠定，但是Spring Cache依旧是保持着一个兼收并蓄的姿态，并积极的兼容了JCache API相关规范，比如`Spring4.1`起项目中可以使用JSR107规范提供的相关注解方法来操作。

![format_png 6][]

## he ##

[format_png]: https://img-blog.csdnimg.cn/img_convert/5f9750807c06e00ac5673b64745bdbb9.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/770abc0f41f00bcf22fdb1a8a7bac972.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/bbd072329c64d84e32778e2228470d24.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/436402a64162387f71b70ac16bfecf70.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/a7958f7487bb5d66655c9fbe54efcbdb.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/d141c29fbe1b5a5e15879ba6a7597c96.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/9c1c702cd4cc8cdea7bcf46beb3b9dd3.webp?x-oss-process=image/format,png