Redis教程

Redis 缓存问题

本文主要是介绍Redis 缓存问题,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

为什么要理解 Redis 缓存问题

在高并发的业务场景下,数据库大多数情况下都是用户并发访问最薄弱的环节。所以,就需要使用 Redis 做一个缓存操作,让请求先访问到 Redis ,而不是直接访问 MySQL 等数据库。这样可以大大缓解数据库的压力。

当缓存库出现问题时,必须要考虑如下问题:

  • 缓存穿透
  • 缓存击穿
  • 缓存雪崩
  • 缓存污染(或者满了)
  • 缓存和数据库一致性

缓存穿透

  • 问题来源

缓存穿透是指缓存和数据库中都没有的数据而用户不断发起请求。由于缓存是不命中时被动写的,而且出于容错考虑,如果从 数据库 查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到 数据库 去查询,失去了缓存的意义。

在流量大的时候,可能数据库就挂掉了,要是有人利用不存在的 key 频繁攻击我们的应用,这就是漏洞。

如 发起 id 为“-1”的数据 或者 id 为特别大不存在的数据,这时的用户很可能是攻击者,攻击会导致数据库压力过大。

  • 解决方案
  1. 接口层增加校验。如用户鉴权校验,id 做基础校验,id <= 0 的直接拦截。
  2. 从缓存取不到的数据,在数据库中也没有取到,这时也可以将 key-value对 写为 key-null ,缓存有效时间可以设置 短点 ,如 30秒(设置太长会导致正常情况下也没法使用)。这样就可以防止攻击用户反复用一个 id 暴力攻击。
  3. 布隆过滤器。bloomfilter 就类似于一个 hash set ,用户快速判断某个元素是否存在于集合中,其典型的应用场景就是快速判断一个key是否存在于某容器,不存在就直接返回。布隆过滤器的关键就在于 hash算法 和 容器大小。

缓存击穿

  • 问题来源

缓存击穿是指 缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库取数据,引起数据库压力瞬间增大,造成压力过大

  • 解决方案
  1. 设置热点数据永不过期。
  2. 接口限流与熔断、降级。重要的接口一定要做好限流策略,防止用户恶意刷接口,同时要降级准备,当接口中的某些服务不可用时,进行熔断,失败快速返回机制。
  3. 加互斥锁(redis 分布式锁 或 ReentrantLock),第一个请求的线程可以拿到锁,拿到锁的线程查询到了数据之后设置缓存,其他线程获取锁失败会等待 50ms ,然后重新到缓存拿数据,这样就可以避免大量请求落到数据库。

缓存雪崩

  • 问题来源

缓存雪崩是指 缓存中大批量数据到过期时间,而查询数据量巨大,引起数据库压力过大甚至down机。和缓存击穿不同的是,缓存击穿指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。

  • 解决方案
  1. 缓存数据的过期时间设置随机,防止同一时间大量数据过期现象的发生。
  2. 如果缓存数据库是分布式部署,将热点数据均匀分布在不同的缓存数据库中
  3. 设置热点数据永不过期

缓存污染(或满了)

缓存污染问题说的是缓存中一些只会被访问一次或者几次的数据,被访问完后,再也不会被访问到,但这部分数据依然留存在缓存中,消耗缓存空间。

缓存污染会随着数据的持续增加而逐渐显露,随着服务的不断运行,缓存中会存在大量的永远不会再次被访问的数据。缓存空间是有限的,如果缓存空间满了,再往缓存里写数据时就会有额外开销,影响 Redis 性能。这部分额外开销主要是指 写的时候判断淘汰策略,根据淘汰策略去选择要淘汰的数据,然后进行删除操作。

最大缓存设置多大?

建议把缓存容量设置为总数据量的 15% 到 30% ,兼顾访问性能和内存空间开销。

但是,缓存被写满是不可避免的,所以需要缓存淘汰策略。

数据库和缓存一致性

  • 问题来源:

使用 Redis 做一个缓冲操作,让请求先访问到 Redis ,而不是直接访问 MySQL 数据库:

读取缓存步骤一般没有什么问题,但是一旦涉及到数据更新:数据库和缓存更新,就容易出现缓存(Redis)和数据库(MySQL)间的数据一致性问题。

不管是先写 MySQL 数据库,再删除 Redis 缓存;还是先删除缓存,再写库,都有可能出现数据不一致的情况。举个栗子:

  1. 如果删除缓存 Redis,但还没来得及 写库 MySQL,另一个线程就来读取,发现缓存为空,则去数据库中读取数据写入缓存,此时缓存中为脏数据。
  2. 如果先写了库,在删除缓存前,写库的线程宕机了,没有删除掉缓存,则也会出现数据不一致的情况。

因为写和读是并发的,没法保证顺序,就会出现缓存和数据库的数据不一致的问题。

更新缓存的 Design Pattern 有四种:Cache Aside,Read Through,Write Through,Write Behind Caching

Cache Aside Pattern

最常用的是 Cache Aside Pattern,总结来说是:

  • 读的时候:先读缓存,缓存没有的话,就读数据库,然后取出数据后放入缓存,同时返回响应。
  • 更新的时候:先更新数据库,然后再删除缓存。

其具体逻辑如下:

  • 失效:应用程序先从 cache 取数据,没有的到,则从数据库中取数据,成功后,放到缓存中。
  • 命中:应用程序从 cache 中取数据,取到后返回。
  • 更新:先把数据存到数据库中,成功后,再让缓存淘汰。

为什么建议淘汰缓存,而不是更新缓存?

答:如果更新缓存,在并发写时,可能出现数据不一致的情况。

如果采用更新缓存,在 请求1 和 请求2 并发写 发生时,由于无法保证时序,此时不管先操作缓存还是先操作数据库,都可能出现:

  1. 请求1 先操作数据库,请求2 后操作数据库
  2. 请求2 先更新缓存,请求1 后更新了缓存

导致,数据库 和 缓存之间的数据不一致

所以,Cache Aside Pattern 建议,删除缓存,而不是更新缓存

为什么建议先操作数据库,再操作缓存?

答:如果先操作缓存,在读写并发时,可能出现数据不一致

如果先操作缓存,在 请求1 和 请求2 并发读写 发生时,由于无法保证时序,可能出现:

  1. 写请求淘汰了缓存
  2. 写请求操作了数据库(主从同步没有完成
  3. 读请求读了缓存(因为缓存被淘汰,所以没有命中
  4. 读请求读了从库(读了一个旧数据
  5. 读请求 set 回数据库(set 了一个旧数据)
  6. 数据库主从同步完成

导致,数据库和缓存的数据不一致

所以,Cache Aside Pattern 建议,先操作数据库,再操作缓存

存在的问题?

答:如果先操作数据库,再淘汰缓存,在原子性被破坏时:

  1. 修改数据库成功了
  2. 淘汰缓存失败了

导致,数据库和缓存的数据不一致

举个例子:一个是读操作,但是没有命中缓存,然后就到数据库中取数据,此时来了一个写操作,写完数据库后,让缓存失效,然后之前的读操作再把旧的数据放进缓存,所以会造成脏数据,导致数据库和缓存的数据不一致。

但这个事件理论上会出现,不过,实际上出现的概率可能非常低,因为这个条件需要发生在读缓存时缓存失效,而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢的多,而且还要锁表,而读操作必须在写操作前进入数据库操作,而又晚于写操作更新缓存,所有的这些条件都具备的概率基本不大。

解决方案:队列 + 重试机制

流程如下:

  1. 更新数据库数据;
  2. 缓存因为种种问题删除失败;
  3. 将需要删除的key发送至消息队列;
  4. 自己消费消息,获得需要删除的key;
  5. 继续重试删除操作,直到成功

缺点:对业务线代码造成大量的侵入。

解决方案:异步更新缓存(基于订阅binlog的同步机制)

技术整体思路:

MySQL binlog 增量订阅消费+消息队列+增量数据更新到Redis

  • 读Redis :热数据基本都在 Redis
  • 写MySQL :增删改都是操作 MySQL
  • 更新 Redis 数据:MySQL的数据操作binlog 来更新到Redis

Redis 更新

  1. 数据操作主要分为两大块:

    • 一个是全量(将全部数据一次写入到Redis)
    • 一个是增量(实时更新)

    增量:MySQL 的update、insert、delete变更数据

  2. 读取binlog 后分析,利用消息队列,推动更新各台的 Redis 缓存数据

    这样一旦MySQL 中产生了新的写入、更新、删除等操作,就可以把binlog相关的消息推送到Redis,Redis 再根据binlog中的记录,对Redis 进行更新。

其实这种机制,很类似 MySQL 的主从备份机制,因为 MySQL 的主备也是通过 binlog 来实现的数据一致性。

这篇关于Redis 缓存问题的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!