Redis解决多卖或者少卖_当下热点词再学：redis缓存预热、更新、降级，限流

学习还是要有的，梦想不能破灭，你说呢？

缓存预热

系统冷启动

当系统上线时，缓存内还没有数据，如果直接提供给用户使用，每个请求都会穿过缓存去访问底层数据库，如果并发大的话，很有可能在上线当天就会宕机，这种情况就叫“系统冷启动”，因此我们需要在上线前先将数据库内的热点数据缓存至Redis内再提供出去使用，这种操作就成为"缓存预热"。

解决方案

提前给redis中嵌入部分数据，再提供服务。这宛如一句feihua，但是却也是行之有效的好办法。
那如何实施？

肯定不可能将所有数据都写入redis，因为数据量太大了，第一耗费的时间太长了，第二redis根本就容纳不下所有的数据。

所以，就.需要更具当天的具体访问情况，统计出频率较高的热数据。

然后将访问频率较高的热数据写入到redis，如果说热数据也比较多，我们也得多个服务并行的读取数据去写，并行的分布式的缓存预热。

然后将嵌入的热数据的redis对外提供服务，这样就不至于冷启动，直接让数据库崩溃了。

缓存更新

缓存服务(Redis)和数据服务(底层数据库)是相互独立且异构的系统，在更新缓存或更新数据的时候无法做到原子性的同时更新两边的数据，因此在并发读写或第二步操作异常时会遇到各种数据不一致的问题。如何解决并发场景下更新操作的双写一致是缓存系统的一个重要知识点。

即数据一致性，这里不过多讲述了。

那就再提一嘴，延时双删，这里就不展开了，挺多的。

缓存降级

巴拉巴拉一大堆，就是压力过大服务器扛不住了呗，需要适当的取舍。

降级：就是在高并发高负载情况下，选择动态的关闭一下不重要的服务，拒绝访问等，来为重要的服务节省资源，比如电商平台秒杀当天可关闭推荐等功能。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的(如加入购物车、结算)。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

(1)一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级； (2)警告：有些服务在一段时间内成功率有波动(如在95~100%之间)，可以自动降级或人工降级，并发送告警； (3)错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级； (4)严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

限流

如果降级解决不了的压力，那就只有限流了。
限流之前在MQ的那篇文章里面有讲过：消息队列：解耦、异步、削峰，现有MQ对比以及新手入门该如何选择MQ? 限流：就相当于调整水龙头的大小，使得访问请求量控制在一定范围。
对于比较关键又高并发的服务，比如秒杀，不能通过缓存和降级方式解决，至少不够解决太大并发量。这时候就需要限流了。

扫 码 关 注

 

|

|

|