Java面试题(六)--Redis

1 Redis基础篇

1、简单介绍一下Redis优点和缺点？

优点：

1、本质上是一个 Key-Value 类型的内存数据库，很像memcached

2、整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据 flush 到硬盘上进行保存

3、因为是纯内存操作，Redis 的性能非常出色，每秒可以处理超过 10 万次读写操作，是已知性能最快的Key-Value DB

4、Redis最大的魅力是支持保存多种数据结构(string,list,set,hash,sortedset)，此外单个 value 的最大限制是 1GB，不像memcached只能保存 1MB 的数据

5、Redis也可以对存入的 Key-Value 设置 expire 时间，因此也可以被当作一个功能加强版的memcached 来用

缺点：

1、Redis 的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此 Redis 适合的场景主要局限在较小数据量的高性能操作和运算上。

2、没有丰富的搜索功能

2、系统中为什么要使用缓存？

主要从“高性能”和“高并发”这两点来看待这个问题。

高性能：

假如用户第一次访问数据库中的某些数据。这个过程会比较慢，因为是从硬盘上读取的。将该用户访问的数据存在数缓存中，这样下一次再访问这些数据的时候就可以直接从缓存中获取了。操作缓存就是直接操作内存，所以速度相当快。如果数据库中的对应数据改变的之后，同步改变缓存中相应的数据即可！

高并发：

直接操作缓存能够承受的请求是远远大于直接访问数据库的，所以我们可以考虑把数据库中的部分数据转移到缓存中去，这样用户的一部分请求会直接到缓存这里而不用经过数据库。

3、常见的缓存同步方案都有哪些？(高频)

同步方案：更改代码业务代码，加入同步操作缓存逻辑的代码(数据库操作完毕以后，同步操作缓存)

异步方案：

1、使用消息队列进行缓存同步：更改代码加入异步操作缓存的逻辑代码(数据库操作完毕以后，将要同步的数据发送到MQ中，MQ的消费者从MQ中获取数据，然后更新缓存)

2、使用阿里巴巴旗下的canal组件实现数据同步：不需要更改业务代码，部署一个canal服务。canal服务把自己伪装成mysql的一个从节点，当mysql数据更新以后，canal会读取binlog数据，然后在通过canal的客户端获取到数据，更新缓存即可。

4、Redis常见数据结构以及使用场景有哪些？(高频)

1、 string

常见命令：set、get、decr、incr、mget等。

基本特点：string数据结构是简单的key-value类型，value其实不仅可以是String，也可以是数字。

应用场景：常规计数：微博数，粉丝数等。

2、hash

常用命令： hget、hset、hgetall等。

基本特点：hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象，后续操作的时候，你可以直接仅仅修改这个对象中的某个字段的值。

应用场景：存储用户信息，商品信息等。

3、list

常用命令: lpush、rpush、lpop、rpop、lrange等。

基本特点：类似于Java中的list可以存储多个数据，并且数据可以重复，而且数据是有序的。

应用场景：存储微博的关注列表，粉丝列表等。

4、set

常用命令： sadd、spop、smembers、sunion 等

基本特点：类似于Java中的set集合可以存储多个数据，数据不可以重复，使用set集合不可以保证数据的有序性。

应用场景：可以利用Redis的集合计算功能，实现微博系统中的共同粉丝、公告关注的用户列表计算。

5、sorted set

常用命令： zadd、zrange、zrem、zcard 等。

基本特点：和set相比，sorted set增加了一个权重参数score，使得集合中的元素能够按score进行有序排列。

应用场景：在直播系统中，实时排行信息包含直播间在线用户列表，各种礼物排行榜等。

5、Redis有哪些数据删除策略？(高频)

数据删除策略：Redis中可以对数据设置数据的有效时间，数据的有效时间到了以后，就需要将数据从内存中删除掉。而删除的时候就需要按照指定的规则进行删除，这种删除规则就被称之为数据的删除策略。

Redis中数据的删除策略：

① 定时删除

• 概述：在设置某个key 的过期时间同时，我们创建一个定时器，让定时器在该过期时间到来时，立即执行对其进行删除的操作。

• 优点：定时删除对内存是最友好的，能够保存内存的key一旦过期就能立即从内存中删除。

• 缺点：对CPU最不友好，在过期键比较多的时候，删除过期键会占用一部分CPU时间，对服务器的响应时间和吞吐量造成影响。

② 惰性删除

• 概述：设置该key过期时间后，我们不去管它，当需要该key时，我们在检查其是否过期，如果过期，我们就删掉它，反之返回该key。

• 优点：对CPU友好，我们只会在使用该键时才会进行过期检查，对于很多用不到的key不用浪费时间进行过期检查。

• 缺点：对内存不友好，如果一个键已经过期，但是一直没有使用，那么该键就会一直存在内存中，如果数据库中有很多这种使用不到的过期键，这些键便永远不会被删除，内存永远不会释放。

③ 定期删除

• 概述：每隔一段时间，我们就对一些key进行检查，删除里面过期的key(从一定数量的数据库中取出一定数量的随机键进行检查，并删除其中的过期键)。

• 优点：可以通过限制删除操作执行的时长和频率来减少删除操作对 CPU 的影响。另外定期删除，也能有效释放过期键占用的内存。

• 缺点：难以确定删除操作执行的时长和频率。

  如果执行的太频繁，定期删除策略变得和定时删除策略一样，对CPU不友好。如果执行的太少，那又和惰性删除一样了，过期键占用的内存不会及时得到释放。

另外最重要的是，在获取某个键时，如果某个键的过期时间已经到了，但是还没执行定期删除，那么就会返回这个键的值，这是业务不能忍受的错误。

Redis的过期删除策略：惰性删除 + 定期删除两种策略进行配合使用定期删除函数的运行频率，在Redis2.6版本中，规定每秒运行10次，大概100ms运行一次。在Redis2.8版本后，可以通过修改配置文件redis.conf 的 hz 选项来调整这个次数。

6、Redis中有哪些数据淘汰策略？(高频)

数据的淘汰策略：当Redis中的内存不够用时，此时在向Redis中添加新的key，那么Redis就会按照某一种规则将内存中的数据删除掉，这种数据的删除规则被称之为内存的淘汰策略。

常见的数据淘汰策略：

noeviction # 不删除任何数据，内存不足直接报错(默认策略)

 volatile-lru # 挑选最近最久使用的数据淘汰(举例：key1是在3s之前访问的, key2是在9s之前访问的，删除的就是key2)

 volatile-lfu # 挑选最近最少使用数据淘汰 (举例：key1最近5s访问了4次, key2最近5s访问了9次， 删除的就是key1)

 volatile-ttl # 挑选将要过期的数据淘汰

 volatile-random # 任意选择数据淘汰

 allkeys-lru # 挑选最近最少使用的数据淘汰

 allkeys-lfu # 挑选最近使用次数最少的数据淘汰

 allkeys-random # 任意选择数据淘汰，相当于随机

注意：

1、不带allkeys字样的淘汰策略是随机从Redis中选择指定的数量的key然后按照对应的淘汰策略进行删除，带allkeys是对所有的key按照对应的淘汰策略进行删除。

2、缓存淘汰策略常见配置项

maxmemory-policy noeviction # 配置淘汰策略

 maxmemory ?mb # 最大可使用内存，即占用物理内存的比例，默认值为0，表示不限制。生产环境中根据需求设定，通常设置在50%以上。

 maxmemory-samples count # 设置redis需要检查key的个数

7、Redis中数据库默认是多少个db即作用？

Redis默认支持16个数据库，可以通过配置databases来修改这一数字。客户端与Redis建立连接后会自动选择0号数据库，不过可以随时使用select命令更换数据库。

Redis支持多个数据库，并且每个数据库是隔离的不能共享，并且基于单机才有，如果是集群就没有数据库的概念。

8、缓存穿透、缓存击穿、缓存雪崩解决方案？(高频)

加入缓存以后的数据查询流程：



缓存穿透：

概述：指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到 DB 去查询，可能导致 DB 挂掉。

解决方案：

1、查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短

2、布隆过滤器：将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对DB的查询

缓存击穿：

概述：对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端 DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把 DB 压垮。

解决方案：

1、使用互斥锁：当缓存失效时，不立即去load db，先使用如 Redis 的 setnx 去设置一个互斥锁，当操作成功返回时再进行 load db的操作并回设缓存，否则重试get缓存的方法

2、永远不过期：不要对这个key设置过期时间

缓存雪崩：

概述：设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB 瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。

解决方案：

将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

9、什么是布隆过滤器？(高频)

概述：布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上由一个很长的二进制向量(二进制数组)和一系列随机映射函数(hash函数)。



作用：布隆过滤器可以用于检索一个元素是否在一个集合中。

添加元素：将商品的id(id1)存储到布隆过滤器



假设当前的布隆过滤器中提供了三个hash函数，此时就使用三个hash函数对id1进行哈希运算，运算结果分别为：1、4、9那么就会数组中对应的位置数据更改为1。

判断数据是否存在：使用相同的hash函数对数据进行哈希运算，得到哈希值。然后判断该哈希值所对应的数组位置是否都为1，如果不都是则说明该数据

肯定不存在。如果是说明该数据可能存在，因为哈希运算可能就会存在重复的情况。如下图所示：



假设添加完id1和id2数据以后，布隆过滤器中数据的存储方式如上图所示，那么此时要判断id3对应的数据在布隆过滤器中是否存在，按照上述的判断规则应该是存在，但是id3这个数据在布隆过滤器中压根就不存在，这种情况就属于误判。

误判率：数组越小误判率就越大，数组越大误判率就越小，但是同时带来了更多的内存消耗。

删除元素：布隆布隆器不支持数据的删除操作，因为如果支持删除那么此时就会影响判断不存在的结果。

使用布隆过滤器：在谷歌的guava缓存工具中提供了布隆过滤器的实现，使用方式如下所示：

pom.xml文件

com.google.guava

     guava

     20.0

测试代码：

// 创建一个BloomFilter对象

 // 第一个参数：布隆过滤器判断的元素的类型

 // 第二个参数：布隆过滤器存储的元素个数

 // 第三个参数：误判率，默认值为0.03

 int size = 100_000 ;

 BloomFilter bloomFilter = BloomFilter.create(Funnels.stringFunnel(Charset.defaultCharset()), size, 0.03);

 for(int x = 0 ; x < size ; x++) {

     bloomFilter.put("add" + x) ;

 }

 ​

 // 在向其中添加100000个数据测试误判率

 int count = 0 ;     // 记录误判的数据条数

 for(int x = size ; x < size * 2 ; x++) {

     if(bloomFilter.mightContain("add" + x)) {

         count++ ;

         System.out.println(count + "误判了");

    }

 }

 ​

 // 输出

 System.out.println("总的误判条数为：" + count);

Redis中使用布隆过滤器防止缓存穿透流程图如下所示：

10、Redis数据持久化有哪些方式？各自有什么优缺点？(高频)

在Redis中提供了两种数据持久化的方式：1、RDB 2、AOF

RDB：定期更新，定期将Redis中的数据生成的快照同步到磁盘等介质上，磁盘上保存的就是Redis的内存快照

优点：数据文件的大小相比于aof较小，使用rdb进行数据恢复速度较快

缺点：比较耗时，存在丢失数据的风险

AOF：将Redis所执行过的所有指令都记录下来，在下次Redis重启时，只需要执行指令就可以了

优点：数据丢失的风险大大降低了

缺点：数据文件的大小相比于rdb较大，使用aof文件进行数据恢复的时候速度较慢

11、Redis都存在哪些集群方案？

在Redis中提供的集群方案总共有三种：

1、主从复制

• 保证高可用性

• 实现故障转移需要手动实现

• 无法实现海量数据存储

2、哨兵模式

• 保证高可用性

• 可以实现自动化的故障转移

• 无法实现海量数据存储

• 监控

• 故障转移

• 通知客户端

3、Redis分片集群

• 保证高可用性

• 可以实现自动化的故障转移

• 可以实现海量数据存储

12、说说Redis哈希槽的概念？

Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念，Redis 集群有 16384 个哈希槽，每个 key通过 CRC16 校验后对 16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash 槽。

13、Redis中的管道有什么用？

一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应，这样就可以将多个命令发送到服务 器，而不用等待回复，最后在一个步骤中读取该答复。

14、谈谈你对Redis中事务的理解？(高频)

事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

Redis中的事务：Redis事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。

总结说：Redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

15、Redis事务相关的命令有哪几个？(高频)

事务相关的命令：

1、MULTI：用来组装一个事务

2、EXEC：执行一个事务

3、DISCARD：取消一个事务

4、WATCH：用来监视一些key，一旦这些key在事务执行之前被改变，则取消事务的执行

5、UNWATCH：取消 WATCH 命令对所有key的监视

如下所示：

16、Redis如何做内存优化？

尽可能使用散列表（hash），散列表（是说散列表里面存储的数少）使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。

比如你的 web 系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。

17、Redis是单线的，但是为什么还那么快？(高频)

Redis总体快的原因：

1、完全基于内存的

2、采用单线程，避免不必要的上下文切换可竞争条件

3、使用多路I/O复用模型，非阻塞IO

2 分布式锁篇

18、什么是分布式锁？

概述：在分布式系统中，多个线程访问共享数据就会出现数据安全性的问题。而由于jdk中的锁要求多个线程在同一个jvm中，因此在分布式系统中无法使用jdk中的锁保证数据的安全性，那么此时就需要使用分布式锁。

作用：可以保证在分布式系统中多个线程访问共享数据时数据的安全性

举例：

在电商系统中，用户在进行下单操作的时候需要扣减库存。为了提高下单操作的执行效率，此时需要将库存的数据存储到Redis中。订单服务每一次生成订单之前需要查询一下库存数据，如果存在则生成订单同时扣减库存。在高并发场景下会存在多个订单服务操作Redis，此时就会出现线程安全问题。

分布式锁的工作原理：



分布式锁应该具备哪些条件：

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行

2、高可用的获取锁与释放锁

3、高性能的获取锁与释放锁

4、具备可重入特性

5、具备锁失效机制，防止死锁

可重入特性：获取到锁的线程再次调用需要锁的方法的时候，不需要再次获取锁对象。

 使用场景：遍历树形菜单的时候的递归调用。

注意：锁具备可重入性的主要目的是为了防止死锁。

19、分布式锁的实现方案都有哪些？(高频)

分布式锁的实现方案：

1、数据库

2、zookeeper

3、redis

20、Redis怎么实现分布式锁思路？(高频)

Redis实现分布式锁主要利用Redis的setnx命令。setnx是SET if not exists(如果不存在，则 SET)的简写。

127.0.0.1:6379> setnx lock value1 #在键lock不存在的情况下，将键key的值设置为value1

 (integer) 1

 127.0.0.1:6379> setnx lock value2 #试图覆盖lock的值，返回0表示失败

 (integer) 0

 127.0.0.1:6379> get lock #获取lock的值，验证没有被覆盖

 "value1"

 127.0.0.1:6379> del lock #删除lock的值，删除成功

 (integer) 1

 127.0.0.1:6379> setnx lock value2 #再使用setnx命令设置，返回0表示成功

 (integer) 1

 127.0.0.1:6379> get lock #获取lock的值，验证设置成功

 "value2"

上面这几个命令就是最基本的用来完成分布式锁的命令。

加锁：使用setnx key value命令，如果key不存在，设置value(加锁成功)。如果已经存在lock(也就是有客户端持有锁了)，则设置失败(加锁失败)。

解锁：使用del命令，通过删除键值释放锁。释放锁之后，其他客户端可以通过setnx命令进行加锁。

21、Redis实现分布式锁如何防止死锁现象？(高频)

产生死锁的原因：如果一个客户端持有锁的期间突然崩溃了，就会导致无法解锁，最后导致出现死锁的现象。

所以要有个超时的机制，在设置key的值时，需要加上有效时间，如果有效时间过期了，就会自动失效，就不会出现死锁。然后加锁的代码就会变成这样。

22、Redis实现分布式锁如何合理的控制锁的有效时长？(高频)

有效时间设置多长，假如我的业务操作比有效时间长？我的业务代码还没执行完就自动给我解锁了，不就完蛋了吗。

解决方案：

1、第一种：程序员自己去把握，预估一下业务代码需要执行的时间，然后设置有效期时间比执行时间长一些，保证不会因为自动解锁影响到客户端业务代码的执行。

2、第二种：给锁续期。

锁续期实现思路：当加锁成功后，同时开启守护线程，默认有效期是用户所设置的，然后每隔10秒就会给锁续期到用户所设置的有效期，只要持有锁的客户端没有宕机，就能保证一直持有锁，直到业务代码执行完毕由客户端自己解锁，如果宕机了自然就在有效期失效后自动解锁。

上述的第二种解决方案可以使用redis官方所提供的Redisson进行实现。

Redisson是Redis官方推荐的Java版的Redis客户端。它提供的功能非常多，也非常强大分布式服务，使用Redisson可以轻松的实现分布式锁。Redisson中进行锁续期的这种机制被称为"看门狗"机制。

redission支持4种连接redis方式，分别为单机、主从、Sentinel、Cluster 集群。

23、Redis实现分布式锁如何保证锁服务的高可用？(高频)

解决方案：

1、使用Redis的哨兵模式构建一个主从架构的Redis集群

2、使用Redis Cluster集群

24、当同步锁数据到从节点之前，主节点宕机了导致锁失效，那么此时其他线程就可以再次获取到锁，这个问题怎么解决？(高频)

使用Redission框架中的RedLock进行处理。

RedLock的方案基于2个前提：

1、不再需要部署从库和哨兵实例，只部署主库

2、但主库要部署多个，官方推荐至少5个实例

也就是说，想使用RedLock，你至少要部署5个Redis实例，而且都是主库，它们之间没有任何关系，都是一个个孤立的实例。

工作流程如下所示：

1、客户端先获取【当前时间戳T1】

2、客户端依次向这个5个Redis实例发起加锁请求，且每个请求会设置超时时间(毫秒级，要远小于锁的有效时间)，如果某一个实例加锁失败(包括网络超时，锁被其他的人持有等各种异常情况)，就立即向下一个Redis实例申请加锁

3、如果客户端从 >=3 个(大多数)以上Redis实例加锁成功，则再次获取【当前时间戳T2】, 如果 T2 - T1 < 锁的过期时间，此时，认为客户端加锁成功，否则加锁失败

4、加锁成功，去操作共享资源

5、加锁失败，向【全部节点】发起释放锁请求

总结4个重点：

1、客户端在多个Redis实例上申请加锁

2、必须保证大多数节点加锁成功

3、大多数节点加锁的总耗时，要小于锁设置的过期时间

4、锁释放，要向全部节点发起释放锁请求

24.1 为什么要在多个实例上加锁？

本质上是为了【容错】, 部分实例异常宕机，剩余的实例加锁成功，整个锁服务依旧可用。

24.2 为什么步骤3加锁成功后，还要计算加锁的累计耗时？

因为操作的是多个节点，所以耗时肯定会比操作单个实例耗时更久，而且，因为是网络请求，网络情况是复杂的，有可能存在延迟、丢包、超时等情况发生，网络请求越多，异常发生的概率就越大。所以，即使大多数节点加锁成功，如果加锁的累计耗时已经超过了锁的过期时间，那此时有些实例上的锁可能已经失效了，这个锁就没有意义了。

代码大致如下所示：

Config config1 = new Config();

 config1.useSingleServer().setAddress("redis://192.168.0.1:5378").setPassword("a123456").setDatabase(0);

 RedissonClient redissonClient1 = Redisson.create(config1);

 ​

 Config config2 = new Config();

 config2.useSingleServer().setAddress("redis://192.168.0.1:5379").setPassword("a123456").setDatabase(0);

 RedissonClient redissonClient2 = Redisson.create(config2);

 ​

 Config config3 = new Config();

 config3.useSingleServer().setAddress("redis://192.168.0.1:5380").setPassword("a123456").setDatabase(0);

 RedissonClient redissonClient3 = Redisson.create(config3);

 ​

 String resourceName = "REDLOCK_KEY";

 ​

 RLock lock1 = redissonClient1.getLock(resourceName);

 RLock lock2 = redissonClient2.getLock(resourceName);

 RLock lock3 = redissonClient3.getLock(resourceName);

 ​

 // 向3个redis实例尝试加锁

 RedissonRedLock redLock = new RedissonRedLock(lock1, lock2, lock3);

 boolean isLock;

 try {

     // isLock = redLock.tryLock();

     // 500ms拿不到锁, 就认为获取锁失败。10000ms即10s是锁失效时间。

     isLock = redLock.tryLock(500, 10000, TimeUnit.MILLISECONDS);

     System.out.println("isLock = "+isLock);

     if (isLock) {

         //TODO if get lock success, do something;

    }

     

 } catch (Exception e) {

 } finally {

     // 无论如何, 最后都要解锁

     redLock.unlock();

 }