redis作为缓存详解

目录

前言：

为什么说关系型数据库性能不高

如何提高MySQL并发量

缓存更新策略

定期更新

实时更新

内存淘汰策略

Redis内置的淘汰策略

缓存常见问题

缓存预热

缓存穿透

缓存雪崩

缓存击穿

---

前言：

    对于缓存的理解，缓存目的就是为了提供更快速的访问效率。一般会使用访问迅速的为访问较为缓慢的作为缓存。例如使用内存作为硬盘的缓存，硬盘作为网络的缓存。使用缓存可以减轻被缓存服务请求数量，一定程度上提供了系统高可用性能。

为什么说关系型数据库性能不高

1）数据库把数据存储在硬盘上，硬盘IO速度并不快，尤其是随机访问。

2）如果查询不能命中索引，就需要进行表遍历，这会大量增加硬盘IO次数。

3）关系型数据库会对SQL进行一系列的解析，优化，校验等工作。

4）一些复杂查询，联表查询，会进行笛卡尔积操作，效率会降低很多。

注意：

    因为mysql等数据库效率比较低，所承担的并发量就有限，一旦请求数量多了，数据库压力就会很大，就很容易宕机。

如何提高MySQL并发量

开源：

    引入更多机器，构成MySQL集群。

节流：

    引入缓存，把一些频繁读取的热点数据，保存在缓存上。后续查询数据的时候，如果缓存中存在，就不去MySQL中进行查询了。

注意：

    数据是存在二八原则的，20%的数据可以满足80%的请求，虽然redis是内存数据库，只能存储少量数据，但基于这个原则，可以大大减少MySQL数据库压力。

缓存更新策略

    如何知道redis中应该存储哪些数据，如何知道哪些数据是热点数据呢？

定期更新

    会把访问的数据以日志形式记录下来，然后就可以分析这些日志数据，得到一些频繁出现的词，那么这些词所对应的数据就算热点数据了，就可以存储在redis中。

    这里redis中的数据可以按照一天一更新，或者一周一更新，定期的进行热点数据统计，更新redis中的数据。

优点：

    上述过程实现起来比较简单，过程更加可控（缓存中有什么数据比较固定），方便排查问题。

缺点：

    实时性不够，如果出发一些特殊事件，有一些本来不是热词的数据成了热词，新热词查询就可能给后面数据库带来比较大的压力。

实时更新

1）先从redis中查询，如果查到数据直接返回。

2）如果redis中不存在，则去数据库查，然后把数据插入redis中。

3）这样不停的往redis中插入数据，就会使redis的内存占用越来越多，逐渐达到上限。此时如果继续往redis中插入数据，就会触发问题。为了解决此问题，redis引入了内存淘汰策略。

内存淘汰策略

1）FIFO(First In First Out)先进先出

    把缓存中存在时间最久的(也就是先来的数据)淘汰掉。

2）LRU (Least Recently Used)淘汰最久未使用的

    记录每个key的最近访问时间.把最近访问时间最老的key淘汰掉。

3）LFU(Least Frequently Used)淘汰访问次数最少的

    记录每个key最近⼀段时间的访问次数。把访问次数最少的淘汰掉.。

4）Random随机淘汰

    从所有的key中抽取幸运儿被随机淘汰掉。

注意：

1）经过一段时间的动态平衡，redis中的数据逐渐就成为了热点数据。

2）具体采用哪种内存淘汰策略，需要根据业务具体问题具体分析。

Redis内置的淘汰策略

    volatile-lru 当内存不足以容纳新写⼊数据时，从设置了过期时间的key中使用LRU（最近最少使用）算法进行淘汰。

    allkeys-lru 当内存不足以容纳新写⼊数据时，从所有key中使⽤LRU（最近最少使用）算法进 进行淘汰。

    volatile-lfu 4.0版本新增，当内存不足以容纳新写⼊数据时，在过期的key中，使用LFU算法 进行删除key。

    allkeys-lfu 4.0版本新增，当内存不足以容纳新写⼊数据时，从所有key中使用LFU算法进行淘汰。

    volatile-random 当内存不足以容纳新写入数据时，从设置了过期时间的key中，随机淘汰数据。

    allkeys-random 当内存不足以容纳新写入数据时，从所有key中随机淘汰数据。

    volatile-ttl 在设置了过期时间的key中，根据过期时间进行淘汰，越早过期的优先被淘汰.。(相当于FIFO，只不过是局限于过期的key)

    noeviction 默认策略，当内存不足以容纳新写入数据时，新写入操作会报错。

注意：

    整体来说redis提供的策略和上述介绍的通用策略是基本⼀致的。只不过redis这里会针对 "过期key" 和 "全部key" 做分别处理。

缓存常见问题

缓存预热

1）定期更新缓存数据，不存在缓存预热情况，首次启动缓存，也会存在一些热点数据，不会给mysql服务造成太大压力。

2）实时更新缓存数据，缓存服务首次启动缓存中是没有数据的，这个时候mysql服务承载的压力就比较大。

解决方案：

    通过离线的方式，向缓存服务导入一些热点数据，首次启动mysql服务就不会有太大压力。随着时间推移，缓存中数据逐渐就都成为热点数据了。

缓存穿透

    查询某个key，redis中不存在，MySQL中也不存在，那么就不会在redis中进行存储。如果存在大量的这些查询，同样会给MySQL造成太大压力。

问题出现场景：

1）业务设计不合理，不如缺少必要的参数校验，导致非法key也被查询了。

2）开发/运维误操作，不小心把部分数据从MySQL中删除了。

3）黑客恶意攻击。

解决方案：

1）如果发现这个key，在redis和MySQL中都不存在，仍然写入redis中，value可设置一个非法值（比如“”），那么后续这些key的查询，在缓存中就可以查询到，就可以执行非法校验逻辑。

2）引入布隆过滤器，每次查询redis/MySQL时，都先判断一下key是否在布隆过滤器中存在。（把所有key都插入到布隆过滤器中），如果布隆过滤器不存在就不需要查询redis或MySQL，MySQL就不会有太大压力。

3）布隆过滤器：本质是结合了 hash + bitmap 不会存储真实数据，但可以判断是否存在。以比较小的空间开销，比较快的时间速度，实现争对key是否存在的判定。

缓存雪崩

    由于在短时间内，redis上大规模的key失效，导致缓存命中率陡然下降，导致MySQL服务压力迅速上升，甚至直接宕机。

问题出现场景：

1）redis直接挂了，redis宕机 / redis集群模式下大量节点宕机。

2）redis没问题，但可能之前短时间内设置很多key到redis中，并且设置的过期时间都是相同的。

解决方案：

1）加强监控报警，保证redis集群的可用性。

2）不给key设置过期时间。

3）key设置过期时间的时候，添加随机因子，避免同一时刻同时失效。

缓存击穿

    相当于缓存雪崩的特殊情况，针对热点key，突然过期了，导致大量请求直接访问数据库，甚至引起数据库直接宕机（热点key的访问频率高，请求数就多，影响更大）

解决方案：

1）基于统计的方式发现热点key，并且设置永不过期。

2）进行必要的服务降级，例如访问数据库的时候使用分布式锁，限制同时请求数据库的并发数。客户端响应时间会比较长，但不至于数据库服务直接挂了。

小结：

    redis作为缓存场景是非常常见的，需要因地制宜选择适合自己业务的功能。