1、Redis 的持久化机制是什么？各自的优缺点？
快照形式：每隔一段时间对redis内存里的数据进行快照存储，当要恢复数据时，直接恢复快照即可。（相当于一个镜像，上次什么样，我就恢复到那个样子）
- 缺点：如果形成快照5分钟后，还没有进行下一次备份，redis就宕机了，那么这5分钟的数据就丢了。
- 优点：快照形式占用磁盘空间较少，而且是靠而哇哦的线程去做的快照备份，对redis性能不会有太大损耗。
日志形式：redis每次增删改都会形成一条日志
- 缺点：占用空间比快照形式大，而且当日志文件较大时，对redis的性能会有影响
- 优点:实时性高
一般都会采用这两种方案结合
2、redis 过期键的删除策略？
立即删除：只要收到删除指令，就对key进行删除。
- 缺点：对redis的性能会有损耗。
惰性删除：给每个key加个是否删除的属性（redis已经帮我们做了，我们只需要配置），收到删除指令后先不删除，先修改这个属性，等下次查询到这个key的时候，先看一下这个属性有没有删除，如果有就删除。如果不查询这个key，就永远不删。
- 缺点：比较占用空间
定时删除：每隔一段时间，对过期的key进行批量删除。
- 缺点：如果需要删除的key很多，对redis性能的损耗比立即删除还要大。
一般情况下，会用2、3结合（白天惰性删除、晚上定时删除）
3、Redis 常见异常问题和解决方案（雪崩，穿透...）
缓存雪崩：缓存在同一时刻同时过期，加缓存的意义是减少数据库压力。
- ---->解决方案：避免让所有的key同时过期，例如热点数据（首页、官网）不设置过期时间。这个需从架构层面考虑优化，或者说编写定时任务，定期从缓存里同步数据。
缓存穿透：查询的key在redis里一直不存在。比如key是long类型的，但是查询缓存的时候，一直用"3dsdfs"(字符串) 这种场景，这种场景经常出现网络攻击，比如查询的key是某个搜索条什或者账号，需要输入的是Long类型，而我总是输入字符串，那么将一直无法命中缓存，导致每次都要查询数据库。
---->解决方案:
- 1、对key值先进行校验。（比如说证件号码，如果出现格式错误，或者说取值范围不对，或者构造形式不对等等，直接返回错误，不进行数据库查询）
- 2、使用布隆过滤器。布隆过滤器也是redis提供的一种数据结构，他能够从海量数据（上千万)中快速判断这个数据存不存在（准确率不是百分之百）。 将数据库所有id预先放到布隆过滤器内，每次查询先看布隆过滤器里边有没有，有的话再查，没有就不查。