最近面试的小伙伴不少,对此我整理了一份Java面试题手册:基础知识、JavaOOP、Java集合/泛型面试题、Java异常面试题、Java中的IO与NIO面试题、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、SpringBoot、SpringCloud、RabbitMQ、Dubbo、MyBatis、ZooKeeper、数据结构、算法、Elasticsearch、Kafka、微服务、Linux等等。能够分享给你们学习。【持续更新中】程序员
完整版Java面试题地址:【2021最新版】Java面试真题汇总web
序号 | 内容 | 地址连接 |
---|---|---|
1 | 【2021最新版】JavaOOP面试题总结 | http://www.noobyard.com/article/p-rncfmibs-oe.html |
2 | 【2021最新版】Java基础面试题总结 | http://www.noobyard.com/article/p-ykqnztan-oe.html |
3 | 【2021最新版】多线程&并发面试题总结 | http://www.noobyard.com/article/p-nhidektg-oe.html |
4 | 【2021最新版】JVM面试题总结 | http://www.noobyard.com/article/p-anzurdyn-oe.html |
5 | 【2021最新版】Mysql面试题总结 | http://www.noobyard.com/article/p-vvarpaer-oe.html |
6 | 【2021最新版】Memcached面试题总结 | 未更新 |
7 | 【2021最新版】MongoDB面试题总结 | 未更新 |
8 | 【2021最新版】Spring面试题总结 | 未更新 |
9 | 【2021最新版】Spring Boot面试题总结 | 未更新 |
10 | 【2021最新版】Spring Cloud面试题总结 | 未更新 |
11 | 【2021最新版】RabbitMQ面试题总结 | 未更新 |
12 | 【2021最新版】Dubbo面试题总结 | 未更新 |
13 | 【2021最新版】MyBatis面试题总结 | 未更新 |
14 | 【2021最新版】ZooKeeper面试题总结 | 未更新 |
15 | 【2021最新版】数据结构面试题总结 | 未更新 |
16 | 【2021最新版】算法面试题总结 | 未更新 |
17 | 【2021最新版】Elasticsearch面试题总结 | 未更新 |
18 | 【2021最新版】Kafka面试题总结 | 未更新 |
19 | 【2021最新版】微服务面试题总结 | 未更新 |
20 | 【2021最新版】Linux面试题总结 | 未更新 |
答:面试
Redis是彻底开源免费的,遵照BSD协议,是一个高性能的key-value数据库。redis
Redis与其余key-value缓存产品有如下三个特色:算法
Redis支持数据的持久化,能够将内存中的数据保存在磁盘中,重启的时候能够再次加载进行使用。sql
Redis不只仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。数据库
Redis支持数据的备份,即master-slave模式的数据备份。后端
Redis优点缓存
性能极高–Redis能读的速度是110000次/s,写的速度是81000次/s 。丰富的数据类型–Redis支持二进制案例的Strings, Lists, Hashes,Sets及Ordered Sets数据类型操做。安全
原子–Redis的全部操做都是原子性的,意思就是要么成功执行要么失败彻底不执行。单个操做是原子性的。多个操做也支持事务,即原子性,经过MULTI和EXEC指令包起来。
丰富的特性–Redis还支持publish/subscribe, 通知,key过时等等特性。
答:
Redis有着更为复杂的数据结构而且提供对他们的原子性操做,这是一个不一样于其余数据库的进化路径。
Redis的数据类型都是基于基本数据结构的同时对程序员透明,无需进行额外的抽象。
Redis 运行在内存中可是能够持久化到磁盘,因此在对不一样数据集进行高速读写时须要权衡内存,由于数据量不能大于硬件内存。在内存数据库方面的另外一个优势是,相比在磁盘上相同的复杂的数据结构,在内存中操做起来很是简单,这样Redis能够作不少内部复杂性很强的事情。
同时,在磁盘格式方面他们是紧凑的以追加的方式产生的,由于他们并不须要进行随机访问。
答:
Redis支持五种数据类型: string(字符串)
1.hash(哈希)
2.list(列表)
3.set(集合)
4.及zsetsorted set:(有序集合)。
咱们实际项目中比较经常使用的是string,hash若是你是Redis中高级用户,还须要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。
若是你说还玩过Redis Module,像 BloomFilter,RedisSearch,Redis-ML,面试官得眼睛就开始发亮了。
答:
一、速度快,由于数据存在内存中,相似于HashMap,HashMap的优点就是查找和操做的时间复杂度都是O1)
二、支持丰富数据类型,支持string,list,set,Zset,hash等
三、支持事务,操做都是原子性,所谓的原子性就是对数据的更改要么所有执行,要么所有不执行
四、丰富的特性:可用于缓存,消息,按key设置过时时间,过时后将会自动删除
答:
一、Memcached全部的值均是简单的字符串,redis做为其替代者,支持更为丰富的数据类
二、Redis的速度比Memcached快很
三、Redis能够持久化其数据
答:
一、存储方式Memecache把数据所有存在内存之中,断电后会挂掉,数据不能超过内存大小。 Redis有部份存在硬盘上,这样能保证数据的持久性。
二、数据支持类型Memcache对数据类型支持相对简单。 Redis有复杂的数据类型。
三、使用底层模型不一样 它们之间底层实现方式 以及与客户端之间通讯的应用协议不同。 Redis直接本身构建了VM机制 ,由于通常的系统调用系统函数的话,会浪费必定的时间去移动和请求。
答:
Redis是单进程单线程的,redis利用队列技术将并发访问变为串行访问,消除了传统数据库串行控制的开销。
答:
512M。
答:
Redis是一个支持持久化的内存数据库,经过持久化机制把内存中的数据同步到硬盘文件来保证数据持久化。当Redis重启后经过把硬盘文件从新加载到内存,就能达到恢复数据的目的。
实现:单首创建fork()一个子进程,将当前父进程的数据库数据复制到子进程的内存中,而后由子进程写入到临时文件中,持久化的过程结束了,再用这个临时文件替换上次的快照文件,而后子进程退出,内存释放。
RDB是Redis默认的持久化方式。按照必定的时间周期策略把内存的数据以快照的形式保存到硬盘的二进制文件。即Snapshot快照存储,对应产生的数据文件为dump.rdb,经过配置文件中的save参数来定义快照的周期。( 快照能够是其所表示的数据的一个副本,也能够是数据的一个复制品。)
AOF:Redis会将每个收到的写命令都经过Write函数追加到文件最后,相似于MySQL的binlog。当Redis重启是会经过从新执行文件中保存的写命令来在内存中重建整个数据库的内容。当两种方式同时开启时,数据恢复Redis会优先选择AOF恢复。
答:
1、缓存雪崩
咱们能够简单的理解为:因为原有缓存失效,新缓存未到期间(例如:咱们设置缓存时采用了相同的过时时间,在同一时刻出现大面积的缓存过时),全部本来应该访问缓存的请求都去查询数据库了,而对数据库CPU和内存形成巨大压力,严重的会形成数据库宕机。从而造成一系列连锁反应,形成整个系统崩溃。
解决办法:
大多数系统设计者考虑用加锁( 最多的解决方案)或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写,从而避免失效时大量的并发请求落到底层存储系统上。还有一个简单方案就时讲缓存失效时间分散开。
2、缓存穿透
缓存穿透是指用户查询数据,在数据库没有,天然在缓存中也不会有。这样就致使用户查询的时候,在缓存中找不到,每次都要去数据库再查询一遍,而后返回空(至关于进行了两次无用的查询)。这样请求就绕过缓存直接查数据库,这也是常常提的缓存命中率问题。
解决办法:
最多见的则是采用布隆过滤器,将全部可能存在的数据哈希到一个足够大的bitmap中,一个必定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法,若是一个查询返回的数据为空(无论是数据不存在,仍是系统故障),咱们仍然把这个空结果进行缓存,但它的过时时间会很短,最长不超过五分钟。经过这个直接设置的默认值存放到缓存,这样第二次到缓冲中获取就有值了,而不会继续访问数据库,这种办法最简单粗暴。
5TB的硬盘上放满了数据,请写一个算法将这些数据进行排重。若是这些数据是一些32bit大小的数据该如何解决?若是是64bit的呢?
对于空间的利用到达了一种极致,那就是Bitmap和布隆过滤器(Bloom Filter)。
Bitmap: 典型的就是哈希表
缺点是,Bitmap对于每一个元素只能记录1bit信息,若是还想完成额外的功能,恐怕只能靠牺牲更多的空间、时间来完成了布隆过滤器(推荐) 就是引入了k(k>1)k(k>1)个相互独立的哈希函数,保证在给定的空间、误判率下,完成元素判重的过程。
它的优势是空间效率和查询时间都远远超过通常的算法,缺点是有必定的误识别率和删除困难。
Bloom-Filter算法的核心思想就是利用多个不一样的Hash函数来解决“冲突”。
Hash存在一个冲突(碰撞)的问题,用同一个Hash获得的两个URL的值有可能相同。为了减小冲突,咱们能够多引入几个Hash,若是经过其中的一个Hash值咱们得出某元素不在集合中,那么该元素确定不在集合中。只有在全部的Hash函数告诉咱们该元素在集合中时,才能肯定该元素存在于集合中。这即是Bloom-Filter的基本思想。
Bloom-Filter通常用于在大数据量的集合中断定某元素是否存在。
3、缓存预热
缓存预热这个应该是一个比较常见的概念,相信不少小伙伴都应该能够很容易的理解,缓存预热就是系统上线后,将相关的缓存数据直接加载到缓存系统。这样就能够避免在用户请求的时候,先查询数据库,而后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!
解决思路:
一、直接写个缓存刷新页面,上线时手工操做下;
二、数据量不大,能够在项目启动的时候自动进行加载;
三、定时刷新缓存
4、缓存更新
除了缓存服务器自带的缓存失效策略以外(Redis默认的有6中策略可供选择),咱们还能够根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种:
(1)定时去清理过时的缓存;
(2)当有用户请求过来时,再判断这个请求所用到的缓存是否过时,过时的话就去底层系统获得新数据并更新缓存。
二者各有优劣,第一种的缺点是维护大量缓存的key是比较麻烦的,第二种的缺点就是每次用户请求过来都要判断缓存失效,逻辑相对比较复杂!具体用哪一种方案,你们能够根据本身的应用场景来权衡。
5、缓存降级
当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然须要保证服务仍是可用的,即便是有损服务。系统能够根据一些关键数据进行自动降级,也能够配置开关实现人工降级。
降级的最终目的是保证核心服务可用,即便是有损的。并且有些服务是没法降级的(如加入购物车、结算)。
以参考日志级别设置预案:
(1)通常:好比有些服务偶尔由于网络抖动或者服务正在上线而超时,能够自动降级;
(2)警告:有些服务在一段时间内成功率有波动(如在95~100%之间),能够自动降级或人工降级,并发送告警;
(3)错误:好比可用率低于90%,或者数据库链接池被打爆了,或者访问量忽然猛增到系统能承受的最大阀值,此时能够根据状况自动降级或者人工降级;
(4)严重错误:好比由于特殊缘由数据错误了,此时须要紧急人工降级。服务降级的目的,是为了防止Redis服务故障,致使数据库跟着一块儿发生雪崩问题。所以,对于不重要的缓存数据,能够采起服务降级策略,例如一个比较常见的作法就是Redis出现问题,不去数据库查询,而是直接返回默认值给用户。
答:
热点数据,缓存才有价值对于冷数据而言,大部分数据可能尚未再次访问到就已经被挤出内存,不只占用内存,并且价值不大。频繁修改的数据,看状况考虑使用缓存对于上面两个例子,寿星列表、导航信息都存在一个特色,就是信息修改频率不高,读取一般很是高的场景。
对于热点数据,好比咱们的某IM产品,生日祝福模块,当天的寿星列表,缓存之后可能读取数十万次。再举个例子,某导航产品,咱们将导航信息,缓存之后可能读取数百万次。
数据更新前至少读取两次,缓存才有意义。这个是最基本的策略,若是缓存尚未起做用就失效了,那就没有太大价值了。
那存不存在,修改频率很高,可是又不得不考虑缓存的场景呢?有!好比,这个读取接口对数据库的压力很大,可是又是热点数据,这个时候就须要考虑经过缓存手段,减小数据库的压力,好比咱们的某助手产品的,点赞数,收藏数,分享数等是很是典型的热点数据,可是又不断变化,此时就须要将数据同步保存到Redis缓存,减小数据库压力。
答:
(一)纯内存操做
(二)单线程操做,避免了频繁的上下文切换
(三)采用了非阻塞I/O多路复用机制
答:
一共五种
(一)String
这个其实没啥好说的,最常规的set/get操做,value能够是String也能够是数字。通常作一些复杂的计数功能的缓存。
(二)hash
这里value存放的是结构化的对象,比较方便的就是操做其中的某个字段。博主在作单点登陆的时候,就是用这种数据结构存储用户信息,以cookieId做为key,设置30分钟为缓存过时时间,能很好的模拟出相似session的效果。
(三)list
使用List的数据结构,能够作简单的消息队列的功能。另外还有一个就是,能够利用lrange命令,作基于redis的分页功能,性能极佳,用户体验好。本人还用一个场景,很合适—取行情信息。就也是个生产者和消费者的场景。LIST能够很好的完成排队,先进先出的原则。
(四)set
由于set堆放的是一堆不重复值的集合。因此能够作全局去重的功能。为何不用JVM自带的Set进行去重?由于咱们的系统通常都是集群部署,使用JVM自带的Set,比较麻烦,难道为了一个作一个全局去重,再起一个公共服务,太麻烦了。
另外,就是利用交集、并集、差集等操做,能够计算共同喜爱,所有的喜爱,本身独有的喜爱等功能。
(五)sorted set
sorted set多了一个权重参数score,集合中的元素可以按score进行排列。能够作排行榜应用,取TOP N操做
答:
redis采用的是按期删除+惰性删除策略。
为何不用定时删除策略?
定时删除,用一个定时器来负责监视key,过时则自动删除。虽然内存及时释放,可是十分消耗CPU资源。在大并发请求下,CPU要将时间应用在处理请求,而不是删除key,所以没有采用这一策略。
按期删除+惰性删除是如何工做的呢?
按期删除,redis默认每一个100ms检查,是否有过时的key,有过时key则删除。须要说明的是,redis不是每一个100ms将全部的key检查一次,而是随机抽取进行检查(若是每隔100ms,所有key进行检查,redis岂不是卡死)。所以,若是只采用按期删除策略,会致使不少key到时间没有删除。因而,惰性删除派上用场。也就是说在你获取某个key的时候,redis会检查一下。
这个key若是设置了过时时间那么是否过时了?
若是过时了此时就会删除。
采用按期删除+惰性删除就没其余问题了么?
不是的,若是按期删除没删除key。而后你也没即时去请求key,也就是说惰性删除也没生效。这样,redis的内存会愈来愈高。那么就应该采用内存淘汰机制。在redis.conf中有一行配置。
该配置就是配内存淘汰策略的(什么,你没配过?好好检讨一下本身)
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(不删除) 基本上一致
答:
(1) Master 最好不要作任何持久化工做,如RDB内存快照和AOF日志文件
(2) 若是数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一次
(3) 为了主从复制的速度和链接的稳定性, Master和Slave最好在同一个局域网内
(4) 尽可能避免在压力很大的主库上增长从库
(5) 主从复制不要用图状结构,用单向链表结构更为稳定,即: Master<- Slave1 <- Slave2 <-Slave3
答:
对于Redis而言,命令的原子性指的是:一个操做的不能够再分,操做要么执行,要么不执行。
Redis的操做之因此是原子性的,是由于Redis是单线程的。
Redis自己提供的全部API都是原子操做,Redis中的事务实际上是要保证批量操做的原子性。
多个命令在并发中也是原子性的吗?
不必定, 将get和set改为单命令操做,incr 。使用Redis的事务,或者使用Redis+Lua==的方式实现。
答:
Redis事务功能是经过MULTI、EXEC、DISCARD和WATCH四个原语实现的
Redis会将一个事务中的全部命令序列化,而后按顺序执行。
1.redis 不支持回滚“Redis 在事务失败时不进行回滚,而是继续执行余下的命令”, 因此Redis的内部能够保持简单且快速。
2.若是在一个事务中的命令出现错误,那么全部的命令都不会执行;
3.若是在一个事务中出现运行错误,那么正确的命令会被执行。
1)MULTI命令用于开启一个事务,它老是返回OK。 MULTI执行以后,客户端能够继续向服务器发送任意多条命令,这些命令不会当即被执行,而是被放到一个队列中,当EXEC命令被调用时,全部队列中的命令才会被执行。
2)EXEC:执行全部事务块内的命令。返回事务块内全部命令的返回值,按命令执行的前后顺序排列。当操做被打断时,返回空值 nil 。
3)经过调用DISCARD,客户端能够清空事务队列,并放弃执行事务, 而且客户端会从事务状态中退出。
4)WATCH命令能够为Redis 事务提供check-and-set(CAS)行为。 能够监控一个或多个键,一旦其中有一个键被修改(或删除),以后的事务就不会执行,监控一直持续到EXEC命令
答:
Redis 提供两种持久化机制 RDB 和 AOF 机制: 一、RDBRedis DataBase)持久化方式: 是指用数据集快照的方式半持久化模式)记录 redis 数据库的全部键值对,在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。
优势:
一、只有一个文件dump.rdb,方便持久化。
二、容灾性好,一个文件能够保存到安全的磁盘。
三、性能最大化,fork子进程来完成写操做,让主进程继续处理命令,因此是IO最大化。使用单独子进程来进行持久化,主进程不会进行任何IO操做,保证了 redis的高性能)
4.相对于数据集大时,比AOF的启动效率更高。
缺点:
一、数据安全性低。RDB是间隔一段时间进行持久化,若是持久化之间redis发生故障,会发生数据丢失。因此这种方式更适合数据要求不严谨的时候)
二、AOFAppend-only file)持久化方式: 是指全部的命令行记录以redis命令请求协议的格式彻底持久化存储)保存为aof文件。
优势:
一、数据安全,aof持久化能够配置appendfsync属性,有always,每进行一次命令操做就记录到 aof 文件中一次。
二、经过append模式写文件,即便中途服务器宕机,能够经过redis-check-aof工具解决数据一致性问题。
三、AOF机制的rewrite模式。AOF文件没被rewrite以前(文件过大时会对命令进行合并重写),能够删除其中的某些命令(好比误操做的flushall))
缺点:
一、AOF文件比RDB文件大,且恢复速度慢。
二、数据集大的时候,比rdb启动效率低。
答:
一、Master最好不要写内存快照,若是Master写内存快照,save命令调度rdbSave函数,会阻塞主线程的工做,当快照比较大时对性能影响是很是大的,会间断性暂停服务
二、若是数据比较重要,某个Slave开启AOF备份数据,策略设置为每秒同步一
三、为了主从复制的速度和链接的稳定性,Master和Slave最好在同一个局域网
四、尽可能避免在压力很大的主库上增长从
五、主从复制不要用图状结构,用单向链表结构更为稳定,即:Master<- Slave1<- Slave2 <- Slave3这样的结构方便解决单点故障问题,实现Slave对Master的替换。若是Master挂了,能够马上启用Slave1作Master,其余不变。
答:
一、定时删除:在设置键的过时时间的同时,建立一个定时器timer). 让定时器在键的过时时间来临时,当即执行对键的删除操做。
二、惰性删除:听任键过时无论,可是每次从键空间中获取键时,都检查取得的键是否过时,若是过时的话,就删除该键;若是没有过时,就返回该键。
三、按期删除:每隔一段时间程序就对数据库进行一次检查,删除里面的过时键。至于要删除多少过时键,以及要检查多少个数据库,则由算法决定。
答:
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
二、若是数据呈现平等分布,也就是全部的数据访问频率都相同,则使用allkey
答:
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种数据淘汰策略:
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(驱逐):禁止驱逐数据
答:
一、会话缓存(Session Cache)
最经常使用的一种使用 Redis 的情景是会话缓存(session cache)。用 Redis 缓存会话比其余存储(如 Memcached)的优点在于:Redis 提供持久化。当维护一个不是严格要求一致性的缓存时,若是用户的购物车信息所有丢失,大部分人都会不高兴的,如今,他们还会这样吗?
幸运的是,随着 Redis 这些年的改进,很容易找到怎么恰当的使用 Redis 来缓存会话的文档。甚至广为人知的商业平台Magento 也提供 Redis 的插件。
二、全页缓存(FPC)
除基本的会话token以外,Redis还提供很简便的FPC平台。回到一致性问题,即便重启了 Redis实例,由于有磁盘的持久化,用户也不会看到页面加载速度的降低,这是一个极大改进,相似PHP本地 FPC。 再次以agento为例,Magento提供一个插件来使用 Redis 做为全页缓存后端。 此外,对WordPress的用户来讲,Pantheon有一个很是好的插件 wp-redis,这个插件能帮助你以最快速度加载你曾浏览过的页面。
三、队列
Reids 在内存存储引擎领域的一大优势是提供 list 和 set 操做,这使得 Redis能做为一个很好的消息队列平台来使用。Redis 做为队列使用的操做,就相似于本地程序语言(如 Python)对list的push/pop操做。 若是你快速的在Google中搜索“Redisqueues”,你立刻就能找到大量的开源项目,这些项目的目的就是利用Redis建立很是好的后端工具,以知足各类队列需求。例如,Celery有一个后台就是使用Redis做为 broker,你能够从这里去查看。
4,排行榜/计数器
Redis 在内存中对数字进行递增或递减的操做实现的很是好。集合(Set)和有序集合(Sorted Set)也使得咱们在执行这些操做的时候变的很是简单,Redis 只是正好提供了这两种数据结构。因此,咱们要从排序集合中获取到排名最靠前的 10个用户–咱们称之为“user_scores”,咱们只须要像下面同样执行便可: 固然,这是假定你是根据你用户的分数作递增的排序。若是你想返回用户及用户的分数,你须要这样执行: ZRANGE user_scores 0 10 WITHSCORES Agora Games就是一个很好的例子,用 Ruby 实现的,它的排行榜就是使用 Redis 来存储数据的,你能够在这里看到
五、发布/订阅
最后(但确定不是最不重要的)是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合成一条指令来用的!对方这时会显露笑容,内心开始默念:摁,这小子还不错。
该面试题答案解析完整文档获取方式:Redis面试题总结