大厂 Redis 面试题—Redis 常见面试题（带答案）

全部面试题答案，更新日期：12月30日，直接下载吧！

下载链接：高清500+份面试题资料及电子书，累计 10000+ 页大厂面试题 PDF

Redis

题1：Redis 中分布式锁有什么缺陷性问题？

Redis分布式锁不能解决超时的问题，分布式锁有一个超时时间，程序的执行如果超出了锁的超时时间就会出现问题。

题2：Redis 中如何实现分布式锁？

分布式锁常见的三种实现方式：

1）数据库乐观锁；

2）基于Redis的分布式锁；

3）基于ZooKeeper的分布式锁。

Redis要实现分布式锁，以下条件应该得到满足：

1）互斥性

在任意时刻，只有一个客户端能持有锁。

2）不能死锁

客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

3）容错性

只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。

一、实现

可以通过set key value px milliseconds nx命令实现加锁， 通过Lua脚本实现解锁。

//获取锁（unique_value可以是UUID等）
SET resource_name unique_value NX PX  30000
 
//释放锁（lua脚本中，一定要比较value，防止误解锁）
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

代码解释

set命令要用set key value px milliseconds nx，替代setnx + expire需要分两次执行命令的方式，保证了原子性；

value要具有唯一性，可以使用UUID.randomUUID().toString()方法生成，用来标识这把锁是属于哪个请求加的，在解锁的时候就可以有依据；

释放锁时要验证 value 值，防止误解锁；

通过 Lua 脚本来避免 Check And Set 模型的并发问题，因为在释放锁的时候因为涉及到多个Redis操作 （利用了eval命令执行Lua脚本的原子性）；

加锁代码分析

首先，set()加入了NX参数，可以保证如果已有key存在，则函数不会调用成功，也就是只有一个客户端能持有锁，满足互斥性。其次，由于我们对锁设置了过期时间，即使锁的持有者后续发生崩溃而没有解锁，锁也会因为到了过期时间而自动解锁（即key被删除），不会发生死锁。最后，因为我们将value赋值为requestId，用来标识这把锁是属于哪个请求加的，那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。

解锁代码分析

将Lua代码传到jedis.eval()方法里，并使参数KEYS[1]赋值为lockKey，ARGV[1]赋值为requestId。在执行的时候，首先会获取锁对应的value值，检查是否与requestId相等，如果相等则解锁（删除key）。

存在的风险

如果存储锁对应key的那个节点挂了的话，就可能存在丢失锁的风险，导致出现多个客户端持有锁的情况，这样就不能实现资源的独享了。

1）客户端A从master获取到锁

2）在master将锁同步到slave之前，master宕掉了（Redis的主从同步通常是异步的）。主从切换，slave节点被晋级为master节点

3）客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。导致存在同一时刻存不止一个线程获取到锁的情况。

二、redlock算法出现

这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：

1）获取当前时间戳，单位是毫秒；

2）跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；

3）尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n / 2 + 1；

4）客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；

5）要是锁建立失败了，那么就依次之前建立过的锁删除；

6）只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。

Redis 官方给出了以上两种基于 Redis 实现分布式锁的方法，详细说明可以查看：

https://redis.io/topics/distlock

三、Redisson实现

Redisson是一个在Redis的基础上实现的Java驻内存数据网格（In-Memory Data Grid）。它不仅提供了一系列的分布式的Java常用对象，还实现了可重入锁（Reentrant Lock）、公平锁（Fair Lock、联锁（MultiLock）、 红锁（RedLock）、 读写锁（ReadWriteLock）等，还提供了许多分布式服务。

Redisson提供了使用Redis的最简单和最便捷的方法。Redisson的宗旨是促进使用者对Redis的关注分离（Separation of Concern），从而让使用者能够将精力更集中地放在处理业务逻辑上。

Redisson 分布式重入锁用法

Redisson 支持单点模式、主从模式、哨兵模式、集群模式，这里以单点模式为例：

// 1.构造redisson实现分布式锁必要的Config
Config config = new Config();
config.useSingleServer().setAddress("redis://127.0.0.1:5379").setPassword("123456").setDatabase(0);
// 2.构造RedissonClient
RedissonClient redissonClient = Redisson.create(config);
// 3.获取锁对象实例（无法保证是按线程的顺序获取到）
RLock rLock = redissonClient.getLock(lockKey);
try {
    /**
     * 4.尝试获取锁
     * waitTimeout 尝试获取锁的最大等待时间，超过这个值，则认为获取锁失败
     * leaseTime   锁的持有时间,超过这个时间锁会自动失效（值应设置为大于业务处理的时间，确保在锁有效期内业务能处理完）
     */
    boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
    if (res) {
        //成功获得锁，在这里处理业务
    }
} catch (Exception e) {
    throw new RuntimeException("aquire lock fail");
}finally{
    //无论如何, 最后都要解锁
    rLock.unlock();
}

加锁流程图

解锁流程图

可以看到RedissonLock是可重入的，并且考虑了失败重试，可以设置锁的最大等待时间，在实现上也做了一些优化，减少了无效的锁申请，提升了资源的利用率。

需要特别注意的是，RedissonLock同样没有解决 节点挂掉的时候，存在丢失锁的风险的问题。而现实情况是有一些场景无法容忍的，所以Redisson提供了实现了redlock算法的 RedissonRedLock，RedissonRedLock 真正解决了单点失败的问题，代价是需要额外的为RedissonRedLock搭建Redis环境。

因此，如果业务场景可以容忍这种小概率的错误，则推荐使用RedissonLock，如果无法容忍，则推荐使用RedissonRedLock。

参考资料：

https://github.com/javazhiyin/advanced-java/ https://crazyfzw.github.io/2019/04/15/distributed-locks-with-redis/

题3：为什么 Redis 集群的最大槽数是 16384 个？

在redis节点发送心跳包时需要把所有的槽放到这个心跳包中，以便让节点知道当前集群信息，即16384=16k，在发送心跳包时使用char进行bitmap压缩后是2k（2*8 (8bit)*1024(1k)=16K），也就是说使用2k的空间创建了16k的槽数。

虽然使用CRC16算法最多可以分配65535（2^16-1）个槽位，即65535=65k，压缩后就是8k（8*8 (8 bit)*1024(1k)=65K），也就是说需要8k的心跳包，并且一般情况下一个redis集群不会有超过1000个master节点，所以16k的槽位是个比较合适的选择。

题4：Redis 中如何解决 overcommit_memory is set to 0 告警问题？

告警信息

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

翻译为：警告内存设置为0！在内存不足的情况下，后台保存可能会失败。若要解决此问题，请将“vm.overcommit_memory = 1”添加到/etc/sysctl.conf，然后重新启动或运行命令“sysctl vm.overcommit_memory=1”使其生效。

解决办法

方式一：执行“echo 1 > /proc/sys/vm/overcommit_memory”命令，如果没有权限执行该命令需要切换至root账户，执行su root命令使用root用户。这会使其立即生效，不用重启redis服务，但是如果redis服务重启后还会报错误，需要再次执行上述命令。

方式二：彻底解决Redis中overcommit_memory is set to 0!告警问题，编辑/etc/sysctl.conf文件，添加net.core.somaxconn = 1024然后执行sysctl -p命令查看是否添加成功，之后重启Redis服务即可。

[root@mrwang redis-4.0.9]# vim /etc/sysctl.conf 
[root@mrwang redis-4.0.9]# sysctl -p            
vm.swappiness = 0
kernel.sysrq = 1
net.ipv4.neigh.default.gc_stale_time = 120
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_announce = 2
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_synack_retries = 2
vm.overcommit_memory = 1

题5：Redis 中如何解决 The TCP backlog setting of 511 cannot be enforced 告警问题？

告警信息

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

翻译为：【警告：无法强制执行TCP backlog设置511，因为/proc/sys/net/core/somaxconn设置为较低的值128。】

解决方法

方式一：设置的值128较低，需要“echo 511 > /proc/sys/net/core/somaxconn”命令，注意此命令只是暂时生效，如果重启后就会失效。

方式二：永久解决Redis中The TCP backlog setting of 511 cannot be enforced告警问题，编辑/etc/sysctl.conf文件，添加net.core.somaxconn = 1024然后执行sysctl -p命令查看是否添加成功，之后重启Redis服务即可。

[root@mrwang redis-4.0.9]# vim /etc/sysctl.conf 
[root@mrwang redis-4.0.9]# sysctl -p            
vm.swappiness = 0
kernel.sysrq = 1
net.ipv4.neigh.default.gc_stale_time = 120
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.arp_announce = 2
net.ipv4.conf.lo.arp_announce = 2
net.ipv4.conf.all.arp_announce = 2
net.ipv4.tcp_max_tw_buckets = 5000
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_synack_retries = 2
net.core.somaxconn = 1024

题6：Redis 中如何解决 THP 服务导致的延迟和内存使用问题？

警告日志

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.

翻译：警告您的内核中启用了透明大页面（THP）支持。这将导致Redis的延迟和内存使用问题。要解决此问题，请以root用户身份运行命令“echo never>/sys/kernel/mm/transparent_hugepage/enabled”，并将其添加到/etc/rc.local中，以便在重新启动后保留设置。禁用THP后，必须重新启动Redis。

解决方法

查看服务状态

[root@mrwang logs]# cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never
[root@mrwang logs]# echo never>/sys/kernel/mm/transparent_hugepage/enabled
[root@mrwang logs]# cat /sys/kernel/mm/transparent_hugepage/enabled       
always madvise [never]

编辑rc.local文件，增加代码。

vi /etc/rc.local

添加代码如下：

if test -f /sys/kernel/mm/redhat_transparent_hugepage/enabled; then
   echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
fi

或者

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

题7：Redis 是单线程的，如何提高多核 CPU 的利用率？

可以在同一个服务器部署多个Redis的实例，并把他们当作不同的服务器来使用，在某些时候，无论如何一个服务器是不够的， 所以，如果你想使用多个CPU，你可以考虑一下分片(shard)。

题8：Redis 集群之间是如何复制的？

异步复制。

题9：Redis 集群会产生数据丢失情况吗？

Redis并不能保证数据的强一致性，也就是说在实际中Redis集群在特定的条件下可能会产生数据丢失的情况。

题10：Redis 哈希槽的概念是什么？

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