Redis 必知必会常见问题

整理这些问题，主要是大家通过这些问题，去思考redis的实现原理与实际生产过程中遇到了问题，该怎么去解决。希望通过这些问题，可以让大家有一些思考，这是本篇文章的主题。

1、说一下你的项目中使用redis的场景？
我相信在大多数公司，大家用redis就是做一个缓存查询，并没有什么特别的点。但是呢，面试建议大家多说点。
①讲一下Redis的5中数据类型，String list  set zset hash  这里顺道提一下你们用的redis的实际数据是什么，我相信大多数都是string... 做个查询缓存
②Redis 也可以做分布式锁，redisson  红锁基本就是为了实现分布式锁。redisson 还有锁的续命，锁的默认续命时间式30秒，底层采用lua脚本
至于redisson 怎么做？提一下就行了，maven工程pom文件中引入对应的包版本即可。
其实这里也可以更加扩展，根据自己的项目，实现锁的方式不同。如果是单机的我们用JVM级别的锁即可。分布式系统，我们才涉及到redisson

2、Redis是单线程还是多线程？
无论什么版本工作线程都是只有一个的。6.X以上的版本出现的IO多线程。这里可以补一下IO的知识点，如果不太清楚，就不提这里的东西了。

3、Redis存在线程安全吗？为什么？
在单个redis服务器内部是单线程串行的，redis可以保障内部串行，外界使用的时候要保证业务操作上自行保障顺序。

4、遇到过缓存穿透、击穿吗？详细描述下
缓存穿透：数据在redis中不存在，在数据库中也不存在，就返回为空，一般情况下返回为空的值是不会写入redis的，所以如果反复请求同一条数据，则会发生缓存穿透。
针对这种情况，临时的解决方案是给这个Key值设置一个空值，下次请求就不会访问数据库了。但是解决不了根本的问题，因为如果每次请求的是不同的Key依然会存在
在这个问题，所以实际生产环境我们引入布隆过滤器来进行处理。布隆过滤器的大致原理就是：先判断key值是否存在，如果不存在，则不访问redis，这样可以拦截大量
的请求。
缓存击穿：热点key过期（或者以前没有被访问的key 突然增加了大量的并发访问），大量的请求并发对这一个点进行访问。
缓存雪崩：大量key同时过期。临时解决方案：不同key设置不同的过期时间。长期的方案：熔断、限流、隔离

上面三个问题的核心思想就是：避免DB无效，避免重复请求

5、redis缓存怎么删除过期key的？缓存是如何回收的？如何淘汰？
①后台在轮询的时候，分批删除哪些过期的key
②请求的时候判断是否已经过期了

回收：内存空间还很大，但是需要进行过期的判断。
淘汰：内存空间快满了，需要进行删除一些key。LRU、LFU、TTL淘汰策略。此外还有全空间的淘汰。

6、redis如何进行缓存预热？
提前把数据塞进redis中。这个操作意义不大，因为开发人员并不能提前知道一些热点数据，所以还是会出现缓存击穿、穿透等场景。

7、数据库与缓存不一致怎么解决？
Canal binlog     完全的异步化   写操作变慢 MQ
我们使用缓存是倾向于略微有时差，实际在互联网项目中，略微的差异，并不影响实际的体验。

8、简述下redis主从不一致的问题？
①redis 是弱一致性的，异步同步。
②锁不能用主从。单实例、分片集群、redlock ==>  redisson
③在配置中提供了必须有多少个client连接能同步，可以配置同步因子，趋于强一致性
④wait  2 5000  命令

9、简述下redis持久化原理
RDB AOF 主从同步也算持久化
高版本redis中，开启AOF AOF是可以通过执行日志得到全部内存数据的。
实际工作中大家采用RDB+AOF两种结合的方式

10、讲一下redis 的setnx指令
setnx  指令的是原子性的。
如果要做分布式锁，则使用： set k v nx ex (不存在的场景，过期时间考虑，避免死锁)