【数据产品】缓存设计

背景为什么需要做缓存

我所做的产品的指标设计越来越复杂查询性能也随之下降。因此需要增加缓存层 以提高接口查询效率。

哪些层需要做缓存

随着指标系统的应用该产品的查询逻辑也越来越简单无非就是API层生成SQL然后调用Metric-Server执行查询返回ListMap然后API层再解析成前端需要的对应数据结构。

(该服务确实经历过几次大改版从传统的api调service再到微服务拆分成多个域再到如今的api调metric-server的指标配置方式整个过程真是应了那句古话天下大势合久必分分久必合)

从上图可以看见能做缓存的层有两个一个是API的接口层二是Metric-server的查询层。

我们先从底层往上做缓存这样可复用的查询就越多。

缓存的粒度

缓存主要是减轻数据库DB的压力。

日周维度理论上是不需要缓存的因为日周查询的数据量不会太大其次就是日周数据每天或每七天就会发生变化缓存命中率可能不很高低命中率的缓存是一种资源浪费。

因此优先考虑月季年进行缓存。

但对于日维度等频繁查询的数据也应进行缓存比如首页概览页面等这种页面可以考虑请求合并。

缓存的数据

因为我们现在都是一个SQL对应一个list

那么什么样的SQL需要缓存呢(总结就是对数据库产生压力的sql)

一是查询慢的二是查询次数多的。

因此我们可以设定一个标准

当 【查询时间 > x秒 && 查询次数 > x次 】时进行数据缓存。

或者

当【查询次数 > x次】时也进行缓存。

缓存的方式

1. 强制缓存请求合并对于一些概览页面每次进入App会频繁调用对于这部分数据可以强制缓存。

2. 主动缓存对于未强制指定缓存的业务查询慢且频繁调用主动进行缓存。

3. 预测缓存对于1和2的中的SQL如果新的表回流任务更新则提前预测查询(这里的缓存阈值可以与1、2不同)进行缓存。

缓存的方案

缓存的监控

缓存的监控同样也很重要一方面是监控每天缓存情况保证缓存正常运行另一方面监控redis数据库容量保证不被打满设置合理的缓存阈值。