缓存核心概念

最新推荐文章于 2022-05-17 17:59:13 发布

destiny ~

最新推荐文章于 2022-05-17 17:59:13 发布

阅读量333

点赞数 1

分类专栏： Spring 文章标签：缓存 Spring缓存抽象 HashMap Redis

本文链接：https://blog.csdn.net/XiaoA82/article/details/87923153

版权

Spring 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

使用缓存的核心目的只有一个，就是：加速访问，提高性能，保护数据库。
对于加速项目访问有一份极具经典的图：

访问量较小时，项目采用的是All In One的结构，这时候能跟数据库快速、便捷存取数据的ORM框架是提升性能的关键；
当访问量增加，能快速响应前端，数据在前后端快速交互的MVC框架就显得更加尤为重要；
访问量极大、高并发的网站一台服务器难以支撑，这时则需要将服务分散于多个服务器上，于是分布式RPC框架出现。

发展历史
与缓存相关的核心概念：
数据库连接池
数据库作为核心资源，频繁的连接而不进行管理必然导致资源崩溃，良好的数据库连接管理可以帮助项目健壮、安全。在目前成熟的连接池技术中，做得比较好的两个技术是dpcp和c3p0，其实就是两个Java的Jar包，只要在连接数据源的时候填写几个参数就可以帮助管理数据库连接资源，它们能很好的分配、管理、释放数据库连接。具体常用的几个参数是：最大连接数量，最大空闲等待时间等。现在的Java项目中基本看不到这些参数了，目前流行的ORM框架MyBatis、JPA等等已经把这些东西写在了底层，在具体的编程过程中已经不需要程序员去关心这些。
JSR107缓存规范
缓存出现最单纯的目的就是：将频繁使用的数据查询出来放到一个地方，给数据库降压。Java有对缓存的支持，也就是JSR107缓存规范。Java Caching定义了5个核心接口：

CachingProvider:定义了怎样创建、配置、获取、管理多个CacheManager,程序在运行期间可以访问多个CachingProvider；
CacheManager:定义了怎样创建、配置、获取、管理多个唯一命名的Cache，这些Cache存在于CacheManager的上下文中，一个CacheManager仅仅被一个CachingProvider所拥有；
Cache是一个类似于Map的数据结构并且临时存储以Key为索引的值；
Entry是一个存储在Cache中的key-value对；
Expiry每一个存储在Cache中的数据都有一个有效期，超过这个时间，就会将缓存置为过期状态，过期就不能对缓存进行访问、更新和删除，有效期可以通过ExpiryPolicy设置。

JDK的缓存抽象虽然功能强大，但是使用起来难度较大。我所知道JDK太过强大而导致使用难度极具增加的模块还有：1、动态代理Proxy，2、序列化Serializable
所以Spring从3.1开始定义了Cache和CacheManager接口来统一不同的缓存技术,并支持使用JCache（JSR-107）注解简化我们开发，这就是Spring缓存抽象。

Spring缓存抽象
Spring全家桶的模式越来越常见，市面上各种各样的缓存中间件Spring缓存抽象都能提供一套注解，操作起来难度降低的不只是一点点。Cache接口为缓存的组件规范定义，包含缓存各种操作集合，提供了各种xxxCache的实现，如：RedisCache，EhCacheCache，ConcurrentMapCache等等好多。每次调用需要缓存的方法时，Spring会检查指定参数的目标方法是否已经被调用过，如果有就直接获取缓存中方法调用后的结果，如果没有就调用方法并且缓存结果后再返回给用户，下次调用直接从缓存中获取。使用起来只要关注两点即可：1、确定方法需要被缓存以及他们的缓存策略，2、从缓存中读取之前缓存存储好的数据。在这里插入图片描述
哈希表与“HashMap和Redis”
哈希表是一种数据结构，HashMap是Java的JDK里面对哈希表的一种是实现，而Redis也是一种对哈希表的实现。一步步来说，哈希表是一种存储key-value的数据结构，它允许Key值相同。
JDK中的HashMap中设计的时候初始的容量是16，默认的负载因子是0.75，因此初始情况下，当键值对的数量大于 16 * 0.75 = 12 时，就会触发扩容；既然运行key值相同，当极端情况全部key值相同的时候其实就是一条链表，链表长度大于 8 时，有可能会转化成红黑树提升查找性能；在哈希表扩容时，如果发现链表长度小于 6，则会由树重新退化为链表；在转变成树之前，还会有一次判断，只有键值对数量大于 64 才会发生转换。这是为了避免在哈希表建立初期，多个键值对恰好被放入了同一个链表中而导致不必要的转化。这些都是写在JDK源码里面的，很有意思的。并且，当负载因子等于0.75，相同key，也就是箱子中元素的个数是服从泊松分布的，这就是为什么箱子中链表长度超过 8 以后要变成红黑树，因为在正常情况下出现这种现象的几率小到忽略不计。一旦出现，几乎可以认为是哈希函数设计有问题导致的。
而Redis采用的是增量扩容，所谓的增量式扩容是指，当需要重哈希时，每次只迁移一个箱子里的链表，这样扩容时不会出现性能的大幅度下降。Redis 提供了 void * 类型 key 的哈希函数，也就是通过任何类型的 key 的指针都可以求出哈希值。它的实现原理是根据指针地址和这一块内存的长度，获取内存中的值，并且放入到一个数组当中，这个数组仅由 0 和 1 构成。然后再对这些数字做哈希运算。因此即使两个指针指向的地址不同，但只要其中内容相同，就可以得到相同的哈希值。
面试经常会问的几个问题，Java中HashMap线程不安全，HashTable线程安全但是性能极其低下，所以Java提供了ConcurrentHashMap在高并发的情景下存储数据，要是能把上边那段HashMap原理弄清楚，红黑树做排序插入增加时候的删除新增修正函数什么的弄清楚，还怕被数据结构虐？
但这一来会导致在数据维护部分要增加对缓存模块的维护管理，尤其在数据库涉及到事务的时候可能会对数据造成“脏读”，“幻读”，“不可重复读”等情况，但是增加缓存能提升访问速度，也是值得的，缓存已经成为大型系统不可不考虑的模块。

使用缓存
缓存提供者用来控制和管理多个缓存管理器，应用程序要使用缓存，可以先通过不同的缓存提供者得到缓存管理器，在缓存管理器中去管理很多不同的缓存，要使用缓存组件从缓存管理器中获取即可，获取了缓存组件就可以将某一条Key-Value记录使用这个缓存组件进行增删改查保存起来，每一个缓存记录都有一个有效期，一旦超过有效期，缓存组件就会将它标记为过期状态，然后进行相应的处理等等。缓存管理器就类似于连接池，缓存组件就类似于连接。
下面是在SpringBoot的项目中整合Redis作为缓存中间件来使用的小例子：

1、使用@EnableCaching注解标注在项目启动的main方法上

@SpringBootApplication
@EnableCaching 
public class Springboot01CacheApplication {
	public static void main(String[] args) {
		SpringApplication.run(Springboot01CacheApplication.class, args);
	}
}

2、使用Cacheable标注在Service层方法上，就能使得方法的结果缓存起来

 /*@Cacheable标注的方法执行之前先来检查缓存中有没有这个数据，默认按照参数的值作为key去查询缓存，
     *   如果没有就运行方法并将结果放入缓存；以后再来调用就可以直接使用缓存中的数据；
     *   核心：
     *      1）、使用CacheManager【ConcurrentMapCacheManager】按照名字得到Cache【ConcurrentMapCache】组件
     *      2）、key使用keyGenerator生成的，默认是SimpleKeyGenerator
     *   几个属性：
     *     1、 cacheNames/value：指定缓存组件的名字;将方法的返回结果放在哪个缓存中，是数组的方式，可以指定多个缓存；
     *     2、key：缓存数据使用的key；可以用它来指定。默认是使用方法参数的值  1-方法的返回值
     *              编写SpEL； #i d;参数id的值   #a0  #p0  #root.args[0]
     *              getEmp[2]
     *     3、 keyGenerator：key的生成器；可以自己指定key的生成器的组件id
     *              key/keyGenerator：二选一使用;
     *     4、 cacheManager：指定缓存管理器；或者cacheResolver指定获取解析器
     *     5、 condition：指定符合条件的情况下才缓存；
     *              ,condition = "#id>0"
     *          condition = "#a0>1"：第一个参数的值》1的时候才进行缓存
     *      6、unless:否定缓存；当unless指定的条件为true，方法的返回值就不会被缓存；可以获取到结果进行判断
     *              unless = "#result == null"
     *              unless = "#a0==2":如果第一个参数的值是2，结果不缓存；
     *     7、 sync：是否使用异步模式    
     * /

@Cacheable(value = {"emp"}/*,keyGenerator = "myKeyGenerator",condition = "#a0>1",unless = "#a0==2"*/)
    public Employee getEmp(Integer id){
        System.out.println("查询"+id+"号员工");
        Employee emp = employeeMapper.getEmpById(id);
        return emp;
    }

3、@CachePut注解标注在方法上时，既调用方法，又更新缓存数据，同步更新缓存

/**
     * @CachePut：既调用方法，又更新缓存数据；同步更新缓存
     * 修改了数据库的某个数据，同时更新缓存；
     * 运行时机：
     *  1、先调用目标方法
     *  2、将目标方法的结果缓存起来
     */
    @CachePut(key = "#result.id")
    public Employee updateEmp(Employee employee){
        System.out.println("updateEmp:"+employee);
        employeeMapper.updateEmp(employee);
        return employee;
    }

4、使用@CacheEvict注解清除已经存储好的缓存

    /**
     * @CacheEvict：缓存清除
     *  key：指定要清除的数据
     *  allEntries = true：指定清除这个缓存中所有的数据
     *  beforeInvocation = false：缓存的清除是否在方法之前执行
     *      默认代表缓存清除操作是在方法执行之后执行;如果出现异常缓存就不会清除
     *  beforeInvocation = true：
     *      代表清除缓存操作是在方法运行之前执行，无论方法是否出现异常，缓存都清除
     */
    @CacheEvict(value="emp",beforeInvocation = true)
    public void deleteEmp(Integer id){
        System.out.println("deleteEmp:"+id);
        employeeMapper.deleteEmpById(id);
        int i = 10/0;
    }

使用缓存带来的问题：
开启了缓存之后就会牵扯到两个问题，一个是缓存数据时Key的生成策略，另外一个是缓存数据时候Value的序列化策略。
说简单一点就是查询到的记录可以定义根据主键放入缓存中，也可以不根据主键。key的值是什么这取决于使用者。当然value的序列化策略也应该是由使用者来决定，一般情况我们都希望变成JSON字符串的形式存储在Redis中。

application.properties 配置文件：

spring.datasource.url=jdbc:mysql://localhost:3306/cache
spring.datasource.username=root
spring.datasource.password=root
#spring.datasource.driver-class-name=com.mysql.jdbc.Driver
# 开启驼峰命名匹配规则
mybatis.configuration.map-underscore-to-camel-case=true
logging.level.com.atguigu.cache.mapper=debug
debug=true
#Redis一般是使用Docker，当然也可以装在本机上，端口是6379
spring.redis.host=127.0.0.1

附：SpringBoot缓存的配置类
SpringBoot使用缓存的原理是：（以下是SpringBoot缓存组件源码分析环节）
将方法的运行结果进行缓存，以后再要相同的数据，直接从缓存中获取，不用调用方法； CacheManager管理多个Cache组件的，对缓存的真正CRUD操作在Cache组件中，每一个缓存组件有自己唯一一个名字；
1、自动配置类；CacheAutoConfiguration
2、哪个配置类默认生效：SimpleCacheConfiguration；
3、给容器中注册了一个CacheManager：ConcurrentMapCacheManager
4、可以获取和创建ConcurrentMapCache类型的缓存组件；他的作用将数据保存在ConcurrentMap中；
运行流程：
@Cacheable：
1、方法运行之前，先去查询Cache（缓存组件），按照cacheNames指定的名字获取，（CacheManager先获取相应的缓存），第一次获取缓存如果没有Cache组件会自动创建。
2、去Cache中查找缓存的内容，使用一个key，默认就是方法的参数；
key是按照某种策略生成的；默认是使用keyGenerator生成的，默认使用SimpleKeyGenerator生成key；
SimpleKeyGenerator生成key的默认策略；
如果没有参数；key=new SimpleKey()；
如果有一个参数：key=参数的值
如果有多个参数：key=new SimpleKey(params)；
3、没有查到缓存就调用目标方法；
4、将目标方法返回的结果，放进缓存中

学过SpringBoot的都知道在项目启动的时候Sping只需要关注@EnableCaching这个注解有没有对应的组件在项目中，只要发现有Redis这个Redis组件的配置文件在项目中，就会开启Redis的缓存组件，没有就会使用默认的缓存组件，所以在@EnableCaching注解上打个断点，跟踪源码，能快速帮助理解缓存组件怎么运用到Java项目中。

org.springframework.boot.autoconfigure.cache.GenericCacheConfiguration org.springframework.boot.autoconfigure.cache.JCacheCacheConfiguration
org.springframework.boot.autoconfigure.cache.EhCacheCacheConfiguration
org.springframework.boot.autoconfigure.cache.HazelcastCacheConfiguration
org.springframework.boot.autoconfigure.cache.InfinispanCacheConfiguration
org.springframework.boot.autoconfigure.cache.CouchbaseCacheConfiguration
org.springframework.boot.autoconfigure.cache.RedisCacheConfiguration
org.springframework.boot.autoconfigure.cache.CaffeineCacheConfiguration
org.springframework.boot.autoconfigure.cache.GuavaCacheConfiguration
org.springframework.boot.autoconfigure.cache.SimpleCacheConfiguration【默认】
org.springframework.boot.autoconfigure.cache.NoOpCacheConfiguration

序列化
说简单一点就是在你电脑上的对象信息当你电脑关机了就没了，下次启动要重新实例化，可不可以想办法把它存起来，下次不想在重新实例化它了，或者我想把它发送给另外一台电脑上。设计模式里面有一种模式叫做单例模式，举个例子，在中国只能娶一个妻子，这就是单例模式，不允许实例化第二个。在JavaEE的项目中也有啊，一个session，当你关闭浏览器，这个session就不见了，在这个session里面的操作存储下来就需要系列化。尤其是现在大数据、分布式系统已经成为主流、微服务的概念深入人心，序列化就越来越重要。序列化就是把内存中的对象，转换成字节序列（或其他数据传输协议）以便于存储（持久化）和网络传输。反序列化就是将收到字节序列（或其他数据传输协议）或者是硬盘的持久化数据，转换成内存中的对象。
Java 的序列化是一个重量级序列化框架（Serializable），一个对象被序列化后，会附带很多额外的信息（各种校验信息，header，继承体系等），不便于在网络中高效传输。所以，很多现在流行的框架都会有自己的序列化机制。
比如hadoop 自己开发了一套序列化机制（Writable），精简、高效。序列化和反序列化在分布式数据处理领域经常出现：进程通信和永久存储。然而 Hadoop中各个节点的通信是通过远程调用（RPC）实现的，那么 RPC 序列化要求具有以下特点：1）紧凑：紧凑的格式能让我们充分利用网络带宽，而带宽是数据中心最稀缺的资源2）快速：进程通信形成了分布式系统的骨架，所以需要尽量减少序列化和反序列化的性能开销，这是基本的；3）可扩展：协议为了满足新的需求变化，所以控制客户端和服务器过程中，需要直接引进相应的协议，这些是新协议，原序列化方式能支持新的协议报文；4）互操作：能支持不同语言写的客户端和服务端进行交互。
RPC
对Dubbo这个框架熟悉的肯定都知道RPC（Dubbo是阿里的，2016年SpringCloud抢占全球分布式市场之际，在2017年农历春节的时候免费贡献给了Apache组织，是国内分布式系统领域比较权威且使用广泛的框架）：
RPC （Remote procedure Call）远程过程调用，是一种计算机通讯协议。
计算机A上的一个进程，调用另外一台计算机B上的进程，其中A上的调用被挂起，而B上的被调用进程开始执行，当B返回给A结果的时候，A继续执行。调用方法可以通过使用参数将信息传送给被调用方。而这个过程对开发人员来说是透明的。简单来说就是我是服务提供者，我就等着别调用我，我跟他不在一台机器上。我是服务使用者，我就掉别人的服务，不需要我自己有。
RPC框架的三个主要角色是：Provider、Consumer和Registry

Server：是暴露服务的服务提供方
Client：是调用远程服务的服务消费方
Registry：服务注册与服务发现的注册中心还负责负载均衡

服务提供者启动之后向注册中心注册机器的ip、port以及提供的服务列表：服务消费者启动后会向注册中心获取服务提供方的地址列表，可以实现负载均衡和Failover，一个成熟的RPC框架需要用到的技术：

1、动态代理：生成client stub 和 server stub 需要用到java的动态代理技术。
可以选用JDK的动态代理，也可以使用比较成熟的开源字节码工具框架
Cglib、Javassist等。其中，推荐使用Cglib因为它跟Spring是完美兼容的。如果不想用这些，可以使用AcpectJ去面向切面编程，Spring两大神器，IOC和AOP。
2、序列化：为了能在互联网上传输和接收java对象，需要对他进行序列化与反序列化操作。可以选用的Java的序列化机制，因为原生Java的序列化做得太强大了，造成效率低的问题，反而不推荐使用。推荐使用一些开源的、成熟的序列化技术，有：protobuf、Thrift、hessian、Kryo、Msgpack等。
3、NIO：当前很多RPC框架都直接基于netty这种IO通讯框架，这是计算机网络的知识了。
4、服务注册中心：可以选用的技术有Redis，Zookeeper，Consul，Etcd
这里面大名鼎鼎的就是Redis，Zookeeper这两个了。其他开源的RPC框架有：Motan 、gRPC、Thrift。

其实，在Java的JDK里面就有一个概念叫RMC，叫做远程方法调用，可以这么理解，RPC是在RMC上的一层封装。调用一个方法变成了调用一个服务。JDK中有许多概念一直被沿用、封装，又被各路大神以更加灵活、方便的形式出现。

对于RPC框架有一份极具经典的图，介绍的话改天补上吧。
在这里插入图片描述

所以最后来说一下“抽象”，“抽象”是从始至终都贯彻在计算机科学道路上的一个概念。
从最底层的将电路的开闭抽象为0和1以及二进制，使用二极管、三极管将各种电路的巧妙组合成为具有计算能力和存储能力的逻辑门电路和存储电路，众多的逻辑门最终组合成CPU、内存等等、接着抽象出一条条移动寄存器数据的指令，将一条条指令抽象为条语句i=i+1,又将一条条语句抽象为一段面向过程的C语言代码，又抽象为面向过程、面向对象、面向切面等等一系列语言。再将这些语言精巧的设计成框架、设计模式等等等等。以及本文中提到的将JDK中的RMC增加一层抽象有了RPC，Spring将JDK中的代理抽象成AOP，Spring缓存抽象将各种缓存中间件提供一个统一的接口来使用，这些都是抽象，化繁为简，向上层抽象。要学习总结的便是这个抽象的思维，遇到问题是怎样抽象出解决思路的，在项目中将公共不变的部分抽取出来，运用适当的设计模式，再层层细分、编码实现，通常在抽象过程中能够做的很好的项目展开起来都不会太难。而所谓的框架就是将更加简单方便的解决方法提供给使用者，将一些实现的细节都封装在内部，降低了难度，开发变得更加简单方便，安全性、易维护、健壮性、可运行性等也得到了很好的保证。

destiny ~

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
缓存核心概念

使用缓存的核心目的只有一个，就是：加速访问，提高性能，保护数据库。对于加速项目访问有一份极具经典的图：访问量较小时，项目采用的是All In One的结构，这时候能跟数据库快速、便捷存取数据的ORM框架是提升性能的关键；当访问量增加，能快速响应前端，数据在前后端快速交互的MVC框架就显得更加尤为重要；访问量极大、高并发的网站一台服务器难以支撑，这时则需要将服务分散于多个服务器上，于是分布...
复制链接

扫一扫