Redis使用场景

Redis使用场景

目次

缓存

• 缓存穿透
  
• 缓存击穿
  
• 缓存雪崩
  
• 双写同等性
  
• 持久化
  
• 数据逾期策略
  
• 数据淘汰策略
  

分布式锁

• 实现原理（setnx、redission）
  

其他

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

缓存

一、缓存穿透

界说：查询一个不存在的数据，Mysql查询不到数据也不会直接写入缓存，导致每次请求都要查数据库
两个解决方案：

• 缓存空数据
  长处：简朴
  缺点：斲丧内存，大概发生差别等问题
  
• 使用布隆过滤器（作用：拦截不存在的数据）
  长处：内存占用较少
  缺点：实现复杂，存在误判
  

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

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

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

关于布隆过滤器

二、缓存击穿

界说：给某个key设置逾期时间，当key逾期时，刚好这个时间点key有大量的并发请求，这些并发请求大概瞬间把DB压垮。

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

两个解决方案：

• 互斥锁
  
• 逻辑逾期
  

互斥锁：强同等性、性能差
比如：跟钱相干的业务必要包管强同等性
互斥锁笔墨描述：线程1请求查询，在redis中未查询到缓存数据，于是获取互斥锁，查询数据库重建缓存数据，写入缓存，释放锁；线程1进行的同时线程2也请求查询未命中，于是获取互斥锁但失败了，只能休眠会再不停重试到缓存命中。
互斥锁的作用：确保任意时刻只有一个线程可以访问共享资源，从而制止数据竞争和差别等问题。

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

三、缓存雪崩

界说：指同一时段大量缓存key同时失效或Redis服务宕机，导致大量请求达到数据库造成巨大压力。
解决方案

• 给差别key的TTL添加随机值（给差别key设置差别的逾期时间）
  
• 使用redis集群服务的可用性，比如哨兵模式、集群模式（解决redis宕机问题）
  
• 给缓存业务添加降级限流策略，比方ngxin、spring cloud gateway
  
• 给业务添加多级缓存，比方Guava、Caffeine
  

降级可作为体系的保底策略，实用于穿透、击穿、雪崩

四、双写同等性

界说：当修改了数据库数据也要更新缓存的数据，保持缓存和数据库的数据同等

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

先删除缓存，照旧先修改数据库？

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

• 正常环境：
  

• 出现脏数据环境：
  

修改数据库数据前被其他线程写入缓存，导致缓存与数据库数据差别等

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

• 正常环境：
  
  
  
  
• 出现脏数据环境：
  

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

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

如何保持强同等性？

• 可以接纳分布式锁（互斥锁）
  

强同等，性能低

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

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

具体代码操作：

• 读操作
  
  
  
  
• 写操作
  
  
  
  

• 异步通知包管数据的终极同等性
  

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

• MQ
  

• canal
  

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

五、持久化

两种方式：RDB、AOF

• RDB(redis数据备份文件，也叫数据快照)
  

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

人工主动备份：

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

• AOF（追加文件，redis处理的每一个下令都记录在AOF文件，可看作是下令日志文件）
  
  
  
  

六、数据逾期策略

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

• 惰性删除
  

界说：访问key时再判定是否逾期，逾期则删除，反之返回key

长处：对CPU友好
缺点：对内存不友好

• 定期删除
  

界说：每隔一段时间，会从一定数量的数据库中取出一定数量的随机key进行检查，并删除其中的逾期key（随之时间推一会遍历所有key，把所有逾期key删除）

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

SLOW模式是定时任务，实行频率默以为10hz，每次不高出25ms，以通过修改配置文件redis.conf的hz选项来调解次数

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

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

七、数据淘汰策略

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

• redis支持8中差别策略来选择删除key
  

• noeviction：不淘汰任何key，但内存满不语序写入新数据，默认策略
  

使用建议

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。