Java Redis-NoSql缓存面试题

---

前言

最新的 Java 面试题，技术栈涉及 Java 基础、集合、多线程、Mysql、分布式、Spring全家桶、MyBatis、Dubbo、缓存、消息队列、Linux…等等，会持续更新。

如果对老铁有帮助，帮忙免费点个赞，谢谢你的发财手！

1、谈谈你对Redis的理解？

Redis是一个开源的基于Key-Value结构的NoSql内存数据库。一般情况下，Redis 用作客户端和数据库之间操作的缓存，主要目的是减少数据库 IO。
Redis的工作流程是这样的：
当用户需要去读取某个数据的时候，首先会去 Redis 里面查询，如果命中就直接返回。如果没有命中，就从数据库查询，查询到数据后返回给用户，再把这个数据缓存到 Redis 里面。

2、为什么Redis这么受欢迎呢？

• 1)、读写特别快，Redis是纯内存操作，读写速度特别快；
• 2)、支持数据持久化，支持RDB和AOF两种持久化方式；
• 3）、支持数据备份，即主从模式的数据备份，提高redis可用性
• 4)、支持多种数据结构，
  5种常用类型：String、list、hash、set、zset
  3种特殊数据类型：
• geospatial（地理空间），计算两个地点之间的距离，场景：查找附近的人
• Hyperloglog（基数统计），场景：统计集合中不重复的数的个数
• Bitmap（位图），场景：用户签到，用户在线状态，统计日活跃用户等 ）

3、缓存穿透，缓存击穿，缓存雪崩？

• 缓存穿透：是指在同一时段有大量key 请求,但这些key在缓存中不存在，就导致大量的并发请求打到数据库，就会被恶意攻击。
  常见的解决方案有2种：1、缓存空对象；2、布隆过滤器
• 缓存击穿：也叫热点key问题，就是一个被高并发访问的key突然过期了，就导致使大量的并发请求打到数据库，带来巨大压力。
  常见的解决方案有2种：1热点key设置永久有效（persist）；2、分布式锁
• 缓存雪崩：是指在同一时段有大量的key同时过期了，就导致大量的并发请求打到数据库，带来巨大压力，甚至会崩溃。
  常见的解决方案有2种：1、给不同的key随机设置过期时间；2、利用Redis集群提高服务的可用性。
  其实，数据库本身也有最大连接数的限制，超过限制的请求会被拒绝；总的来说，具体选择哪种方式，还是看具体的业务场景。

4、Redis 和 Mysql 如何保证数据一致性？

当用户需要去读取某个数据的时候，首先会去 Redis 里面查询，如果命中就直接返回。如果没有命中，就从数据库查询，查询到数据后返回给用户，再把这个数据缓存到 Redis 里面。这会出现一个问题，就是一份数据，同时保存在Redis和Mysql里面，当数据发生变化的时候，就会出现数据一致性问题：
在这种情况下，能够选择的方法只有2种。

• 第1种，先更新Mysql，再更新Redis：但如果更新Redis失败，就会导致Mysql和 Redis 中的数据不一致；
• 第2种，先删除Redis缓存，再更新Mysql：但是极端情况下，删除 Redis缓存和更新Mysql这两个操作并不是原子的，所以还是会存在数据不一致问题。
  那么就只能采用最终一致性方案：
  第1种方案：基于 MQ 的可靠性消息队列，来实现最终一致性；
  第2种方案：通过alibaba开源的Canal组件，监控 Mysql 中 的binlog 日志，把更新后的数据同步到 Redis 里面；
  如果业务场景不能接受数据的短期不一致性，那就不能使用这些方案来做。

5、Redis 的持久化机制是什么？各自的优缺点？

Redis提供了 RDB（默认） 和 AOF 两种持久化机制：
RDB: 也叫做Redis数据快照，简单来说就是把内存数据都写入到磁盘中的一个dump.rdb二进制文件中(bgsave)。
ROF：Redis每次修改数据的命令，都会追加到aof文件中,然后可以设置每秒刷盘一次，兼顾性能和安全。
我认为 RDB 和 AOF 的优缺点有两个。

• 1、RDB 是每隔一段时间触发持久化，因此数据安全性低，而AOF 可以做到实时持久化，数据安全性较高 ；
• 2、RDB 文件默认采用压缩的方式持久化，而AOF 存储的是执行指令，文件比较大，所以 RDB 在数据恢复的时候性能更好
  在我看来，所谓优缺点，本质上其实是哪种方案更适合当前的应用场景而已。

6、Redis 的主从同步机制：

Redis可以使用主从同步，同步分为全量同步和增量同步：

全量同步：

• 第1步：master节点收到salve节点的psync命令后，执行bgsave命令生成RDB文件，并且在缓冲区中记录之后所有的写操作；
• 第2步：master将生成好的RDB文件发送给slave节点；
• 第3步：slave节点在接收到RDB后，会先将自身的数据全部丢弃，然后加载RDB文件
• 第4步：加载完RDB后，通知主节点将积压在缓冲区的所有写指令发送给自己，然后执行这些写指令，从而实现全量同步。
  在下面2种情况下，都会执行全量同步：第1种是从节点第一次同步；第2种是从节点断开时间太久，导致缓冲区里的指令被覆盖，只能再次全量同步了。

增量同步：

• master节点通过服务器运行ID和偏移量，把积压在缓冲区的所有写指令发送给slave节点，然后salve节点执行这些写指令，