橘子学Mybatis07之Mybatis关于缓存的设计-Toy模板网

这篇具有很好参考价值的文章主要介绍了橘子学Mybatis07之Mybatis关于缓存的设计。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

很逆天的一件事是，我上一次发mybatis是在2022年10月15号，然后直到今天才开始总结下一篇Mybatis的东西。一年里面忙成那啥了，而且重心都投入在了Elasticsearch的学习上面，基本一年下来都在搞ES，并且考下了ECE认证，后续如果有时间，一直想写一些es学习的总结，分享一下。
现在貌似又要开始往管理岗位上面凑热闹了，以后可能会有多的时间来总结之前的一些学习了，这个不知道是好事还是坏事，这里就当抱怨抱怨。哈哈。

一、缓存的意义

话不多说，我们来看Mybatis中的缓存，我们之前说过缓存，那还是在2022年的时候，我们知道mybatis作为ORM框架，他的核心任务就是和数据库打交道。
我们又知道你和数据库打交道我们不说各家数据库对于文件系统的实现是不是自身自带缓存，他总归是要和磁盘打交道的，涉及到很重的磁盘IO操作(别抬杠，别和我说硬件的进化，我说的是相对很重)。
而我们面对这种一般就是在业务设计的时候都会想到缓存，是的常见的就是Redis缓存，我们会把数据库(磁盘中)的一部分数据预先加载在缓存中，而缓存是内存角度的操作，在内存中操作数据是很轻量级的。以后我们每次读数据库的时候就在缓存里面放一份，下次再读的时候就直接走缓存了，那么是不是就能提高请求的响应，提高业务的吞吐。
缓存中的数据在修改的时候也不需要直接就刷回磁盘，我们可以在一定时间频率内进行数据的写磁盘，这样对于你系统的吞吐也是很有提升的，当然前提是你能容忍一定的数据丢失问题。这些大概就是缓存的意义，但是实现起来却并不容易，数据的一致性，数据的持久化，缓存的大小导致的数据换出，内存中存储的大小，这都是我们在设计的时候需要考虑的，如果你想知道一些扩展的东西，可以去看redis的实现。这里不多展开说了。

既然知道了缓存的大致意义，他可以做到减少和磁盘IO的交互，转为和内存的交互，这样就能减少我们的性能开支。那么mybatis是和数据库打交道的，那么他是不是可以加入关于缓存的设计呢，答案是可以，他确实这么设计了一套接口API，并且以接口的形式暴露出来，方面我们自己进行扩展，你可以很方便的就扩展为你们自己的redis架构。

二、Mybatis中缓存的设计

mybatis中缓存是设计为接口的形式，方便后面的扩展和实现。现在我们就来看一下这个扩展接口。
这个接口的位置是org.apache.ibatis.cache.Cache类，我们可以看到他是ibatis包中的一个接口。
这个接口有诸多的方法，我们可以借助idea的ctrl+F12组合键来看一下。
如何查找应用文件缓存位置,SSM,# Mybatis,JAVA,mybatis,java
我们看到他作为缓存的顶层接口，实际上就约定了缓存操作的一些基础操作，看了一下也其实就那么回事吧。无外乎就是怎么把数据放入缓存(putObject)，怎么把数据从缓存里面取出来(getObject)，怎么把数据从缓存中移除出去(removeObject)，怎么清除缓存(clear),其他的基本也是围绕这几个操作展开的一些更加细化的操作，我们说其实不用看他这个代码也能想到他就是这么些个功能。
原谅我这里再次吐槽一下，mybatis的源码注释，真的少。我的建议是要不干脆别加了。

这里需要额外说一件事就是那个getReadWriteLock这个方法，看着意思是获取读写锁，但是我们看一下源码：

/**
   * 从3.2.6开始，mybatis已经移除了这个方法，所以其实他不重要。
   * Optional. As of 3.2.6 this method is no longer called by the core.
   * 
   * 以后的锁需要由提供缓存的人来维护这个并发安全，所以如果你怕麻烦，那我推荐你使用redis，服务端写入单线程，没有这个苦恼，我们一直都用它。
   * Any locking needed by the cache must be provided internally by the cache provider.
   *
   * @return A ReadWriteLock
   */
  default ReadWriteLock getReadWriteLock() {
    return null;
  }

那按照我们对于缓存的理解，自然你往缓存里面放数据的时候，就要指定数据的key，方便我们后面去根据这个key去取，自然putObject的参数就有两个，一个是标识key，一个是缓存的数据。
那我们取数据的时候自然就是根据这个标识去取，自然getObject的参数就是那个key.
移除数据和获取数据其实是一样的，都是找到这个数据。这个其实就类似于map，而缓存实际上也就是map的那个意思，可以一起理解一下。
clear不说了，属于AOE大招，直接全删，自然也不需要区分什么谁是谁，不要参数，直接全干掉。
至此我们是对于这个缓存有个大概的理解了。下面我们就来实际操作一下，我们看看咋用。亲爱的。

三、先让你来设计一下缓存

既然mybatis这么贴心为我们设计了缓存接口，我们只需要实现一下就能实现缓存功能。那你不试一把，实在是对不起远在大洋彼岸的那些大佬们(或者你用plus，那就稍微对得起他们了)。
来吧，我们来试试。试试就逝逝。

3.1、实现接口

第一步、我们先定义一个org.apache.ibatis.cache.Cache接口的接口实现类，就叫他IkunCache吧。

public class IkunCache implements Cache {
  @Override
  public String getId() {
    return null;
  }

  @Override
  public void putObject(Object key, Object value) {

  }

  @Override
  public Object getObject(Object key) {
    return null;
  }

  @Override
  public Object removeObject(Object key) {
    return null;
  }

  @Override
  public void clear() {

  }

  @Override
  public int getSize() {
    return 0;
  }

  @Override
  public ReadWriteLock getReadWriteLock() {
    return null;
  }
}

好了，我们现在已经完成了接口实现类的工作了，下一步我们要考虑一下既然是缓存，那么数据到底缓存到哪呢，redis？一上来就开大，不太好吧(实际上我本地没有redis环境)。我们先放在我们的本地内存试试。

3.2、制定存储结构

既然要在本地存，那作为java boy,本地其实就那么几种结构，存那么多缓存数据你高低得是个集合吧，那无外乎就是List，Set，Map这种，list和set不行，我直接否了，因为他们获取数据需要遍历。移除数据也要遍历。我用缓存是为了快，你给我来个遍历，你脑子和我脑子到底谁有问题。
所以我们就把目标定在了Map上，简单点，哥们，直接用HashMap，能通过key直接获取删除，等会你说key，你刚才说了key。还记不记得我们说缓存redis这种的时候，就是Key,我们又说Cache接口里面那些方法的时候也说的是key。好了，HashMap,我宣布，你就是今天的天命之子。
于是我们就要声明一个本地变量，就是HashMap，然后我们不管是写缓存，还是读缓存，还是清空缓存都用这个map就好了，那么代码就进化成为这样。

public class IkunCache implements Cache {
  

  // 缓存内容的容器
  private static Map<Object,Object> ikunCache = new HashMap<>();
  
  /**
    因为整个应用中可能存在多个缓存，比如缓存的redis，本地的，或者按照业务划分缓存的订单的，用户的等等
    这里可以为你的缓存指定一个名字来区分
   **/
  @Override
  public String getId() {
    // 我们用缓存类的类名来区分开每个缓存实例，每个缓存类都维护自己的一个map即可，这样就区分开了，简单设计一下，别太纠结
    return getClass().getName();
  }

  @Override
  public void putObject(Object key, Object value) {
    // 把数据放入缓存
    ikunCache.put(key,value);
  }

  @Override
  public Object getObject(Object key) {
    // 从缓存中获取数据
    return ikunCache.get(key);
  }

  @Override
  public Object removeObject(Object key) {
    // 从缓存中移除数据
    return ikunCache.remove(key);
  }

  @Override
  public void clear() {
    // 开大招，清空缓存
    ikunCache.clear();
  }

  @Override
  public int getSize() {
    // 获取缓存的长度
    return ikunCache.size();
  }

  @Override
  public ReadWriteLock getReadWriteLock() {
    // 移除了
    return null;
  }
}

那现在是不是你就实现了这个缓存接口了，你就能用了。至于你是不是还有其他的实现类，那可以制定多个实现类。你自己多实现几个试试，你可以给你的map整个过期时间等等，或者换成别的容器，到时候用那个看你指定哪个就好。或者你直接换成redis，全部放redis里面，把你的k-v序列化好就行。
原则就是能用就行，毕竟我们的路线是，完成，完善，完美，完蛋。
这是我们的简单实现，那么mybatis实际上提供了很多内置的实现方式，也就是他自己有很多实现类，我们就来看一下。

四、Mybatis内置缓存实现

我们看一下Mybatis自己内置的实现类。
如何查找应用文件缓存位置,SSM,# Mybatis,JAVA,mybatis,java
这个图好像被压缩了，我来用文字列出这几个类。

Cache (org.apache.ibatis.cache)：这是那个缓存接口
	SoftCache (org.apache.ibatis.cache.decorators)
	PerpetualCache (org.apache.ibatis.cache.impl)
	LoggingCache (org.apache.ibatis.cache.decorators)
	SynchronizedCache (org.apache.ibatis.cache.decorators)
	ScheduledCache (org.apache.ibatis.cache.decorators)
	LruCache (org.apache.ibatis.cache.decorators)
	IkunCache (com.yx.cache) ：这是我们刚才自己实现的，就不说了。
	WeakCache (org.apache.ibatis.cache.decorators)
	FifoCache (org.apache.ibatis.cache.decorators)
	SerializedCache (org.apache.ibatis.cache.decorators)
	BlockingCache (org.apache.ibatis.cache.decorators)
	TransactionalCache (org.apache.ibatis.cache.decorators)

我们看到除了我们自己实现的，mybatis自己内置的几个类貌似分为两种。

一种是属于org.apache.ibatis.cache.decorators包下面的，我们说decorators其实翻译一下就是装饰器
装饰器这三个字有没有唤醒你内心的设计模式之魂，所以我们知道这些类都是装饰器门面，
真正工作的其实不在他这里，其核心实际在下面这个PerpetualCache。
那我们说装饰器模式的作用是装饰器为了给你的目标类增强功能。

第二种是属于org.apache.ibatis.cache.impl包下面的，其实这个包下面就一个PerpetualCache。

根据我们对于装饰器的理解，所以其实他的目标类是在PerpetualCache，其余的都是给他增强功能用的，所以我们直接看PerpetualCache就可以了。

4.1、干活的其实是我，目标PerpetualCache登场

我们来看一下PerpetualCache的源码。

public class PerpetualCache implements Cache {

  private final String id;

  private final Map<Object, Object> cache = new HashMap<>();

  public PerpetualCache(String id) {
    this.id = id;
  }

  @Override
  public String getId() {
    return id;
  }

  @Override
  public int getSize() {
    return cache.size();
  }

  @Override
  public void putObject(Object key, Object value) {
    cache.put(key, value);
  }

  @Override
  public Object getObject(Object key) {
    return cache.get(key);
  }

  @Override
  public Object removeObject(Object key) {
    return cache.remove(key);
  }

  @Override
  public void clear() {
    cache.clear();
  }

  @Override
  public boolean equals(Object o) {
    if (getId() == null) {
      throw new CacheException("Cache instances require an ID.");
    }
    if (this == o) {
      return true;
    }
    if (!(o instanceof Cache)) {
      return false;
    }

    Cache otherCache = (Cache) o;
    return getId().equals(otherCache.getId());
  }

  @Override
  public int hashCode() {
    if (getId() == null) {
      throw new CacheException("Cache instances require an ID.");
    }
    return getId().hashCode();
  }

}

再吐槽一次，你们是真不写注释啊哥，我们看到他除了传入一个id来指定缓存的名字来区分以外，其余的实现也是用了一个HashMap作为缓存容器，除了他重写了equal和hashcode方法，其余的和我们刚才的实现一毛一样。你看看，其实你也是大佬。
但是大佬肯定不能这么粗糙，于是就有了那么多的装饰器，来增强你这个无比粗糙的缓存。

4.2、我来给你加点buff吧，缓存装饰器登场

我们看到了那个缓存干活的类，PerpetualCache，主打一个粗糙，那mybats绝对不会这么low，于是他借助装饰器模式来实现了一组增强功能的装饰器。来看一下。

	LruCache (org.apache.ibatis.cache.decorators)
	FifoCache (org.apache.ibatis.cache.decorators)
	
    SoftCache (org.apache.ibatis.cache.decorators)
	LoggingCache (org.apache.ibatis.cache.decorators)
	SynchronizedCache (org.apache.ibatis.cache.decorators)
	ScheduledCache (org.apache.ibatis.cache.decorators)
	WeakCache (org.apache.ibatis.cache.decorators)
	SerializedCache (org.apache.ibatis.cache.decorators)
	BlockingCache (org.apache.ibatis.cache.decorators)
	TransactionalCache (org.apache.ibatis.cache.decorators)

你看到了，我把LruCache和FifoCache单独列在了一起，和我一样聪明的你一眼就看懂了，Lru和Fifo其实是一种淘汰机制，在内存页置换的时候学习的时候，你是知道的，我不多说了。算了简单说一下。
LRU:Least Recently Used，最近最少使用，换言之就是最近用的最少的数据，就先淘汰。
FIFO:First In First Out,先进先出，我不管你谁用的多，那么花里花哨没用，谁先进来谁先滚，呆那么长时间干嘛。
以上都是在缓存中的数据超过了限制的时候，再有新的数据进来的时候，需要淘汰掉老的缓存数据的时候设计的策略。可见mybatis是实现了这两种的。
LoggingCache (org.apache.ibatis.cache.decorators):增强日志打印的功能
BlockingCache (org.apache.ibatis.cache.decorators)：阻塞增强，保证一时间只有一个线程读写缓存，线程安全得以保证。
ScheduledCache (org.apache.ibatis.cache.decorators)：能够定时自动刷新缓存，按照一定的时间定时去清空缓存。你可以在代码设置这个时间间隔。
SerializedCache (org.apache.ibatis.cache.decorators)：可以自动帮我们完成k-v的序列化和反序列化，序列化方式就是jdk的Serializedble序列化方式。
TransactionalCache (org.apache.ibatis.cache.decorators)：这个装饰器只有在事务操作成功的时候才会写入缓存，你是不是发现这个保证了写入DB和缓存的一致性，不至于事务失败了，缓存写进去了，挺好的是不是。
其余的不常用就不说了。其实主要是加装饰器是为了扩展功能，但是实际上我们一般也不咋用，默认就可以了，如果你需要设计的更加精细可以考虑使用。我们一般还是借助redis去实现分布式缓存。这里的学习是为了学习他的设计。

至于这个装饰器，你说你不会用，你知道的，我会。

4.2.1、缓存装饰器简单操作

我们来写个简单的实现看看装饰器模式怎么用。

@Test
public void testMyCache() throws IOException {
  // 我们先声明一个PerpetualCache 被增强的目标缓存对象
  PerpetualCache perpetualCache = new PerpetualCache("levi");
  // 然后创建加buff的装饰器缓存类，把我们要增强的传入，此时的cache 就是一个有了FIFO的能力缓存了
  FifoCache cache = new FifoCache(perpetualCache);
  // 我们设计缓存大小为5来模拟缓存换出，你看看，增强之后都有设置大小的能力了，
  cache.setSize(5);
  // 放入五个对象，此时已经满了
  for (int i = 0; i < 5; i++) {
    cache.putObject(i, i);
  }
  // 输出一下第一个放入的key就是0的对象
  System.out.println(cache.getObject(0));
  // 再放一个进去，发生换出
  cache.putObject(5, 5);
  // 再取一下第一个放进去的，不出意外的话，他已经没了，因为他第一个放进去，
  // 按照FIFO的逻辑，他被淘汰换出了
  System.out.println(cache.getObject(0));
}

不出意外的话，果然没有意外，输出符合预期。
0
null

4.2.2、缓存装饰器连环设置

我们上面就设置了一个增强，其实他可以多个增强，增强一组能力。写法如下。

@Test
public void testMyCache2() throws IOException {
  PerpetualCache perpetualCache = new PerpetualCache("levi");
  FifoCache fifoCache = new FifoCache(perpetualCache);
  LoggingCache loggingCache = new LoggingCache(perpetualCache);
}

这样他就增强了换出和日志打出的功能，你也可以再加。
或者是链式的写法。

@Test
public void testMyCache3() throws IOException {
  PerpetualCache perpetualCache = new PerpetualCache("levi");
  FifoCache fifoCache = new FifoCache(perpetualCache);
  LoggingCache cache = new LoggingCache(fifoCache);
}

这样都可以。至于什么是装饰器的设计，我会在设计模式写出来。

4.3、贴心的源码

你肯定会问我为啥知道这个装饰器怎么用，首先我告诉你我学过设计模式，那么没学过的兄弟们就不配用吗，mybatis此时从天而降，大喊一声，放开那个姑娘，让我来。
我们看一下mybatis源码有一个test包。这里都有，你照着看就行了，哥们，不难吧。
如何查找应用文件缓存位置,SSM,# Mybatis,JAVA,mybatis,java

五、装饰器模式和代理模式的区别

5.1、核心区别

为啥要提到这两个模式呢，因为我们前面说代理模式的时候，提到过。
代理设计模式：为逻辑添加功能。增强功能。
装饰器模式：现在我们又说装饰器模式也是增强功能。
而且二者的URL设计类图都大差不差，那有啥区别的，用的时候有啥分别呢？
代理模式是为了增强的核心逻辑的额外功能。附加功能。
装饰器模式是为了增强核心逻辑的核心功能。
举个例子，我们的service的事务就是代理模式做的，那你service可能是去查用户，或者登录等等，肯定不是做的事务，事务是额外加的功能，增强的功能不是你要做的事，你本来是登录，他给你增强了事务功能，是两件事。这就是代理模式。
而我们上面的缓存装饰器增强的是缓存的换出和日志，这就是核心功能的增强，增强的是自己的功能，是一件事。这就是他们的区别。

可能你又要问了，既然都差不多，我为啥要听他呢，我用装饰器模式增强额外功能不行吗？
答案是行，就你行，谁能难得到你啊，数你能了。
那么大哥，你的代码以后还有人维护呢，你自己不按规矩来，后面的兄弟是不是会不理解，这样混杂一起，代码只会越来越烂，屎上雕花。

5.2、语法区别

装饰器代码我们刚才看到了，我们能套娃式的链式增强。
但是代理模式好像没这么写。
实际这个理由不充分，因为代理一般就增强一层，实际上他也能多个套，看你写不写了。

// 动态代理的InvocationHandler接口实现
InvocationHandler invocationHandler = new InvocationHandler(){
  @Override
  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    // 这里你可以继续对prox这个代理进行增强套娃，再增强一次，只不过不这么做而已
    Object result = method.invoke(userService, args);
    return result;
  }
};