顾问头条

Redis使用场景

2024-09-06 18:44 由 竹林编梦 发表于 #数据库

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，但内存满不语序写入新数据，默认策略

使用建议