缓存常见问题

缓存最常见的4个问题： 面试

1. 缓存穿透
2. 缓存雪崩
3. 缓存击穿
4. 数据一致性

缓存穿透

缓存穿透: 是指查询一个不存在的数据，由于缓存无法命中，将去查询数据库，但是数据库也无此记录，并且出于容错考虑，我们没有将这次查询的null写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。

• 解决1 ：空结果也进行缓存，但它的过期时间会很短，最长不超过五分钟，但是不能防止随机穿透。

• 解决2 ：使用布隆过滤器或者Redis的Bitmap来解决随机穿透问题

缓存雪崩

缓存雪崩:是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。

解决1：

原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

解决2：

如果单节点宕机，可以采用集群部署方式防止雪崩

缓存击穿

缓存击穿: 是指对于一些设置了过期时间的key，如果这些key可能会在某些时间点被超高并发地访问，是一种非常“热点”的数据。这个时候，需要考虑一个问题：如果这个key在大量请求同时进来之前正好失效，那么所有对这个key的数据查询都落到db，我们称为缓存击穿。

与缓存雪崩的区别：

1. 击穿是一个热点key失效
2. 雪崩是很多key集体失效

解决：分布式锁

数据一致性问题

数据一致性：在当前环境下，通常我们会首选redis缓存来减轻我们数据库访问压力。但是也会遇到以下这种情况：大量用户来访问我们系统，首先会去查询缓存， 如果缓存中没有数据，则去查询数据库，然后更新数据到缓存中，并且如果数据库中的数据发生了改变则需要同步到redis中，同步过程中需要保证 MySQL与redis数据一致性问题

解决1：使用延时双删策略

延时双删策略是一种常见的保证MySQL和Redis数据一致性的方法。其主要流程包括：先删除缓存，然后更新数据库。这个过程完成后，大约在数据库从库更新后再次删除缓存。具体的步骤如下：

第一步，先执行redis.del(key)操作删除缓存；

第二步，然后执行写数据库的操作；

第三步，休眠一段时间（例如500毫秒），根据具体的业务时间来定；

第四步，再次执行redis.del(key)操作删除缓存。

延时双删策略通过这种方式尝试达到最终的数据一致性，但是这并不是强一致性，因为MySQL和Redis主从节点数据的同步并不是实时的，所以需要等待一段时间以增强它们的数据一致性。同时，由于读写是并发的，可能出现缓存和数据库数据不一致的问题

解决2：使用canal解决

分布式锁

分布式锁主流的实现方案：

1. 基于数据库实现分布式锁
2. 基于缓存（ Redis等）
3. 基于Zookeeper

每一种分布式锁解决方案都有各自的优缺点：

1. 高性能：Redis最高
2. 可靠性：zookeeper最高

分布式锁的关键是多进程共享的内存标记(锁)，因此只要我们在Redis中放置一个这样的标记(数据)就可以了。不过在实现过程中，不要忘了我们需要实现下列目标：

• 多进程可见：多进程可见，否则就无法实现分布式效果
• 避免死锁：死锁的情况有很多，我们要思考各种异常导致死锁的情况，保证锁可以被释放
• 排它：同一时刻，只能有一个进程获得锁
• 高可用：避免锁服务宕机或处理好宕机的补救措施(redis集群架构：1.主从复制 2.哨兵 3.cluster集群)

小总结：

为了确保分布式锁可用，至少要确保锁的实现同时满足以下几个条件：

• 互斥性。在任意时刻，只有一个客户端能持有锁。

• 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

• 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

• 加锁和解锁必须具有原子性。