为何需要规范
构建的最简化版本的缓存框架,虽然可以使用,但是也存在一个问题,就是它对外提供的实现接口都是框架根据自己的需要而自定义的。这样一来,项目集成了此缓存框架,后续如果想要更换缓存框架的时候,业务层面的改动会比较大。 —— 因为是自定义的框架接口,无法基于里氏替换原则来进行灵活的更换。
在业界各大厂商或者开源团队都会构建并提供一些自己实现的缓存框架或者组件,提供给开发者按需选择使用。如果大家都是各自闭门造车,势必导致业务中集成并使用某一缓存实现之后,想要更换缓存实现组件会难于登天。
千古一帝秦始皇统一天下后,颁布了书同文、车同轨等一系列法规制度,使得所有的车辆都遵循统一的轴距,然后都可以在官道上正常的通行,大大提升了流通性。而正所谓“国有国法、行有行规”,为了保证缓存框架的通用性、提升项目的可移植性,JAVA行业也迫切需要这么一个缓存规范,来约束各个缓存提供商给出的缓存框架都遵循相同的规范接口,业务中按照标准接口进行调用,无需与缓存框架进行深度耦合,使得缓存组件的更换成为一件简单点的事情。
在JAVA的缓存领域,流传比较广泛的主要是JCache API和Spring Cache两套规范,下面就一起来看下。
虽迟但到的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规范中,定义的缓存框架相关接口类之间的关系逻辑梳理如下:
我们要实现自己的本地缓存框架,也即需要实现上述各个接口。对上述各接口类的含义介绍说明如下:
接口类 |
功能定位描述 |
CachingProvider |
SPI接口,缓存框架的加载入口。每个Provider中可以持有1个或者多个CacheManager对象,用来提供不同的缓存能力 |
CacheManager |
缓存管理器接口,每个缓存管理器负责对具体的缓存容器的创建与管理,可以管理1个或者多个不同的Cache对象 |
Cache |
Cache缓存容器接口,负责存储具体的缓存数据,可以提供不同的容器能力 |
Entry |
Cache容器中存储的key-value键值对记录 | <