1、热点key的问题怎么解决

第一种解决办法：避免带宽或者传输影响，本地缓存热点key数据，对于每次读请求，将首先检查key是否存在于本地缓存中，如果存在则直接返回，如果不存在再去访问分布式缓存的机器

第二种解决办法：将热点key分散为多个子key，然后存储到缓存集群的不同机器上，这些子key对应的value都和热点key是一样的。当通过热点key去查询数据时，通过某种hash算法随机选择一个子key，然后再去访问缓存机器，将热点分散到了多个子key上。

2、分布式锁

就是通过加锁和解锁来实现保证同一时间只有一个客户端可以对共享资源进行操作
加锁 SETNX key value
解锁 del (key)
配置锁超时 expire (key，30s），防止成为死锁

存在的问题
1、多个命令之间不是原子性操作，如setnx和expire之间，如果setnx成功，但是expire失败，且宕机了，则这个资源就是死锁
解决方案

使用原子命令：设置和配置过期时间  setnx / setex
如: set key 1 ex 30 nx
java里面 redisTemplate.opsForValue().setIfAbsent("seckill_1","success",30,TimeUnit.MILLISECONDS)

2、业务超时，存在其他线程勿删，key 30秒过期，假如线程A执行很慢超过30秒，则key就被释放了，其他线程B就得到了锁，这个时候线程A执行完成，而B还没执行完成，结果就是线程A删除了线程B加的锁
解决方案
使用lua脚本+redis可以在 del 释放锁之前做一个判断，验证当前的锁是不是自己加的锁

加锁+配置过期时间：保证原子性操作，使用setnx setex 可以保证原子性
解锁: 防止误删除、也要保证原子性操作，采用 lua脚本+redis, 由于【判断和删除】是lua脚本执行，所以要么全成功，要么全失败

设计分布式锁应该考虑
a、排他性（在分布式应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行)
b、容错性(分布式锁一定能得到释放，比如客户端奔溃或者网络中断)
c、满足可重入、高性能、高可用
d、注意分布式锁的开销、锁粒度

3、什么是缓存击穿，缓存雪崩，缓存穿透及解决方案

缓存击穿：(某个热点key缓存失效了)
缓存中没有但数据库中有的数据，假如是热点数据，那key在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力增大。
解决方案
设置热点数据不过期；
定时任务定时更新缓存；

缓存雪崩：(多个热点key都过期)
大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。
解决方案
存数据的过期时间设置随机，防止同一时间大量数据过期现象发生
设置热点数据永远不过期，定时任务定时更新

缓存穿透（查询不存在数据）
查询一个不存在的数据，如果从存储层查不到数据则不写入缓存这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。存在大量查询不存在的数据，可能DB就挂掉了，这也是黑客利用不存在的key频繁攻击应用的一种方式
解决方案
接口层增加校验，数据合理性校验
缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，设置短点的过期时间，防止同个key被一直攻击

4、分布式缓存Redis6.x持久化配置AOF和RDB

RDB持久化介绍
在指定的时间间隔内将内存中的数据集快照写入磁盘
默认的文件名为dump.rdb

AOF持久化介绍
append only file，追加文件的方式，文件容易被人读懂
以独立日志的方式记录每次写命令， 重启时再重新执行AOF文件中的命令达到恢复数据的目的
写入过程宕机，也不影响之前的数据，可以通过 redis-check-aof检查修复问题
核心原理
Redis每次写入命令会追加到aof_buf（缓冲区）
AOF缓冲区根据对应的策略向硬盘做同步操作
高频AOF会带来影响，特别是每次刷盘

RDB的优缺点
优点：
RDB最大限度地提高了Redis的性能，父进程不需要参与磁盘I/O
RDB文件紧凑，全量备份，适合用于进行备份和灾难恢复
在恢复大数据集时的速度比 AOF 的恢复速度要快
生成的是一个紧凑压缩的二进制文件
缺点：
如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降至最低，则RDB并不好
RDB经常需要fork才能使用子进程持久存储在磁盘上。如果数据集很大，Fork可能会非常耗时
AOF的优缺点
优点：
数据更加安全
当Redis AOF文件太大时，Redis能够在后台自动重写AOF
AOF以易于理解和解析的格式，一个接一个地包含所有操作的日志
缺点：
AOF文件通常比同一数据集的等效RDB文件大
根据确切的fsync策略，恢复的时候AOF可能比RDB慢

在线上我们到底该怎么做？
RDB持久化与AOF持久化一起使用
如果Redis中的数据并不是特别敏感或者可以通过其它方式重写生成数据
集群中可以关闭AOF持久化，靠集群的备份方式保证可用性
自己制定策略定期检查Redis的情况，然后可以手动触发备份、重写数据；
采用集群和主从同步

5、key淘汰算法

redis key过期策略
定期删除+惰性删除
定期删除：隔一段时间，就随机抽取一些设置了过期时间的 key，检查其是否过期，如果过期就删除。