Ehcache

之前我们介绍了两种进程内缓存的用法，包括Spring Boot默认使用的 ConcurrentMap缓存 以及 缓存框架EhCache 。虽然EhCache已经能够适用很多应用场景，但是由于EhCache是进程内的缓存框架，在集群模式下时，各应用服务器之间的缓存都是独立的，因此在不同服务器的进程间会存在缓存不一致的情况。即使EhCache提供了集群环境下的缓存同步策略，但是同步依然是需要一定的时间，短暂的缓存不一致依然存在。 在一些要求高一致性（任何数据变化都能及时的被查询到）的系统和应用中，就不能再使用EhCache来解决了，这个时候使用集中式缓存就可以很好的解决缓存数据的一致性问题。接下来我们就来学习一下，如何在Spring Boot的缓存支持中使用Redis实现数据缓存。 动手试试 本篇的实现将基于 上一篇 的基础工程来进行。先来回顾下上一篇中的程序要素： User实体的定义 @Entity @Data @NoArgsConstructor public class User implements Serializable { @Id @GeneratedValue private Long id; private String name; private Integer age; public User(String name, Integer age) { this

J2Cache 是一个两级的缓存框架，第一级是基于内存的数据缓存，支持 caffeine、ehcache2 和 ehcache3 ，二级缓存只支持 redis。 在某些生产环境中你可能没有 redis，但是又希望多个应用节点间... 来源： oschina 链接： https://my.oschina.net/u/4415089/blog/4523317

缓存实现的方式 一级缓存 二级缓存 案例实操 1. 一级缓存 基于 PerpetualCache 的 HashMap 本地缓存（mybatis 内部实现 cache 接口），其存储作用域为 Session，当 Session flush 或 close 之后，该 Session 中的所有 Cache 就将清空； 2. 二级缓存 一级缓存其机制相同，默认也是采用 PerpetualCache 的 HashMap 存储，不同在于其存储作用域为 Mapper(Namespace)，并且可自定义存储源，如 Ehcache； 对于缓存数据更新机制，当某一个作用域(一级缓存 Session/二级缓存 Namespaces)的进行了 C/R/U/D 操作后，默认该作用域下所有 select 中的缓存将被 clear。 如果二缓存开启，首先从二级缓存查询数据，如果二级缓存有则从二级缓存中获取数据，如果二级缓存没有，从一级缓存找是否有缓存数据，如果一级缓存没有，查询数据库 。 3. 二级缓存局限性 mybatis 二级缓存对细粒度的数据级别的缓存实现不好，对同时缓存较多条数据的缓存，比如如下需求：对商品信息进行缓存，由于商品信息查询访问量大，但是要求用户每次都能查询最新的商品信息，此时如果使用 mybatis 的二级缓存就无法实现当一个商品变化时只刷新该商品的缓存信息而不刷新其它商品的信息，因为

在程序中可以使用缓存的技术来节省对数据库的开销。Spring Boot对缓存提供了很好的支持，我们几乎不用做过多的配置即可使用各种缓存实现。这里主要介绍平日里个人接触较多的Ehcache和Redis缓存实现。 准备工作 可根据 Spring-Boot中使用Mybatis.html 搭建一个Spring Boot项目，然后yml中配置日志输出级别以观察SQL的执行情况： 1 2 3 4 5 logging: level: com: springboot: mapper: debug 其中 com.spring.mapper 为MyBatis的Mapper接口路径。 然后编写如下测试方法： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 @RunWith (SpringJUnit4ClassRunner.class) @SpringBootTest (classes = Application.class) public class ApplicationTest { @Autowired private StudentService studentService; @Test public void test () throws Exception { Student student1 = this .studentService

缓存 缓存的作用： 高并发、高性能 高性能：查询速度快 高并发：缓存是走内存的，内存天然就支撑高并发 常见缓存问题： 缓存与数据库双写不一致 缓存雪崩、缓存穿透、缓存击穿 缓存并发竞争 如何保证缓存和数据库一致性： 使用串行化，即：将读请求和写请求放到一个内存队列中。 串行化可以保证缓存与数据库一直，但是会导致系统吞吐量大幅度降低。非严格要求，不要串行化。 经典缓存+DB读写模式 》读：先读缓存，没有读取DB,读出来放入缓存。 》更新：先更新DB,再 删除 缓存。 缓存雪崩 请求量大时，缓存此时也跌机了，导致大量请求直接请求DB,带着DB也跌机了。 缓存雪崩的事前事中事后的解决方案： 事前：Redis 高可用，主从+哨兵，Redis cluster，避免全盘崩溃。 事中：本地 ehcache 缓存 + hystrix 限流&降级，避免 MySQL 被打死。 事后：Redis 持久化，一旦重启，自动从磁盘上加载数据，快速恢复缓存数据。 缓存穿透 缓存中查询不到，大量的请求直接查询DB. 解决方案： 每次系统 A 从数据库中只要没查到，就写一个空值到缓存里去，比如 set -999 UNKNOWN 。然后设置一个过期时间，这样的话，下次有相同的 key 来访问的时候，在缓存失效之前，都可以直接从缓存中取数据。 缓存击穿 某个 key 非常热点，访问非常频繁，处于集中式高并发访问的情况