面试 - Redis

原创
2020/02/24 16:39
阅读数 330

Redis有哪些数据结构?
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。

使用过Redis分布式锁么,它是什么回事?
先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放。set指令有非常复杂的参数,这个应该是可以同时把setnx和expire合成一条指令来用的。

假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如果将它们全部找出来?
使用keys指令可以扫出指定模式的key列表。redis的单线程的。keys指令会导致线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。

Redis如何做持久化的?
bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会耗费较长时间,不够实时,在停机的时候会导致大量丢失数据,所以需要aof来配合使用。在redis实例重启时,会使用bgsave持久化文件重新构建内存,再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

bgsave的原理是什么?
fork和cow。fork是指redis通过创建子进程来进行bgsave操作,cow指的是copyonwrite,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。

是否使用过Redis集群,集群的原理是什么?
RedisSentinal着眼于高可用,在master宕机时会自动将slave提升为master,继续提供服务。
RedisCluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。

Redis的同步机制?
Redis可以使用主从同步,从从同步。第一次同步时,主节点做一次bgsave,并同时将后续修改操作记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存。加载完成后,再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

Redis为什么这么快?
Redis 完全基于内存,绝大部分请求是纯粹的内存操作,非常迅速,数据存在内存中,类似于 HashMap,HashMap 的优势就是查找和操作的时间复杂度是 O(1)。
数据结构简单,对数据操作也简单。
采用单线程,避免了不必要的上下文切换和竞争条件,不存在多线程导致的 CPU 切换,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有死锁问题导致的性能消耗。
使用多路复用 IO 模型,非阻塞 IO。

Redis 和 Memcached 的区别?
存储方式上:Memcache 会把数据全部存在内存之中,断电后会挂掉,数据不能超过内存大小。Redis 有部分数据存在硬盘上,这样能保证数据的持久性。
数据支持类型上:Memcache 对数据类型的支持简单,只支持简单的 key-value,,而 Redis 支持五种数据类型。
使用底层模型不同:它们之间底层实现方式以及与客户端之间通信的应用协议不一样。Redis 直接自己构建了 VM 机制,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求。
Value 的大小:Redis 可以达到 1GB,而 Memcache 只有 1MB。

Redis的持久化策略?
RDB:快照形式是直接把内存中的数据保存到一个 dump 的文件中,定时保存,保存策略。
AOF:把所有的对 Redis 的服务器进行修改的命令都存到一个文件里,命令的集合。Redis 默认是快照 RDB 的持久化方式。

Redis的淘汰策略?
noeviction:不删除策略,达到最大内存限制时,如果需要更多内存,直接返回错误信息。
allkeys-lru:所有key通用;优先删除最近最少使用(less recently used ,LRU) 的 key。
volatile-lru:只限于设置了 expire 的部分;优先删除最近最少使用(less recently used ,LRU) 的 key。
allkeys-random:所有key通用;随机删除一部分 key。
volatile-random:只限于设置了 expire 的部分;随机删除一部分 key。
volatile-ttl:只限于设置了 expire 的部分;优先删除剩余时间(time to live,TTL) 短的key。

Redis的主从复制?
Redis 单节点存在单点故障问题,为了解决单点问题,一般都需要对 Redis 配置从节点,然后使用哨兵来监听主节点的存活状态,如果主节点挂掉,从节点能继续提供缓存功能。

关于复制过程:
从节点执行 slaveof[masterIP][masterPort],保存主节点信息。
从节点中的定时任务发现主节点信息,建立和主节点的 Socket 连接。
从节点发送 Ping 信号,主节点返回 Pong,两边能互相通信。
连接建立后,主节点将所有数据发送给从节点(数据同步)。
主节点把当前的数据同步给从节点后,便完成了复制的建立过程。
接下来,主节点就会持续的把写命令发送给从节点,保证主从数据一致性。

存在问题:
一旦主节点宕机,从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令所有从节点去复制新的主节点,整个过程需要人工干预。
主节点的写能力受到单机的限制。
主节点的存储能力受到单机的限制。
原生复制的弊端在早期的版本中也会比较突出,比如:Redis 复制中断后,从节点会发起 psync。
此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时,可能会造成毫秒或秒级的卡顿。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部