Redis内存回收与缓存问题
内存回收：
1.过期key处理
通过expire命令给key设置ttl
Redis本身是KV型数据库，所有数据都存在RedisDB结构体中，其中有两张哈希表
dict：用于存放KV（这里K是K，V是V）
expires：保存Redis中所有的设置了过期时间的KEY以及到期时间TTL（这里K是K，V是TTL）
过期KEY有两种删除策略：
- 惰性删除，有命令需要操作key时，检测key是否还活着，过期则删除
- 周期删除，通过一个定时任务，周期性抽样带有TTL的key，过期则删除
- slow模式：默认频率10/s，每次执行时长不超过25ms，受server.hz参数影响
- fast模式：频率不固定，跟随内部IO事件循环执行。两次任务之间间隔不低于2ms，执行时长不超过1ms
2.内存淘汰策略
当Redis内存使用达到阈值的时候，Redis会主动挑选一部分key进行删除
什么时候检查是否达到阈值：在每次处理操作的时候都会进行
推荐使用volatile-lfu，其中的lfu与lru都记录在RedisObject中的unsigned lru:LRU_BITS
缓存问题.
缓存一致性
- 数据库双写，具有侵入性。（常用）
- 缓存与数据库整合为一套服务，开发的时候直接调接口。
- CRUD直接基于缓存，然后异步实现数据持久化。性能好，但是流程复杂，而且没有强一致性
低一致性的最佳实践：设一下TTL
高一致性的最佳实践
Q：为什么增删改都只是删除Redis中的数据
A：为了方便，反正我们查询的时候也会重新把数据写入Redis
Q：为什么删除的时候要先操作数据库，再操作Redis？
A：如果先操作Redis会出现线程安全问题：我们首先删除了Redis中的data，接下来进行数据库的操作，这个操作往往被认为是比较慢的。如果这时候同时有别的线程执行了读操作，就会导致Redis中写入了旧的数据，产生了缓存不一致
Q：延迟双删是什么
A：上述操作仍有极低概率造成线程安全问题。我们为了解决这个问题引入了延迟双删：在删除Redis数据之后的一段时间，我们再进行一次删除，确保数据的一致性
缓存穿透
客户端请求的数据在数据库里根本不存在，导致请求穿透缓存直接打到数据库上
解决方案：
- 缓存空对象：给不存在的数据建立缓存null。会额外消耗内存
- 布隆过滤：基于过滤器判断数据是否存在，如果根本不存在，拒绝请求
什么是布隆过滤器：一种数据统计的算法，用于检索一个元素是否存在于集合中。并且布隆过滤器无需存储元素到集合，而是把元素映射在一个很长的二进制数位上。存在一定误差。
缓存雪崩
同一时段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(); } }
