标签:占用 .com 进入 有一个 链表 快速 状态 信号 ref
面:缓存中间件——Memcached和Redis的区别是什么?
答:Memcached的优点是简单易用,代码层次类似与Hash。支持简单数据类型,但不支持数据持久化存储,也不支持主从同步,也不支持分片。Redis的数据类型丰富,支持数据磁盘持久化存储,支持主从,支持分片。
面:为什么Redis能这么快?(100000+QPS)
面:说说你用过的Redis的数据类型?
Redis底层数据类型基础:
面:如何从海量Key里查询出某一固定前缀的Key?
答:若使用KEYS pattern:查找出所有符合给定模式patter的key,会对使线上的业务造成卡顿(主要是一次性返回所有的满足条件的key),此时可以使用SCAN指令(SCAN cursor [MATCH pattern] [COUNT count])无阻塞的返回一定数量的key(它是基于游标的迭代器,需要基于上一次的游标延续之前的迭代过程;以0作为游标开始一次新的迭代,直到命令返回游标0完成一次遍历;不保证每次执行都返回某个给定数量的元素,支持模糊查询。)
面:如何通过Redis实现简单的分布式锁?
分布式锁需要解决的问题:互斥性(任意时刻只能有一个客户端获取锁),安全性(锁只能由持有该锁的客户端释放),死锁(持有锁的客户端宕机后,无法释放锁,导致其他客户端无法获取到该锁导致的死锁),容错(当某些客户端宕机后,其他客户端也要能获取锁和释放锁)
答:缺陷方案:首先可以通过Redis命令SETNX key value
(原子性的,如果可以不存在,则创建并赋值,时间复杂度O(1),设置成功返回1,失败返回0),若能设置成功则说明此时没有别的线程进入了临界区。若失败,则表明该资源已经被其他线程所占用了,所以需要一直等待,直到SETNX返回1即其他线程设置的key过期了(EXPIRE key seconds)。但是上述方案有个缺点:即SETNX 和 EXPIRE的复合操作不是原子性的,若某个线程执行完SETNX突然挂掉了,那么由于没有执行EXPIRE操作,那么独占资源就一直不能被其他线程所占用。
优秀方案:上述方案之所以有缺陷,是因为原子性没有得到满足,所以可以通过以下命令SET key value [EX secods] [PX milliseconds] [NX|XX]
(这条命令就是同时满足SETNX和EXPIRE,SET操作成功时返回OK,否则返回nil)此条命令是原子操作。
面:如果有大量的Key同时过期,那么需要注意什么?
集中过期,由于清除大量的key会耗时,会出现短暂的卡顿现象。解决方案是在设置key的过期时间时,给每个key加上随机值,使得过期时间分散些。
面:如何使用Redis做异步队列?
答:使用List作为队列,RPUSH生产消息,LPOP消费消息。但是LPOP不会等待队列有值才消费它会一直尝试消费,可以同过引入Sleep机制调用LPOP重试。也可通过命令BLPOP key [key...] timeout
(阻塞直到队列有消息或者超时)。缺点是:只能供一个消费者消费。如果要让多个消费者消费,就可以使用Redis里的pub/sub(主题订阅者模式),但是消息的发布是无状态的,无法保证可达(要解决这个问题,就需要使用专业的队列Kafka)。
面:Redis如何做持久化?
面:如何解决AOF文件大小不断增大的问题?
答:可以采取日志重写的方式,原理如下:
面:当RDB和AOF文件共存的情况下,如何恢复Redis的数据?
面:谈谈RDB和AOF的优缺点?
RDB-AOF混合持久化方式:BGSAVE做镜像全量持久化,AOF做增量持久化。
面:如何从海量数据里快速找到所需要的数据?
答:使用分片:按照某种规则去划分数据,使数据分散存储在多个节点上。并且Redis为了能够提高key的命中率,采用的是一致性hash算法(一致性hash算法:对2^32取模将hash值空间组织成虚拟的圆环,将数据key使用相同的hash函数计算出hash值,引入虚拟节点解决数据倾斜)。
标签:占用 .com 进入 有一个 链表 快速 状态 信号 ref
原文地址:https://www.cnblogs.com/yunche/p/10546628.html