【数据产品】基于通知机制的缓存设计

1. 背景：为什么需要做缓存？

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

2. 哪些层需要做缓存？

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

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

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

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

3. 缓存的粒度？

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

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

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

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

4. 缓存的数据？

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

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

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

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

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

或者

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

缓存的方式？

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

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

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

5. 缓存的方案？

6. 缓存的监控

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