1、我看你做的项目中，都用到了redis，你在最近的项目中哪些场景使用了redis呢?
2、缓存穿透
布隆过滤器的误判现象
Redisson和Guava都对布隆过滤器进行了实现
3、缓存击穿
互斥锁，就是一个线程来修改，并占据了锁，另外其他的线程想要访问必须拿到锁，否则就休眠重试，等到修改线程结束后把锁释放了，缓存中也就有新的数据，这个时候其他线程也可以拿到数据了。
设置逻辑过期，没有那么的强一致性，但是整体性能 很高，先让线程去拿老的数据，另外开一个线程去更新数据，其他线程来了也会第一时间拿到老的数据
4、缓存雪崩
5、MySQL怎么跟Redis保持一致？
第一种方式：延时双删
先删除缓存，还是先修改数据库？都会有问题
先删缓存在改数据库的情况
正常情况：
异常情况：初始: 缓存是20，数据库是10，线程1是修改操作，线程1先把20的缓存删除掉了，线程2查询不到缓存，接着查数据库查到了10，把10写入到了缓存中，然后线程2又把数据库给更新为20，现在缓存是10，数据库却是20
先操作数据库再删缓存的情况
正常情况
异常情况：
延时的原因是因为数据库是主从的，延时一段时间保证从库已经完成了主库发来的更改
第二种方案 可以使用共享锁+排他锁的方案来解决缓存一致性的问题
第三种方案 异步通知保证数据的最终一致性
6、Redis的持久化
7、Redis的过期策略
惰性删除
定期删除
8、Redis的数据淘汰策略
9、分布式锁
分布式锁的使用场景：集群情况下的定时任务、抢单、幂等性等场景
lock.tryLock(第一个参数表示等待锁的最大尝试时间，第二个参数表示锁的自动释放时间(此时看门狗就不会生效了，因为redisson认为你自己有控制锁时长的能力，第三个参数是时间单位))，加锁、设置过期时间等操作都是基于LUA脚本完成的
9.1、Redisson是可重入锁吗?
10、Redis的集群方案
11、Redisson获取锁的源码分析
11.1、redissonClient.getLock
getLock的过程就是对底层的数据做一些准备工作，这个时候锁还没有放到redis中去
11.2、lock.lock()
执行完lua脚本后，在redis里就有锁了
11.3、锁的续期
看门狗续期
每 过期时间/3 时间段过后，就会对锁进行一个续期
11.4、锁的释放
11.5、Redisson是可重入锁吗？
第一次上锁redis中的状态：
第二次上锁redis中的状态：
然后第一次释放锁：
然后第二次释放锁：
11.6、实现分布式锁需要注意哪些问题？
11.6.1、不是原子操作
获取锁+设置过期时间写成一行
11.6.2、没有释放锁
设置过期时间 + 手动释放来保证锁一定会被释放
11.6.3、释放了锁，但是业务还没执行完
锁过期时间30s，但是业务执行了35s，另外的线程就可以拿到锁，可能造成数据的不一致
业务没执行完，就续期
11.6.4、释放了别人的锁
- 可以加锁的时候给key加一个UUID
- 释放锁之前判断是否还是当前线程
-
if (lock.isHeldByCurrentThread()) { lock.unlock(); }
11.6.5、大量请求竞争锁失败
- 重试
- 让业务执行时间尽可能短
- 限流
11.6.6、多节点Redis主从复制的问题
11.6.7、锁的性能问题
11.6.8、锁的可重入问题
12、Redis的应用场景
12.1、Token
12.2、短信验证码存储
