Redis内存回收与缓存问题

内存回收：

1.过期key处理

通过expire命令给key设置ttl

Redis本身是KV型数据库，所有数据都存在RedisDB结构体中，其中有两张哈希表

　　dict：用于存放KV（这里K是K，V是V）

　　expires：保存Redis中所有的设置了过期时间的KEY以及到期时间TTL（这里K是K，V是TTL）

过期KEY有两种删除策略：

1. 惰性删除，有命令需要操作key时，检测key是否还活着，过期则删除
2. 周期删除，通过一个定时任务，周期性抽样带有TTL的key，过期则删除
   1. slow模式：默认频率10/s，每次执行时长不超过25ms，受server.hz参数影响
   2. fast模式：频率不固定，跟随内部IO事件循环执行。两次任务之间间隔不低于2ms，执行时长不超过1ms
      
      

2.内存淘汰策略

　　当Redis内存使用达到阈值的时候，Redis会主动挑选一部分key进行删除

　　什么时候检查是否达到阈值：在每次处理操作的时候都会进行

　　推荐使用volatile-lfu，其中的lfu与lru都记录在RedisObject中的unsigned lru:LRU_BITS

缓存问题.

缓存一致性

1. 数据库双写，具有侵入性。（常用）
2. 缓存与数据库整合为一套服务，开发的时候直接调接口。
3. CRUD直接基于缓存，然后异步实现数据持久化。性能好，但是流程复杂，而且没有强一致性

低一致性的最佳实践：设一下TTL

高一致性的最佳实践

Q：为什么增删改都只是删除Redis中的数据

A：为了方便，反正我们查询的时候也会重新把数据写入Redis

Q：为什么删除的时候要先操作数据库，再操作Redis？

A：如果先操作Redis会出现线程安全问题：我们首先删除了Redis中的data，接下来进行数据库的操作，这个操作往往被认为是比较慢的。如果这时候同时有别的线程执行了读操作，就会导致Redis中写入了旧的数据，产生了缓存不一致

Q：延迟双删是什么

A：上述操作仍有极低概率造成线程安全问题。我们为了解决这个问题引入了延迟双删：在删除Redis数据之后的一段时间，我们再进行一次删除，确保数据的一致性

缓存穿透

客户端请求的数据在数据库里根本不存在，导致请求穿透缓存直接打到数据库上

解决方案：

1. 缓存空对象：给不存在的数据建立缓存null。会额外消耗内存

   

2. 布隆过滤：基于过滤器判断数据是否存在，如果根本不存在，拒绝请求

   

什么是布隆过滤器：一种数据统计的算法，用于检索一个元素是否存在于集合中。并且布隆过滤器无需存储元素到集合，而是把元素映射在一个很长的二进制数位上。存在一定误差。

缓存雪崩

 同一时段Redis内大量key同时失效，或者Redis突然宕机。大量请求打到数据库，带来巨大压力

解决方案：

• 给不同的key的ttl随机设值
• 利用集群提高服务可用性
• 给缓存业务添加降级限流策略
• 给业务添加多级缓存：网页缓存/NGINX缓存/JVM缓存

缓存击穿

 也称热点key问题，一个被高并发访问且缓存重建业务较复杂的key突然失效了，无数请求访问会瞬间打在数据库上造成压力

解决方案：

• 互斥锁：问题：性能比较差

  

   

• 逻辑过期：

  

java如何实现互斥锁？

public synchronized void test() {
　　// 通过关键字修饰方法或代码块
}

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
 //通过Lock接口
private final Lock lock=new ReentrantLock();
    public void test() {
        lock.lock();
        try {

        }catch (){

        }finally {
            lock.unlock();
        }
    }