项目中缓存的使用

Redis缓存

Redis简介

Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。

Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。

本项目将单机版的Redis作为中间件使用，来完成性能优化的一些操作

Redis缓存有三种模式：1）单机版；2）sentinal哨兵模式；3）集群cluster模式

使用Redis做商品详情页动态获取接口的缓存的内容的实现，是企业级应用第一个常用的优化点；在SpringMVC的Controller层将对应的Redis引入，将从下游Service层(数据库)接收到的一些数据在Controller层缓存起来，以便于下次再有任何的请求进来的时候，可以直接判断缓存中是否有对应的商品详情页的数据，如果有，直接返回而不去走下游的Service层(数据库)调用，减少对数据库的依赖。

最好的优化方式就是在Controller层，在访问对应的商品库存信息之前完成缓存的操作

redis配置

引入依赖

商品详情页动态内容展示实现的操作：

如果使用 Redis 默认序列化机制，往Redis中存储对象的结果展示：

可以看到在界面中，值都被序列化成这么一串字符串了，不便于数据的查看。

将 Redis 的默认序列化机制，改成 JSON 格式的序列化机制最佳，方便商品详情页动态内容展示

Redis的序列化机制：

Redis 的默认序列化机制是JDK序列化机制，下图的源码中可以看出：

从源码中也可以看出，如果没有设置序列化机制，则defaulatSeralizer = new JdkSerializationRedisSerializer() ，可以明显看出，使用的就是JDK 的序列化机制。

JDK默认序列化机制并非不能使用，只是它具有一定的局限性

• 它只适用于Java项目，对其他语言编写的项目不兼容，如Go或者PHP

• 在Redis的可视化页面，无法进行较好的展示

需要将 Redis 的默认序列化机制改为JSON格式，一方面兼容性较高，另一方面方便商品详情页动态内容展示。

将商品展示页面的Java对象数据序列化为字节序列的格式以便于保存到Redis数据库中， 并且将日期序列化为自定义的指定格式。Redis中的key是String类型数据，value是Json数据类型。

redis默认的序列化方式就是JDK的序列化方式；这里需要将数据反序列化为Json格式返回给前端

 

第一次刷新不会出现上面的错误，因为是直接从数据库中取的；第二次刷新错误报这个错误的原因是对下面的字节序列反序列化不了，因为解析不了对应的参数

加入一行代码：

//可以在序列化的字节序列中包含类信息,以便于反序列化的时候JVM咋样解析参数
 
objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL);     

可以看到此时的字节序列中多了类的信息，加入这行代码的作用就是为了告诉JVM咋样去解析对应的参数；此时，无论刷新多少次都是从缓存(Redis)里取的

Redis缓存为啥必须设置缓存失效时间：

对应的缓存必须要有失效时间，不仅仅是为Redis的容量性能考虑，更为了对应的业务的能力，如果说缓存没有失效时间，那就必定当数据发生改变的时候，需要有一个清理缓存的机制；首先使用被动的数据过期失效方式，也就是说，不管后台数据库的数据咋么变，Redis默认给一个10分钟的失效时间。

ItemController类中 

Redis的缺点：

redis缓存的管理的优势是集中式的key-value对的数据库，并且支持数据库 --持久化操作，但是正是由于一致性管理的特性，导致了所有对于数据库的存或者取都需要经过网络的IO达到对应的redisService上（I/0开销是耗时的主要原因：因为redis的数据存在内存上），并且根据redis协议去更新对应的状态，因此相对于操作本地缓存的特性来说，redis的性能此时是并不是最高要求的；因此实现多级缓存第二级，第一级(最底层的是redis)，在这之上，引入本地热点缓存。

本地缓存

本地热点缓存的特点：

 应用程序启动的时候，堆栈的大小设置为2048M

项目中本地热点缓存的方案：

设想一下，做一个类似于Java中HashMap的数据结构，key就是item的id，value就是对应的itemModel的模型即可；做这样的hashmap很有挑战，要支持有并发读有并发写的能力，此时想到ConcrentHashMap，但是它是基于段的方式处理锁的，写锁加上去之后会对写锁的性能产生影响；做到本地缓存就必须考虑对应的失效的淘汰时间以及对应的LRU缓存，所以本项目使用谷歌的Guava cache组件；其本质上也是一个可并发的hashmap，但是它可以控制key的大小和超时时间还可以配置LRU的策略，其次它还是线程安全的

Guava Cache简介

Guava Cache是 Google 提供的一套 Java 工具包，是一套非常完善的本地缓存机制（JVM缓存）。Guava Cache 的设计来源于 CurrentHashMap，可以按照多种策略来清理存储在其中的缓存值，且保持很高的并发读写能力。

Guava Cache的优点：

1）可控制的大小和缓存过期时间

2）可配置的LRU策略(冷数据就不会长期占据内存空间)

3）线程安全

guava介绍的好文章：

https://www.jianshu.com/p/b3c10fcdbf0f

官网(慕课老师推荐)

[Google Guava] 3-缓存 | 并发编程网 – ifeve.com

本地缓存在项目中的体现：

引入对应的jar包

之前使用redis中间件完成对应的数据库的存取操作，现在封装一个类似于cacheService来完成guava的存和取

本地热点缓存的设置 

这里cache的使用基本和map的使用一样,但是它提供了初始化的方式可以容许程序员配置最大、最小值以及对应的过期时间、过期策略

LRU算法 

LRU 算法优势在于算法实现简单，对于对于热点数据， LRU 效率会很好，所以很常用；

缺点是：如果偶然性的要对全量数据进行遍历，那么“历史访问记录”就会被刷走，造成污染；导致缓存命中率下降，减慢了正常数据查询。

缓存命中率是缓存系统的非常重要指标，如果缓存系统的缓存命中率过低，将会导致查询回流到数据库，导致数据库的压力升高。

改进方案：

将链表拆分成两部分，分为热数据区，与冷数据区。

改进之后算法流程将会变成下面一样:

访问数据如果位于热数据区，与之前 LRU 算法一样，移动到热数据区的头结点。
插入数据时，若缓存已满，淘汰尾结点的数据。然后将数据 插入冷数据区的头结点。
处于冷数据区的数据每次被访问需要做如下判断：
若该数据已在缓存中超过指定时间，比如说 1 s，则移动到热数据区的头结点。
若该数据存在在时间小于指定的时间，则位置保持不变。
对于偶发的批量查询，数据仅仅只会落入冷数据区，然后很快就会被淘汰出去。热门数据区的数据将不会受到影响，这样就解决了 LRU 算法缓存命中率下降的问题。 

LRU策略引入leetcode算法帮助理解学习：

146. LRU 缓存

本地缓存过期时间问题： 

过期时间是一个相对的时间，到底是相对写入时间还是相对于被访问的时间？

一般设置为相对写入时间，因为被访问的时间对于热点数据如果一直被访问的话永远也失效不了，就不合理

总结：

本项目中缓存策略是Redis结合本地缓存，秒杀业务下，高频读取缓存对Redis压力很大，使用本地缓存结合Redis缓存使用，降低Redis压力，同时本地缓存没有连接开销，性能更优。

redis缓存和本地缓存混用的优缺点

优点

• redis保证数据可持久，本地缓存保证超高的读取性能，秒杀场景下能有效降低redis压力

• guava作为本地缓存，提供了丰富的api，过期策略，最大容量，保证服务内存可控，冷数据不会长期占据内存空间

• 服务重启导致的本地缓存清空不会影响业务进行

缺点

• 只适用于缓存内容只增不改的场景

• 会产生一定的延时，这个延时具体的影响将会根据业务的差别而定。

面试题：项目中为什么要使用缓存？

1. 提升性能

2. 缓解数据库压力

面试题： 缓存穿透、 缓存雪崩、 缓存击穿

缓存穿透

• 业务误操作，缓存中的数据和数据库中的数据都被误删除了，所以导致缓存和数据库中都没有数据；
• 黑客恶意攻击，故意大量访问某些读取不存在数据的业务；

• 第一种方案，非法请求的限制；
• 第二种方案，缓存空值或者默认不存在的值；

缓存雪崩

• 大量数据同时过期；
• Redis 故障宕机；

大量数据同时过期

• 均匀设置过期时间；
• 互斥锁；
• 设置热点数据永不过期；

Redis 故障宕机

• 服务熔断或请求限流机制；
• 构建 Redis 缓存高可靠集群；

缓存击穿

• 互斥锁方案，保证同一时间只有一个业务线程更新缓存，未能获取互斥锁的请求，等待锁释放后重新读取缓存。
• 设置热点数据永不过期，避免热点数据的失效导致大量的相同请求落入DB； 缓存数据不设置有效期，并不是意味着数据一直能在内存里，因为 当系统内存紧张的时候，有些缓存数据会被“淘汰”  。

现在的项目是如何解决Redis缓存穿透、 缓存雪崩、 缓存击穿的？ 

本地缓存 + 限流 + 合理的缓存失效时间，足以抗住整个秒杀环节；对于redis集群高可用、持久化策略还没有在项目中实现。

Redis中所有对于数据库的存或者取都需要经过网络的IO达到对应的redisService上（I/0开销是耗时的主要原因：因为redis的数据存在内存上），所以使用本地热点缓存；本地热点缓存只有热点数据才可以进入，热点数据每秒钟的访问量是非常大的，这样可以减少服务端到redis中取数据对应的网络开销，也可以减少redisService的压力。

设置合理的失效时间避免Redis缓存和本地缓存同时回源。

面试题：Rdeis线程安全问题

关于取数据判断是否为null的逻辑上面，如果在高并发场景下，不加锁，是否会有线程安全问题，是否该加个双重检查锁？

答： 无需加锁，因为用缓存本身就没有必要保证一定不能脏读，加了锁反而影响性能，就体现不出来做缓存的任何意义

《【面试突击】— Redis篇》--Redis的线程模型了解吗？为啥单线程效率还这么高？