一般来说,可以在5个方面进行缓存的设计:

1.最底层可以配置的是mysql自带的query cache,

2.mybatis的一级缓存,默认情况下都处于开启状态,只能使用自带的PerpetualCache,无法配置第三方缓存

3.mybatis的二级缓存,可以配置开关状态,默认使用自带的PerpetualCache,但功能比较弱,能够配置第三方缓存

4.service层的缓存配置,结合spring,可以灵活进行选择

5.针对实际业务情况,直接缓存部分html页面,直接返回给客户端。

 

在测试过程中,发现mybatis的一级缓存没有起作用,失效了。经过调研,发现是由于以下原因引起的:

1.mybatis的一级缓存生效的范围是sqlsession,是为了在sqlsession没有关闭时,业务需要重复查询相同数据使用的。一旦sqlsession关闭,则由这个sqlsession缓存的数据将会被清空。

2.spring对mybatis的sqlsession的使用是由template控制的,sqlsession又被spring当作resource放在当前线程的上下文里(threadlocal),spring通过mybatis调用数据库的过程如下:

           a.我们需要访问数据

           b.spring检查到了这种需求,于是去申请一个mybatis的sqlsession(资源池),并将申请到的sqlsession与当前线程绑定,放入threadlocal里面

           c.template从threadlocal获取到sqlsession,去执行查询

           d.查询结束,清空threadlocal中与当前线程绑定的sqlsession,释放资源

           e.我们又需要访问数据

           f.返回到步骤b

通过以上步骤后发现,同一线程里面两次查询同一数据所使用的sqlsession是不相同的,所以,给人的印象就是结合spring后,mybatis的一级缓存失效了。

一级缓存,是Session级别的缓存,它会把这个操作的结果放在一级缓存中。短时间内这个session(一定要同一个session)又做了同一个操作,那么直接从一级缓存中拿,而不会再去连数据库,取数据。它是内置的事务范围的缓存,不能被卸载。

二级缓存,是SessionFactory级别的缓存,查询的时候会把查询结果缓存到二级缓存中。 如果同一个sessionFactory创建的某个session执行了相同的操作,就会从二级缓存中拿结果,而不会再去连接数据库。 这是可选的插件式的缓存,在默认情况下,SessionFactory不会启用这个插件。

可以在每个类或每个集合的粒度上配置,严格意义上说,SessionFactory缓存分为两类:内置缓存和外置缓存。我们通常意义上说的二级缓存是指外置缓存。内置缓存与session级别缓存实现方式相似,前者是SessionFactory对象的一些集合属性包含的数据,后者是指Session的一些集合属性包含的数据。SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句。

SessionFactory的内置缓存是只读的,应用程序不能修改缓存中的映射元数据和预定义SQL语句,因此SessionFactory不需要进行内置缓存与映射文件的同步。

Hibernate的这两级缓存都位于持久化层,存放的都是数据库数据的拷贝。
缓存的并发访问策略
1、缓存的范围
决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。
事务范围
进程范围
集群范围
注:
对大多数应用来说,应该慎重地考虑是否需要使用集群范围的缓存,因为访问的速度不一定会比直接访问数据库数据的速度快多少。
事务范围的缓存是持久化层的第一级缓存,通常它是必需的;进程范围或集群范围的缓存是持久化层的第二级缓存,通常是可选的。
2、缓存的并发访问策略
当多个并发的事务同时访问持久化层的缓存的相同数据时,会引起并发问题,必须采用必要的事务隔离措施。
在进程范围或集群范围的缓存,即第二级缓存,会出现并发问题。
因此可以设定以下四种类型的并发访问策略,每一种策略对应一种事务隔离级别。
事务型并发访问策略是事务隔离级别最高,只读型的隔离级别最低。事务隔离级别越高,并发性能就越低。

隔离级别

脏读

不可重复读

幻读

非严格读写型(TRANSACTION_READ_UNCOMMITTED)

允许

允许

允许

读写型(TRANSACTION_READ_COMMITTED)

不允许

允许

允许

事务型(TRANSACTION_REPEATABLE_READ)

不允许

不允许

允许

只读型(TRANSACTION_SERIALIZABLE)

不允许

不允许

不允许

A 事务型:仅仅在受管理环境中适用( TRANSACTION_REPEATABLE_READ )。它提供了Repeatable Read事务隔离级别。
对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读和不可重复读这类的并发问题。
B 读写型:提供了Read Committed事务隔离级别( TRANSACTION_READ_COMMITTED )。仅仅在非集群的环境中适用。
对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读这类的并发问题。
C 非严格读写型:不保证缓存与数据库中数据的一致性( TRANSACTION_READ_UNCOMMITTED )。
如果存在两个事务同时访问缓存中相同数据的可能,必须为该数据配置一个很短的数据过期时间,从而尽量避免脏读。
对于极少被修改,并且允许偶尔脏读的数据,可以采用这种并发访问策略。
D 只读型:对于从来不会修改的数据,如参考数据,可以使用这种并发访问策略( TRANSACTION_SERIALIZABLE )。
除此之外,还有 TRANSACTION_NONE  不使用事务。

什么样的数据适合存放到第二级缓存中?
1、很少被修改的数据
2、不是很重要的数据,允许出现偶尔并发的数据
3、不会被并发访问的数据
4、参考数据

不适合存放到第二级缓存的数据?
1、经常被修改的数据
2、财务数据,绝对不允许出现并发
3、与其他应用共享的数据

Hibernate的二级缓存策略的一般过程如下:
1) 条件查询的时候,总是发出一条select * from table_name where …. (选择所有字段)这样的SQL语句查询数据库,一次获得所有的数据对象。
2) 把获得的所有数据对象根据ID放入到第二级缓存中。
3) 当Hibernate根据ID访问数据对象的时候,首先从Session一级缓存中查;查不到,如果配置了二级缓存,那么从二级缓存中查;查不到,再查询数据库,把结果按照ID放入到缓存。
4) 删除、更新、增加数据的时候,同时更新缓存。
注:
Hibernate的二级缓存策略,是针对于ID查询的缓存策略,对于条件查询则毫无作用。为此,Hibernate提供了针对条件查询的Query缓存。
Query缓存策略的过程如下:
1) Hibernate首先根据这些信息组成一个Query Key,Query Key包括条件查询的请求一般信息:SQL, SQL需要的参数,记录范围(起始位置rowStart,最大记录个数maxRows),等。
2) Hibernate根据这个Query Key到Query缓存中查找对应的结果列表。如果存在,那么返回这个结果列表;如果不存在,查询数据库,获取结果列表,把整个结果列表根据Query Key放入到Query缓存中。
3) Query Key中的SQL涉及到一些表名,如果这些表的任何数据发生修改、删除、增加等操作,这些相关的Query Key都要从缓存中清空。