Redis常见面试题总结

最新推荐文章于 2024-08-06 21:10:18 发布

黄山路443号

最新推荐文章于 2024-08-06 21:10:18 发布

阅读量586

点赞数

分类专栏： Redis 文章标签：分布式数据库 redis 多线程面试

本文链接：https://blog.csdn.net/dong_W_/article/details/105197794

版权

Redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

一些问题的总结

Memcache与Redis的区别都有哪些？

redis的过期策略以及内存淘汰机制

同时有多个子系统去set一个key。这个时候要注意什么呢？

如何保证缓存与数据库双写时的数据一致性?

redis遇到高并发，如果保证读写key的一致性。

为什么Redis的操作是原子性的，怎么保证原子性的？

Redis 常见性能问题和解决方案？

Redis实现分布式锁

Memcache与Redis的区别都有哪些？

存储方式 Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。 Redis有部份存在硬盘上，redis可以持久化其数据
数据支持类型 memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富的数据类型，提供list，set，zset，hash等数据结构的存储
使用底层模型不同它们之间底层实现方式以及与客户端之间通信的应用协议不一样。 Redis直接自己构建了VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
value 值大小不同：Redis 最大可以达到 512M；memcache 只有 1mb。
redis的速度比memcached快很多
Redis支持数据的备份，即master-slave模式的数据备份。

redis的过期策略以及内存淘汰机制

redis采用的是定期删除+惰性删除策略。

为什么不用定时删除策略?

定时删除，用一个定时器来负责监视key,过期则自动删除。虽然内存及时释放，但是十分消耗CPU资源。在大并发请求下，CPU要将时间应用在处理请求，而不是删除key，因此没有采用这一策略.

定期删除+惰性删除是如何工作的呢?

定期删除，redis默认每个100ms检查，是否有过期的key，有过期key则删除。需要说明的是，redis不是每个100ms将所有的key检查一次，而是随机抽取进行检查(如果每隔100ms,全部key进行检查，redis岂不是卡死)。因此，如果只采用定期删除策略，会导致很多key到时间没有删除。于是，惰性删除派上用场。也就是说在你获取某个key的时候，redis会检查一下，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除。

采用定期删除+惰性删除就没其他问题了么?

不是的，如果定期删除没删除key。然后你也没即时去请求key，也就是说惰性删除也没生效。这样，redis的内存会越来越高。那么就应该采用内存淘汰机制。

在redis.conf中有一行配置：maxmemory-policy volatile-lru 该配置就是配内存淘汰策略的 volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰 volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰 volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰 allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰 allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰 no-enviction（驱逐）：禁止驱逐数据，新写入操作会报错 ps：如果没有设置 expire 的key，不满足先决条件(prerequisites)；那么 volatile-lru, volatile-random 和 volatile-ttl 策略的行为, 和 noeviction(不删除) 基本上一致。

同时有多个子系统去set一个key。这个时候要注意什么呢？

不推荐使用redis的事务机制。因为我们的生产环境，基本都是redis集群环境，做了数据分片操作。你一个事务中有涉及到多个key操作的时候，这多个key不一定都存储在同一个redis-server上。因此，redis的事务机制，十分鸡肋。 (1) 如果对这个key操作，不要求顺序：准备一个分布式锁，大家去抢锁，抢到锁就做set操作即可 (2) 如果对这个key操作，要求顺序：分布式锁+时间戳。假设这会系统B先抢到锁，将key1设置为{valueB 3:05}。接下来系统A抢到锁，发现自己的valueA的时间戳早于缓存中的时间戳，那就不做set操作了。以此类推。 (3) 利用队列，将set方法变成串行访问也可以。

如何保证缓存与数据库双写时的数据一致性?

你只要用缓存，就可能会涉及到缓存与数据库双存储双写，你只要是双写，就一定会有数据一致性的问题，那么你如何解决一致性问题？

问题1：先更新数据库，再删除缓存。如果删除缓存失败了，那么会导致数据库中是新数据，缓存中是旧数据，数据就出现了不一致。

解决思路：先删除缓存，再更新数据库。如果数据库更新失败了，那么数据库中是旧数据，缓存中是空的，那么数据不会不一致。因为读的时候缓存没有，所以去读了数据库中的旧数据，然后更新到缓存中。

问题2：数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改。完了，数据库和缓存中的数据不一样了...

解决思路(1)：写请求先删除缓存，再去更新数据库，（异步等待段时间)再删除缓存（成功表示有脏数据出现）。

这种方案读取快速，但会出现短时间的脏数据。

解决思路(2)：写请求先修改缓存为指定值，再去更新数据库，再更新缓存。读请求过来后，先读缓存，判断是指定值后进入循环状态，等待写请求更新缓存。如果循环超时就去数据库读取数据，更新缓存。

这种方案保证了读写的一致性，但是读请求会等待写操作的完成，降低了吞吐量

看这篇文章

redis遇到高并发，如果保证读写key的一致性。

对redis的操作都是具有原子性的，是线程安全的操作，你不用考虑并发问题，redis内部已经帮你处理好并发的问题了。

redis是一个单线程程序，也就说同一时刻它只能处理一个客户端请求。redis是通过IO多路复用（select，epoll, kqueue，依据不同的平台，采取不同的实现）来处理多个客户端请求的

为什么Redis的操作是原子性的，怎么保证原子性的？

对于Redis而言，命令的原子性指的是：一个操作的不可以再分，操作要么执行，要么不执行。 Redis的操作之所以是原子性的，是因为Redis是单线程的。 Redis本身提供的所有API都是原子操作，Redis中的事务其实是要保证批量操作的原子性。 多个命令在并发中也是原子性的吗？ 不一定，将get和set改成单命令操作，incr 。使用Redis的事务，或者使用Redis+Lua==的方式实现.