大家好我是小明，今天不谈学习，准备面试。
文章目录
- 1.缓存穿透
- 2.缓存击穿
- 3.缓存雪崩
- [4. 双写一致（数据和缓存数据一致性）](#4. 双写一致（数据和缓存数据一致性）)
-
- [4.1 数据一致性高](#4.1 数据一致性高)
- [4.2 允许数据延迟一致性，保证高性能](#4.2 允许数据延迟一致性，保证高性能)
- [5. redis持久化（rdb, aof）](#5. redis持久化（rdb, aof）)
-
- [5.1 RDB运行原理](#5.1 RDB运行原理)
- [5.2 AOF运行原理](#5.2 AOF运行原理)
- 6.数据过期策略
-
- [6.1 惰性删除](#6.1 惰性删除)
- [6.2 定期删除](#6.2 定期删除)
- 7.数据淘汰策略（内存被占满）
- [8. 分布式锁](#8. 分布式锁)
-
- [8.1 分布式锁的使用场景分析题](#8.1 分布式锁的使用场景分析题)
- [8.2 redis的分布式锁的实现](#8.2 redis的分布式锁的实现)
1.缓存穿透
缓存穿透：查询一个不存在的数据，mysql查询不到也不会写入redis缓存，会导致每次请求都命中（查询）数据库。
解决：
方案一：
缓存空数据，mysql查询不到，返回空数据（null），把这个空结果进行缓存。
方案二：
使用布隆过滤器
缓存预热布隆过滤器，请求到布隆过滤器查询，不存在，直接返回。
redis内部也实现了布隆过滤器。
2.缓存击穿
缓存击穿：给每一个key设置一个过期时间，当key过期的时候，恰好这个时间点对这个key有大量的请求并发过来，这些请求瞬间把db压垮。
原因：
解决方案：
方案一：
互斥锁：
数据强一致性，性能差，适合和钱相关的业务逻辑。
方案二：
不设置过期时间
高可用，性能优。
3.缓存雪崩
缓存雪崩：在同一时间大量缓存key同时失效或者redis服务器宕机，带来的巨大压力。
解决方案：
- 给不同的key添加TTL的随机值
- 使用redis集群模式提高服务器可用性（哨兵，集群模式）
- 给业务流程添加降级限流策略（保底策略）
- 给业务添加多级缓存
4. 双写一致（数据和缓存数据一致性）
这个面试题回答的时候**一定**要回答前提（数据一致性高，允许延迟一致性）
4.1 数据一致性高
使用分布式锁：
使用读写锁
代码：
读锁
写锁：
4.2 允许数据延迟一致性，保证高性能
异步通知保证数据最终的一致性
需要保证mq的可靠性
面试回答：
5. redis持久化（rdb, aof）
redis提供了两种持久化的方式rdb和aof。
面试背景：
redis的数据是缓存在内存上的，redis重启后的数据是缓存在redis快照（在硬盘上面）。
主动备份
配置自动备份
5.1 RDB运行原理
bgsave开始时会frok（复制）一个子进程 ，子进程共享内存数据，完成frork后读取内存数据并写入RDB文件。
5.2 AOF运行原理
AOF是一个追加文件，redis处理每一个命令都会记录在AOF文件，可以看做是命令执行的日志文件。
从写策略
面试回答参考：
6.数据过期策略
redis数据过期删除策略有两种惰性删除 和定期删除。
6.1 惰性删除
惰性删除：设置改该key过期时间后，我们不管它，当需要该key的时候。我们在检查是否过期，如果过期，我们就删除掉他，反之返回该key。
优点：对cpu友好
缺点：对内存不友好
6.2 定期删除
定期删除 ：每隔一段时间，我们对一些key进行检查，删除里面过期的key。
定期清理有两种模式：
- SLOW模式是定时任务，执行频率默认为10hz，每次执行不超过25ms，通过修改配置文件redis.conf的hz选项来调整
- FAST模式执行频率不固定，但两次间隔不低于2ms，每次耗时不超过1ms。
优点 ：可以通过限制删除操作执行的时长和频率来减少删除操作对cpu的影响。另外定期删除，也能有效释放过期键占用的内存。
缺点：难以确定删除操作执行的时长和频率。
redis过期策略：惰性删除+定期删除两种策略进行配合。
面试回答参考：
7.数据淘汰策略（内存被占满）
数据淘汰策略：当redis内存不够用时，此时redis在向内存添加新的key时，那么redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称为内存的淘汰策略。
一定要了解LFU,LRU的面试淘汰策略
8. 分布式锁
常见的使用场景：
抢卷，秒杀。
8.1 分布式锁的使用场景分析题
但是这种情况只能是单体服务下才行通，但是一个项目往往的是集群的，像下面这样子。
上面的代码就不合适了，这时候使用redis分布式锁。
8.2 redis的分布式锁的实现
命令
上锁命令可以简化成
java
setnx lock value ex 10redis如何合理设置锁的有效时长？
这点redis已经实现了，redis采用看门狗的机制，给锁添加执行时间。
实现代码
redisson分布式锁是否是可重入？
解释：
redisson是java封装的redis接口，redisson实现的时候是支持可重入的，但是redis的分布式锁是不可重入的。
实现原理和java的锁一样，即：
java在同一个线程里面，线程id是一样的，使用线程来id来判断是否为同一个线程，是同一个线程就可以获取锁，获取到锁，程序会使用一个hash结构记录线程id和重入次数，加锁的时候重入次数+1，解锁的时候-1。
redisson实现分布式锁主从一致性
现象：
加锁的逻辑没有同步到从节点，这个时候又有其他客户端执行加锁逻辑，这就不行了。
可以使用redisson红锁
能解决主从数据强一致性，但是性能太低了，建一采用zookeeper实现的分布式锁实现数据的强一致性。
好了，这次就到这里，小伙伴们再见。