一,多级缓存架构,从底往上做,先分析缓存数据的生产数据库底层这一块
如上图
-
监听多个 kafka topic,每个 kafka topic 对应一个服务
简化一下,监听一个 kafka topic
-
如果一个服务发生了数据变更,那么就发送一个消息到 kafka topic 中
-
缓存数据生产服务监听到了消息以后,就发送请求到对应的服务中调用接口以及拉取数据,此时是从 mysql 中查询的
-
缓存数据生产服务拉取到了数据之后,会将数据在本地缓存中写入一份,就是 ehcache 中
-
同时会将数据在 redis 中写入一份
而缓存数据生产服务是前两层(nginx、redis)的基石
服务本地堆缓存,我们用什么来做缓存?除了最简单的使用 map 来手动管理缓存之外,还有很多流行的框架可选,Guava cache、ehcache 等,在 spring 中,有一个 Cache 抽象,可以用来支持整合多个缓存框架。我们这里使用 ehcache
spring boot + ehcache 整合起来,演示一下是怎么使用的
springboot2
ehcache.xml
<?xml version="1.0" encoding="UTF-8"?> <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://ehcache.org/ehcache.xsd" updateCheck="false"> <!-- diskStore:ehcache其实是支持内存+磁盘+堆外内存,几个层级的缓存 --> <!-- 在这里设置一下,但是一般不用的 --> <diskStore path="java.io.tmpdir/Tmp_EhCache" /> <!-- defaultCache,是默认的缓存策略 --> <!-- 如果你指定的缓存策略没有找到,那么就用这个默认的缓存策略 --> <!-- external:如果设置为true的话,那么timeout就没有效果,缓存就会一直存在,一般默认就是false --> <!-- maxElementsInMemory:内存中可以缓存多少个缓存条目,在实践中,你是需要自己去计算的,比如你计算你要缓存的对象是什么?有多大?最多可以缓存多少MB,或者多少个G的数据?除以每个对象的大小,计算出最多可以放多少个对象 --> <!-- overflowToDisk:如果内存不够的时候,是否溢出到磁盘 --> <!-- diskPersistent:是否启用磁盘持久化的机制,在jvm崩溃的时候和重启之间,不用 --> <!-- timeToIdleSeconds:对象最大的闲置的时间,如果超出闲置的时间,可能就会过期,我们这里就不用了,缓存最多闲置5分钟就被干掉了 --> <!-- timeToLiveSeconds:对象最多存活的时间,我们这里也不用,超过这个时间,缓存就过期,就没了 --> <!-- memoryStoreEvictionPolicy:当缓存数量达到了最大的指定条目数的时候,需要采用一定的算法,从缓存中清除一批数据,LRU,最近最少使用算法,最近一段时间内,最少使用的那些数据,就被干掉了 --> <defaultCache eternal="false" maxElementsInMemory="1000" overflowToDisk="false" diskPersistent="false" timeToIdleSeconds="300" timeToLiveSeconds="0" memoryStoreEvictionPolicy="LRU" /> <!-- 手动指定的缓存策略 --> <!-- 比如你一个应用吧,可能要缓存很多种不同的数据,比如说商品信息,或者是其他的一些数据 --> <!-- 对不同的数据,缓存策略可以在这里配置多种 --> <cache name="local" eternal="false" maxElementsInMemory="1000" overflowToDisk="false" diskPersistent="false" timeToIdleSeconds="300" timeToLiveSeconds="0" memoryStoreEvictionPolicy="LRU" /> <!-- ehcache这种东西,简单实用,是很快速的,1小时上手可以用在项目里了,没什么难度的 --> <!-- ehcache这个技术,如果讲深了,里面的东西还是很多的,高级的feature,但是我们这里就不涉及了 --> </ehcache>
spring: cache: type: ehcache ehcache: config: classpath:/ehcache.xml
以上配置在 yml 中写,加上 ehcache.xml 就可以了
spring cache 测试
@Service public class CacheServiceImpl implements CacheService { public static final String CACHE_NAME = "local"; /** * 将商品信息保存到本地缓存中 */ @CachePut(value = CACHE_NAME, key = "'key_'+#productInfo.getId()") public ProductInfo saveLocalCache(ProductInfo productInfo) { return productInfo; } /** * 从本地缓存中获取商品信息 */ @Cacheable(value = CACHE_NAME, key = "'key_'+#id") public ProductInfo getLocalCache(Long id) { return null; } }
可以看到,在存在的时候直接返回了传递进来的对象, 但是在读取的时候返回了 null,如果先存后取成功了的话,那么久说明目前正和 ehache 是成功的
@Controller public class CacheController { @Autowired private CacheService cacheService; @RequestMapping("/testPutCache") @ResponseBody public String testPutCache(ProductInfo productInfo) { cacheService.saveLocalCache(productInfo); return "success"; } @RequestMapping("/testGetCache") @ResponseBody public ProductInfo testGetCache(Long id) { return cacheService.getLocalCache(id); } }
启动程序测试
http://localhost:6002/testPutCache?id=1&name=iphone7&price=100.80 http://localhost:6002/testGetCache?id=1
redis 的 LRU 缓存清除算法以及相关配置使用
多级缓存架构,缓存数据生产服务监听各个数据源服务的数据变更的消息, 得到消息之后,然后调用接口拉去数据,将拉取到的数据,写入本地 ehcache 缓存一份
数据还会写入 redis 分布式缓存中一份,你不断的将数据写入 redis,然而 redis 的内存是有限的, 每个 redis 实例最大一般也就是设置 10G,当数据写入的量超过了 redis 能承受的范围之后, 该怎么办呢
redis 是会在数据达到一定程度之后,超过了一个最大的限度之后,就会将数据进行一定的清理, 从内存中清理掉一些数据,只有清理掉一些数据之后,才能将新的数据写入内存中
LRU 算法概述
LRU:Least Recently Used 最近最少使用算法
redis 使用 LRU 策略,因为内存是有限的,但是如果你不断地往 redis 里面写入数据, 那肯定是没法存放下所有的数据在内存的
将最近一段时间内,最少使用的一些数据给干掉。比如说有一个 key,在最近 1 个小时内, 只被访问了一次; 还有一个 key 在最近 1 个小时内,被访问了 1 万次, 当内存满的时候,那么 1 小时内只被访问了 1 次的那条数据将会被清理掉
缓存清理设置
配置文件:redis.conf
-
maxmemory:设置 redis 用来存放数据的最大的内存大小
一旦超出这个内存大小之后,就会立即使用 LRU 算法清理掉部分数据
如果用 LRU,那么就是将最近最少使用的数据从缓存中清除出去
对于 64 bit 的机器,如果 maxmemory 设置为 0,那么就默认不限制内存的使用,直到耗尽机器中所有的内存为止; 但是对于 32 bit 的机器,有一个隐式的限制就是 3GB
-
maxmemory-policy 可以设置内存达到最大限制后,采取什么策略来处理
-
noeviction: 如果内存使用达到了 maxmemory,client 还要继续写入数据,那么就直接报错给客户端
-
allkeys-lru: 就是我们常说的 LRU 算法,移除掉最近最少使用的那些 keys 对应的数据
-
volatile-lru: 也是采取 LRU 算法,但是仅仅针对那些设置了指定存活时间(TTL)的 key 才会清理掉
-
allkeys-random: 随机选择一些 key 来删除掉
-
volatile-random: 随机选择一些设置了 TTL 的 key 来删除掉
-
volatile-ttl: 移除掉部分 keys,选择那些 TTL 时间比较短的 keys
-
对于以上的解释在配置文件中有英文的说明,和上面的基本上一致。
TTL:也就是开发中常说的过期时间,redis 中支持给 key 配置 ttl
实时计算领域中 storm 比较流行,storm 有很多的流分组的一些策略, 按 shuffle 分组、global 全局分组、direct 直接分组、fields 按字段值 hash 后分组, 分组策略也很多,但是真正公司里 99% 的场景下,使用的也就是 shuffle 和 fields 两种策略
redis 也一样,给了这么多种乱七八糟的缓存清理的算法,其实真正常用的可能也就那么一两种,allkeys-lru 是最常用的
缓存清理的流程
-
客户端执行数据写入操作
-
redis server 接收到写入操作之后,检查 maxmemory 的限制,如果超过了限制,那么就根据对应的 policy 清理掉部分数据
-
写入操作完成执行
redis 的 LRU 近似算法
redis 采取的是 LRU 近似算法,也就是对 keys 进行采样,然后在采样结果中进行数据清理
redis 3.0 开始,在 LRU 近似算法中引入了 pool 机制,表现可以跟真正的 LRU 算法相当, 但是还是有所差距的,不过这样可以减少内存的消耗
redis LRU 算法,是采样之后再做 LRU 清理的,跟真正的、传统、全量的 LRU 算法是不太一样的
maxmemory-samples:比如 5,可以设置采样的大小,如果设置为 10,那么效果会更好,不过也会耗费更多的 CPU 资源
maxmemory-samples 在配置文件中也有一部分解释,根据机翻来看,设置 5 会检查 5 个键来进行对比检查, 所以说是近似的,但是具体的思路没有提及到