自定义PubSub,pubsub( 二 )


03. 字典表、配置类的数据这一类的数据是最适合放在缓存中的 , 因为更新频率特别低 , 甚至有时候 insert 了之后就再也不做 update  , 如果这类数据的调用量比较大 , 是一定要放到 Redis 中的;至于缓存策略 , 可以在更新的时候双写数据库和 Redis , 也可以采用自动失效的方式 , 当然这个失效时间可以放得比较长一些;针对我们项目 , 我采用的是半夜 12 点统一失效的策略 , 第一因为我们系统这类数据 , 是夜间通过 ETL 抽取过来的 , 每天同步一次 , 第二就是我们不怕缓存雪崩 , 没有那么大的访问量 , 夜间更没有什么访问量了 。
04. 明显是热点数据的数据有一类数据 , 很明显就是热点数据;我们就有一个接口 , 虽然是业务数据 , 不过数据总量只有几千条 , 但是每天的调用量大约在 40 万 , 而且更新频率不是很高 , 这类数据放入 Redis 中也就再适合不过了;至于缓存策略么 , 因为数据也是从其他系统同步过来的 , 根据数据同步的时间 , 我们最终采用一个小时的失效时间 。
05. 其余数据的评估其实前两种数据很容易就能评估出来 , 关键是这类数据的评估:我们有一个接口日调用量 20-30 万 , 量不大 , 但是查询和处理逻辑比较复杂;基础数据量太大 , 无法把所有数据都放入 Redis 中;无法把基础数据直接放入 Redis 中 , 因为有多重查询维度(条件);无法确定每条数据的调用频率是怎么样的 , 最悲观的结果 , 每条数据当天只调用一次 , 这样就没有缓存的必要了 。
但是咱也不能一拍脑袋就说:“调用量挺大的 , 直接放到 Redis 中吧” , 或者“不好评估 , 算了吧 , 别放缓存了” , 做任何一个决定还是需要有依据的 , 于是我是这样做的:Step 1. 把该接口当天的所有日志都找出来几十个日志文件肯定不能一个一个翻 , 要么就自己写个程序把需要的数据扒出来 , 但是考虑到这个工作可能只做一次 , 我还是尽量节省一些时间吧 。
依然使用 EditPlus 这个工具的【在文件中查找】的功能 , 在查询结果框中【复制所有内容】 , 花了两分钟 , 就把 24 万条日志找出来了 。Step 2. 把数据导入到数据库中进行下一步分析每一条日志大概是这样的:XXXX.log"(64190,95):2020-3-17 16:44:10.092 http-nio-8080-exec-5 INFO 包名.类名 : 请求参数:args1={"字段1":"XXX 。

推荐阅读