2021-08-13 redis

redis

1、缓存失效

（1）、缓存穿透：指redis和数据都没有数据，而用户不断发送请求，或者对一个不存在的key发送请求，因为redis中没有，大量请求就会落在数据库上，就可能造成数据库崩溃。

解决方案：在redis中缓存空对象、布隆过滤器、mvc拦截器

（2）、缓存雪崩：指在设置缓存key时，采用了相同的过期时间，导致缓存key在同一时间大面积失效，然后全部请求转移到db上，导致db崩溃。

解决方案：在设置key过期时间是，加上随机值，防止缓存数据在同一时间大面积失效。

（3）、缓存击穿：指并发查询同一条数据，此时缓存中数据过期失效，导致所有请求都到db上，造成压力过大。

解决方案：在单机环境下加同步锁就能解决，集群环境下可以使用redis的setnx，互斥锁，使当前请求同步，然后这些请求先查询缓存，缓存没有再查询数据库，然后将数据库的数据局同步到缓存中

分布式锁详解：
1、使用redis的setnx，同一时刻只能设置成功一个，key是固定的 value可以变化
2、需要将redis的操作的原子性，（程序意外宕机，造成死锁可以设置一个过期时间）
3、业务操作完之后需要删除key释放锁，此时解决删除锁操作的原子性，这里可以使用redis加上lua脚本，保证判断锁是否存在和删除锁的操作的原子性
4、使用redission:
（1）、可重入锁
（2）、可重入读写锁
（3）、信号量
（4）、看门狗机制：在加锁时，会给锁设置一个过期时间，但是当锁的过期时间到，线程还没执行完，这是该锁就被其他线程抢占，然后程序执行完，删除锁，这样就会出现线程执行错乱，redission的看门狗机制就是在线程没执行完，就自动给锁续期。当然如果这是redis出现宕机，就不会再给锁续期了。

（4）、缓存与数据库一致性

1、读操作不会存在数据一直问题

2、写操作一般有两种策略

（1）、先更新库在淘汰缓存：假设在更新数据库后，在淘汰缓存时失败，这是缓存就是旧数据，就会出现数据不一致问题

（2）、先淘汰缓存在更新库：假设先淘汰缓存，然后在更新数据库时失败，此时缓存已被淘汰，此时数据库中还是旧数据，因此缓存与数据库不存在数据不一致问题

（3）、上面两种方案：因为先淘汰缓存在更新数据库不会存在数据不一致问题，优先选择它，但是在极端场景下比如并发，还是会存在数据不一致问题，解决思路：采用双删（在更新完数据库后再删除一次缓存）、给缓存设置过期时间、在高并发场景下（可以使用分布式读写锁）。

（4）、使用cannl监听数据库的更新，有更新就同步redis