首先应该理解为什么需要缓存。
在计算机的组成中,关于存储这一块是分层设计的,访问速度从快到慢主要分为:CPU的L1缓存、CPU的L2缓存、CPU的L3缓存、主内存、SSD硬盘、机械硬盘。
其实一开始并没有L1、L2、L3缓存,但CPU访问内存的速度还是慢,在这个过程中CPU只能等,为了优化这一点,在CPU内部加入了这些缓存,主要用于存放内存中的热点数据。举个特例来说,CPU内部的缓存是按缓存行存储的,64位OS的缓存行通常是64字节,如果当前操作的是一个数组对象的话,CPU不会只读取一个数组元素到缓存中,而是会读取多个元素,填充64字节的缓存行,这样一来,如果遍历下一个元素的话,就不用跑内存去拿了。
由上可知,计算机的缓存设计是为了尽量消除CPU与各存储设备的访问延迟。使数据尽早的触达CPU。同样业务开发中,缓存的设计也是为了使数据尽早的触达用户。
但是在业务中,还应该根据业务的特点判断,例如,服务本身没啥访问量,而且都是轻量级操作,即使每次都直接操作DB也没关系,那就没必要设计缓存,这种情况下设计缓存反而会增加系统复杂度。
另外,如果缓存的数据频繁变更,也就是写多读少的情况,也没必要设计缓存。
所以,缓存的应用场景可以概括如下:
1)读多写少。
2)读取的数据是需要经过大量计算得出的,这种可以预计算并缓存起来。
另外聊一下题主说的DB缓存、MyBatis缓存、Redis等。
1)DB缓存、MyBatis缓存的设计思路其实跟上面是一致的,目前数据库的存储上,主流还是使用机械硬盘,而mysql一类的关系型数据库通常是随机读写,机械硬盘的一次随机读写寻址时间大概需要10ms,虽然InnoDB引擎的B+数可以有效缓解随机读写次数,但对于高并发系统来说,这个消耗还是很可观的。再加之每次select操作都需要经过DB的分析器、优化器、执行器、存储引擎,所以操作是比较复杂的,所以这里缓存的目的就是为了尽可能的降低上述操作带来的消耗。
另外,MySQL的数据库缓存,在8版本中已经不支持了,因为每次对于一个row的update操作都会导致缓存失效,update频繁时,此缓存基本处于无效状态。在8之前的版本中,DB缓存的使用场景通常是在数据基本不变更的场景下。
2)Redis。其本质是个无中心设计的分布式内存数据库,基于单进程K-V设计,访问时间复杂度O(1),通常配合关系型数据库使用,可当做关系型数据库的缓存层。这个按需使用即可。