Redis使用场景

Redis使用场景

目录

缓存

  • 缓存穿透
  • 缓存击穿
  • 缓存雪崩
  • 双写一致性
  • 持久化
  • 数据过期策略
  • 数据淘汰策略

分布式锁

  • 实现原理(setnx、redission)

其他

  • 哨兵模式、集群脑裂
  • 分片集群、数据读取规则
  • redis是单线程的却很快

缓存

一、缓存穿透

定义:查询一个不存在的数据,Mysql查询不到数据也不会直接写入缓存,导致每次请求都要查数据库

两个解决方案:

  1. 缓存空数据
    优点:简单
    缺点:消耗内存,可能发生不一致问题

  2. 使用布隆过滤器(作用:拦截不存在的数据)
    优点:内存占用较少
    缺点:实现复杂,存在误判

举例说明:根据文章id查询文章,请求路径如下:
一个get请求: api/enws/getById/1

正常缓存流程:根据id到redis中爬取数据,若找到数据则返回结果;若redis中未找到,再到数据库中查找,将结果返回,返回前需将数据库中查到的数据存储于redis中

缓存穿透是查询一个不存在的数据,Mysql查询不到数据也不会直接写入缓存,导致每次请求都要查数据库。导致这种情况一般是由于系统被恶意攻击,请求路径被获取后制造假id(0、复数、很大的值),疯狂冲击数据库,数据库并发并不高,请求达到一定量就会造成宕机

关于布隆过滤器

二、缓存击穿

定义:给某个key设置过期时间,当key过期时,刚好这个时间点key有大量的并发请求,这些并发请求可能瞬间把DB压垮。

虽然我们再查询时把数据同步到redis,但可能在缓存重建时,存入的是多个表汇总的结果,可能需要分组统计花费较长的时间,比如花费了50毫秒,这时若有大量请求数据库是承受不住的。

两个解决方案:

  1. 互斥锁
  2. 逻辑过期

互斥锁:强一致性、性能差
比如:跟钱相关的业务需要保证强一致性
互斥锁文字描述:线程1请求查询,在redis中未查询到缓存数据,于是获取互斥锁,查询数据库重建缓存数据,写入缓存,释放锁;线程1进行的同时线程2也请求查询未命中,于是获取互斥锁但失败了,只能休眠会再一直重试到缓存命中。
互斥锁的作用:确保任意时刻只有一个线程可以访问共享资源,从而避免数据竞争和不一致问题。

逻辑过期:高可用、性能优
比如:互联网行业,更加注重用户体验
逻辑过期文字描述:线程1查询缓存,发现逻辑时间已过期,获取互斥锁后,开启新线程2查询数据库重建缓存数据、写入缓存并重置逻辑过期时间、释放锁,同时线程1中继续并返回过期数据。线程1进行的同时线程3也查询发现逻辑时间过期,获取互斥锁失败后返回过期数据。当线程4命中缓存并没有过期,就可以获得最新查询数据了。

三、缓存雪崩

定义:指同一时段大量缓存key同时失效或Redis服务宕机,导致大量请求达到数据库造成巨大压力。

解决方案

  1. 给不同key的TTL添加随机值(给不同key设置不同的过期时间)
  2. 利用redis集群服务的可用性,比如哨兵模式、集群模式(解决redis宕机问题)
  3. 给缓存业务添加降级限流策略,例如ngxin、spring cloud gateway
  4. 给业务添加多级缓存,例如Guava、Caffeine

降级可作为系统的保底策略,适用于穿透、击穿、雪崩

四、双写一致性

定义:当修改了数据库数据也要更新缓存的数据,保持缓存和数据库的数据一致

  • 读操作:缓存命中,直接返回;缓存未命中查询数据库,写入缓存,设定超时时间
  • 写操作:延迟双删

先删除缓存,还是先修改数据库?

先删除缓存,再修改数据库

  • 正常情况:

  • 出现脏数据情况:

修改数据库数据前被其他线程写入缓存,导致缓存与数据库数据不一致

先修改操作数据库,再删除缓存

  • 正常情况:

  • 出现脏数据情况:

线程1得到的返回的结果写入缓存,与线程2更新的数据库数据对不上

所以不管先删除缓存,还是先修改数据库都会出现脏数据,应该采取延迟双删的方法,即删除两次缓存,可以降低脏数据的出现。延迟删除是因为数据库是主存模式,延迟删除让主节点把数据同步到从节点,但延迟删除也只是控制了一部分脏数据的风险,由于延迟时间不好确认,也有脏数据的风险,做不到绝对的强一至。

如何保持强一致性?

  1. 可以采用分布式锁(互斥锁)

强一致,性能低

一般存入缓存的数据都是读多写少,用读写锁来进行控制

  • 共享锁:加锁后其他线程可以共享读操作
  • 排他锁:加锁后阻塞其他线程读写操作

具体代码操作:

  • 读操作
  • 写操作
  1. 异步通知保证数据的最终一致性

利用异步通知解决数据同步问题

  • MQ

  • canal

它是基于mysql的主从同步实现
当有数据修改写入数据库后,数据库一旦变化就会记录到BINLOG日志文件中,cannal通过binlog数据文件获取变化,我们就可以在缓存服务获取变化的数据,然后更新到缓存

五、持久化

两种方式:RDB、AOF

  1. RDB(redis数据备份文件,也叫数据快照)

将内存中的数据存到磁盘中,当redis实例故障重启后,从磁盘读取快照文件,恢复数据

人工主动备份:

redis内部有触发RBG的机制,可以在redis.conf文件中找到

  1. AOF(追加文件,redis处理的每一个命令都记录在AOF文件,可看作是命令日志文件)

六、数据过期策略

Redis过期删除策略:惰性删除 + 定期删除两种策略配合使用

  1. 惰性删除

定义:访问key时再判断是否过期,过期则删除,反之返回key

优点:对CPU友好
缺点:对内存不友好

  1. 定期删除

定义:每隔一段时间,会从一定数量的数据库中取出一定数量的随机key进行检查,并删除其中的过期key(随之时间推一会遍历所有key,把所有过期key删除)

  • 定期删除分两种模式:SLOW、FAST

SLOW模式是定时任务,执行频率默认为10hz,每次不超过25ms,以通过修改配置文件redis.conf的hz选项来调整次数

FAST模式执行频率不固定,但两次间隔不低于2ms,每次耗时不好过1ms

优点:可通过限制删除操作执行时长和频率减少删除操作对CPU的影响,另外定期删除能有效释放过期键占用的内存
缺点:难以确定删除操作执行的时长和频率

七、数据淘汰策略

定义:当redis内存不足想添加新key,会按照某种规则将内存数据删除,这种数据删除规则被成为内存的淘汰策略

  • redis支持8中不同策略来选择删除key
  1. noeviction:不淘汰任何key,但内存满不语序写入新数据,默认策略

使用建议