Redis缓存设计和更新策略

缓存背景 

   对于大面积的QPS请求 ，传统的数据库的读写分离已经无法满足。当数据库的最大连接数 都达到峰值，这时候如果只是一味的加数据的DB机器 也许可以缓解一下DB压力。但是数据库机器一般都比较贵，从经济成本上来说，不可取。那么对于像秒杀这种场景，一段时间的查询量非常大，活动一结束查询量就会降下来，该如何是好？这时候自然想到缓存系统，提高数据库的响应时间，同时很多请求不必要再查询数据库。

 

1.缓存设计

图片取自互联网来源 https://www.jianshu.com/p/76b82129b78f

当请求发送给服务器的时候，缓存找不到，就查询数据库里，同时回写到缓存。当第二次查询时就可以不用查询数据库，直接到缓存中取数值了。

2.好了缓存设计好了，似乎可以提高数据的并发量了 ，不用加机器了，节约了不少钱，但是这种设计是否是非常完美呢？试想一下，如果数据库的值变了，缓存如何跟着一起更新最新的值呢。

 

2.缓存策略 

2.1一般2种方案 

        更新数据数据时，顺便更新一下缓存 这样数据就一直是最新的数据，实际开发中，也许更新数据是有大数据团队进行更新，用ETL等技术来做，redis，人家一脸懵逼啊。这时作为API开发的我们一脸无奈，只能靠自己了。对这就是我要说的第二种方案，redis过期剔除，这样当缓存没有数据，必然就要去数据库去查，然后回写到redis。主动去更新redis的值，开发自己去控制热点键值的生命周期。当然啦，这时数据一致性和维护成本的一中这种方案。

3.测试，上线一切如此很好，可是活动上线的第二天，运维发邮件说，数据库的负载太高，问我们怎么回事，这时就一脸懵逼了。数据库读写分离了，同时还用了redis做了缓存。怎么数据库的负载还会高呢?不行 有图有真相，我让运维给出负载高的截图。ps 其实这时还是拒接接受这个消息的。 但是人家给出一张图来，我就折服了 高负载都是在某点出现。后来我想了 想 终于知道原因了。tmd还能这么玩 ，给一张图你们自行体会。

3.缓存入坑

缓存大量没命中。。。。。。。。看了一下日志，好几个ip的用户居然24小时在请求查询操作。据我经验判断，这些用户应该就是爬虫的。上午紧急写了一个限流拦截，同时检查了一下代码，不看不知道 看了吓一跳，同事写存储时有漏洞。对于查询数据库也没有的数据的情况，没做处理。假设用户请求很多无用的key，同样会查询数据库。查看日志，发现就有一个ip用户这么干的 不停的换key，流量攻击我们的系统。我思考了一会儿，这些数据库查询不到的数据，value值就给null，咨询了一下产品，对数据实时性要求不是很高。对就这么干。刚写完代码，测试说你这5分钟过期，要是同一时间请求，到下一个时间点又同时请求，刚好时间点时过期时间怎么办？恩 有道理。我赶紧和同事说这个事情，最终决定 在无效key设置过期时间时用随机数。这样就可以空间换时间了。到下午紧急上线。活动持续三天 ，一切很完美。各项指标正常

这里的指标指 我们的api监控系统 主要是1业务响应时间2.接口总调用数3缓存命中数4数据库查询次数

        

后续 热点key的重建优化