此为转载文章,仅作记录使用,方便往后查看,原文连接:http://www.bieryun.com/3405.htmlhtml
答:Redis全称为:Remote Dictionary Server(远程数据服务),是一个基于内存的高性能key-value数据库。web
答:Redis支持五种数据类型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。面试
咱们实际项目中比较经常使用的是string,hash若是你是Redis中高级用户,还须要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。redis
若是你说还玩过Redis Module,像BloomFilter,RedisSearch,Redis-ML,面试官得眼睛就开始发亮了。算法
(1) 速度快,由于数据存在内存中,相似于HashMap,HashMap的优点就是查找和操做的时间复杂度都是O(1)数据库
(2) 支持丰富数据类型,支持string,list,set,Zset,hash等后端
(3) 支持事务,操做都是原子性,所谓的原子性就是对数据的更改要么所有执行,要么所有不执行缓存
(4) 丰富的特性:可用于缓存,消息,按key设置过时时间,过时后将会自动删除安全
(1) Memcached全部的值均是简单的字符串,redis做为其替代者,支持更为丰富的数据类型服务器
(2) Redis的速度比Memcached快不少
(3) Redis能够持久化其数据
(1)、存储方式 Memecache把数据所有存在内存之中,断电后会挂掉,数据不能超过内存大小。 Redis有部份存在硬盘上,这样能保证数据的持久性。
(2)、数据支持类型 Memcache对数据类型支持相对简单。 Redis有复杂的数据类型。
(3)、使用底层模型不一样 它们之间底层实现方式 以及与客户端之间通讯的应用协议不同。 Redis直接本身构建了VM 机制 ,由于通常的系统调用系统函数的话,会浪费必定的时间去移动和请求。
答:Redis是单进程单线程的,redis利用队列技术将并发访问变为串行访问,消除了传统数据库串行控制的开销。
答:512M
Redis提供两种持久化机制RDB和AOF机制:
1)RDB(Redis DataBase)持久化方式: 是指用数据集快照的方式(半持久化模式)记录redis数据库的全部键值对,在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。
优势:
1.只有一个文件dump.rdb,方便持久化。
2.容灾性好,一个文件能够保存到安全的磁盘。
3.性能最大化,fork子进程来完成写操做,让主进程继续处理命令,因此是IO最大化。(使用单独子进程来进行持久化,主进程不会进行任何IO操做,保证了redis的高性能) 4.相对于数据集大时,比AOF的启动效率更高。
缺点:
1.数据安全性低。(RDB是间隔一段时间进行持久化,若是持久化之间redis发生故障,会发生数据丢失。因此这种方式更适合数据要求不严谨的时候)
2)AOF(Append-only file)持久化方式: 是指全部的命令行记录以redis命令请求协议的格式(彻底持久化存储)保存为aof文件。
优势:
1.数据安全,aof持久化能够配置appendfsync属性,有always,每进行一次命令操做就记录到aof文件中一次。
2.经过append模式写文件,即便中途服务器宕机,能够经过redis-check-aof工具解决数据一致性问题。
3.AOF机制的rewrite模式。(AOF文件没被rewrite以前(文件过大时会对命令进行合并重写),能够删除其中的某些命令(好比误操做的flushall))
缺点:
1.AOF文件比RDB文件大,且恢复速度慢。
2.数据集大的时候,比rdb启动效率低。
(1) Master最好不要写内存快照,若是Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工做,当快照比较大时对性能影响是很是大的,会间断性暂停服务。
(2) 若是数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次
(3) 为了主从复制的速度和链接的稳定性,Master和Slave最好在同一个局域网内
(4) 尽可能避免在压力很大的主库上增长从库
(5) 主从复制不要用图状结构,用单向链表结构更为稳定,即:Master <- Slave1 <- Slave2 <- Slave3…这样的结构方便解决单点故障问题,实现Slave对Master的替换。若是Master挂了,能够马上启用Slave1作Master,其余不变。
(1)、定时删除:在设置键的过时时间的同时,建立一个定时器(timer). 让定时器在键的过时时间来临时,当即执行对键的删除操做。
(2)、惰性删除:听任键过时无论,可是每次从键空间中获取键时,都检查取得的键是否过时,若是过时的话,就删除该键;若是没有过时,就返回该键。
(3)、按期删除:每隔一段时间程序就对数据库进行一次检查,删除里面的过时键。至于要删除多少过时键,以及要检查多少个数据库,则由算法决定。
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(驱逐):禁止驱逐数据
注意这里的6种机制,volatile和allkeys规定了是对已设置过时时间的数据集淘汰数据仍是从所有数据集淘汰数据,后面的lru、ttl以及random是三种不一样的淘汰策略,再加上一种no-enviction永不回收的策略。
使用策略规则:
一、若是数据呈现幂律分布,也就是一部分数据访问频率高,一部分数据访问频率低,则使用allkeys-lru
二、若是数据呈现平等分布,也就是全部的数据访问频率都相同,则使用allkeys-random
答:Redis为了达到最快的读写速度将数据都读到内存中,并经过异步的方式将数据写入磁盘。因此redis具备快速和数据持久化的特征。若是不将数据放在内存中,磁盘I/O速度为严重影响redis的性能。在内存愈来愈便宜的今天,redis将会愈来愈受欢迎。若是设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值。
答:Redis可使用主从同步,从从同步。第一次同步时,主节点作一次bgsave,并同时将后续修改操做记录到内存buffer,待完成后将rdb文件全量同步到复制节点,复制节点接受完成后将rdb镜像加载到内存。加载完成后,再通知主节点将期间修改的操做记录同步到复制节点进行重放就完成了同步过程。
答:能够将屡次IO往返的时间缩减为一次,前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候能够发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。
(1)、Redis Sentinal着眼于高可用,在master宕机时会自动将slave提高为master,继续提供服务。
(2)、Redis Cluster着眼于扩展性,在单个redis内存不足时,使用Cluster进行分片存储。
答:有A,B,C三个节点的集群,在没有复制模型的状况下,若是节点B失败了,那么整个集群就会觉得缺乏5501-11000这个范围的槽而不可用。
答:Redisson、Jedis、lettuce等等,官方推荐使用Redisson。
答:Jedis是Redis的Java实现的客户端,其API提供了比较全面的Redis命令的支持;Redisson实现了分布式和可扩展的Java数据结构,和Jedis相比,功能较为简单,不支持字符串操做,不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离,从而让使用者可以将精力更集中地放在处理业务逻辑上。
设置密码:config set requirepass 123456
受权密码:auth 123456
答:Redis集群没有使用一致性hash,而是引入了哈希槽的概念,Redis集群有16384个哈希槽,每一个key经过CRC16校验后对16384取模来决定放置哪一个槽,集群的每一个节点负责一部分hash槽。
答:为了使在部分节点失败或者大部分节点没法通讯的状况下集群仍然可用,因此集群使用了主从复制模型,每一个节点都会有N-1个复制品.
答:Redis并不能保证数据的强一致性,这意味这在实际中集群在特定的条件下可能会丢失写操做。
答:异步复制
答:16384个。
答:Redis集群目前没法作数据库选择,默认在0数据库。
答:使用ping命令。
答:
1)事务是一个单独的隔离操做:事务中的全部命令都会序列化、按顺序地执行。事务在执行的过程当中,不会被其余客户端发送来的命令请求所打断。
2)事务是一个原子操做:事务中的命令要么所有被执行,要么所有都不执行。
答:MULTI、EXEC、DISCARD、WATCH
答:EXPIRE和PERSIST命令。
答:尽量使用散列表(hashes),散列表(是说散列表里面存储的数少)使用的内存很是小,因此你应该尽量的将你的数据模型抽象到一个散列表里面。好比你的web系统中有一个用户对象,不要为这个用户的名称,姓氏,邮箱,密码设置单独的key,而是应该把这个用户的全部信息存储到一张散列表里面.
答:一个客户端运行了新的命令,添加了新的数据。Redi检查内存使用状况,若是大于maxmemory的限制, 则根据设定好的策略进行回收。一个新的命令被执行,等等。因此咱们不断地穿越内存限制的边界,经过不断达到边界而后不断地回收回到边界如下。若是一个命令的结果致使大量内存被使用(例如很大的集合的交集保存到一个新的键),不用多久内存限制就会被这个内存使用量超越。
答:若是你使用的是32位的Redis实例,能够好好利用Hash,list,sorted set,set等集合类型数据,由于一般状况下不少小的Key-Value能够用更紧凑的方式存放到一块儿。
答:若是达到设置的上限,Redis的写命令会返回错误信息(可是读命令还能够正常返回。)或者你能够将Redis当缓存来使用配置淘汰机制,当Redis达到内存上限时会冲刷掉旧的内容。
答:理论上Redis能够处理多达232的keys,而且在实际中进行了测试,每一个实例至少存放了2亿5千万的keys。咱们正在测试一些较大的值。任何list、set、和sorted set均可以放232个元素。换句话说,Redis的存储极限是系统中的可用内存值。
答:Redis内存数据集大小上升到必定大小的时候,就会施行数据淘汰策略。
相关知识:Redis提供6种数据淘汰策略:
voltile-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(驱逐):禁止驱逐数据
(1)、会话缓存(Session Cache)
最经常使用的一种使用Redis的情景是会话缓存(session cache)。用Redis缓存会话比其余存储(如Memcached)的优点在于:Redis提供持久化。当维护一个不是严格要求一致性的缓存时,若是用户的购物车信息所有丢失,大部分人都会不高兴的,如今,他们还会这样吗? 幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
(2)、全页缓存(FPC)
除基本的会话token以外,Redis还提供很简便的FPC平台。回到一致性问题,即便重启了Redis实例,由于有磁盘的持久化,用户也不会看到页面加载速度的降低,这是一个极大改进,相似PHP本地FPC。 再次以Magento为例,Magento提供一个插件来使用Redis做为全页缓存后端。 此外,对WordPress的用户来讲,Pantheon有一个很是好的插件 wp-redis,这个插件能帮助你以最快速度加载你曾浏览过的页面。
(3)、队列
Reids在内存存储引擎领域的一大优势是提供 list 和 set 操做,这使得Redis能做为一个很好的消息队列平台来使用。Redis做为队列使用的操做,就相似于本地程序语言(如Python)对 list 的 push/pop 操做。 若是你快速的在Google中搜索“Redis queues”,你立刻就能找到大量的开源项目,这些项目的目的就是利用Redis建立很是好的后端工具,以知足各类队列需求。例如,Celery有一个后台就是使用Redis做为broker,你能够从这里去查看。
(4),排行榜/计数器
Redis在内存中对数字进行递增或递减的操做实现的很是好。集合(Set)和有序集合(Sorted Set)也使得咱们在执行这些操做的时候变的很是简单,Redis只是正好提供了这两种数据结构。因此,咱们要从排序集合中获取到排名最靠前的10个用户–咱们称之为“user_scores”,咱们只须要像下面同样执行便可: 固然,这是假定你是根据你用户的分数作递增的排序。若是你想返回用户及用户的分数,你须要这样执行: ZRANGE user_scores 0 10 WITHSCORES Agora Games就是一个很好的例子,用Ruby实现的,它的排行榜就是使用Redis来存储数据的,你能够在这里看到。
(5)、发布/订阅
最后(但确定不是最不重要的)是Redis的发布/订阅功能。发布/订阅的使用场景确实很是多。我已看见人们在社交网络链接中使用,还可做为基于发布/订阅的脚本触发器,甚至用Redis的发布/订阅功能来创建聊天系统!
答:使用keys指令能够扫出指定模式的key列表。
对方接着追问:若是这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题?
这个时候你要回答redis关键的一个特性:redis的单线程的。keys指令会致使线程阻塞一段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可使用scan指令,scan指令能够无阻塞的提取出指定模式的key列表,可是会有必定的重复几率,在客户端作一次去重就能够了,可是总体所花费的时间会比直接用keys指令长。
答:若是大量的key过时时间设置的过于集中,到过时的那个时间点,redis可能会出现短暂的卡顿现象。通常须要在时间上加一个随机值,使得过时时间分散一些。
答:通常使用list结构做为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleep一会再重试。
若是对方追问可不能够不用sleep呢?
list还有个指令叫blpop,在没有消息的时候,它会阻塞住直到消息到来。若是对方追问能不能生产一次消费屡次呢?使用pub/sub主题订阅者模式,能够实现1:N的消息队列。
若是对方追问pub/sub有什么缺点?
在消费者下线的状况下,生产的消息会丢失,得使用专业的消息队列如RabbitMQ等。
若是对方追问redis如何实现延时队列?
我估计如今你很想把面试官一棒打死若是你手上有一根棒球棍的话,怎么问的这么详细。可是你很克制,而后神态自若的回答道:使用sortedset,拿时间戳做为score,消息内容做为key调用zadd来生产消息,消费者用zrangebyscore指令获取N秒以前的数据轮询进行处理。到这里,面试官暗地里已经对你竖起了大拇指。可是他不知道的是此刻你却竖起了中指,在椅子背后。
先拿setnx来争抢锁,抢到以后,再用expire给锁加一个过时时间防止锁忘记了释放。
这时候对方会告诉你说你回答得不错,而后接着问若是在setnx以后执行expire以前进程意外crash或者要重启维护了,那会怎么样?
这时候你要给予惊讶的反馈:唉,是喔,这个锁就永远得不到释放了。紧接着你须要抓一抓本身得脑壳,故做思考片刻,好像接下来的结果是你主动思考出来的,而后回答:我记得set指令有很是复杂的参数,这个应该是能够同时把setnx和expire合成一条指令来用的!对方这时会显露笑容,内心开始默念:摁,这小子还不错。