这篇文章将为大家详细讲解有关关于redis缓存的面试题有哪些，小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
目前成都创新互联公司已为成百上千家的企业提供了网站建设、域名、网页空间、成都网站托管、企业网站设计、鼓楼网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。
区别：
memcached可缓存图片和视频。redis支持除k/v更多的数据结构；
redis可以使用虚拟内存，redis可持久化和aof灾难恢复，redis通过主从支持数据备份；
3.redis可以做消息队列。
原因：memcached多线程模型引入了缓存一致性和锁，加锁带来了性能损耗。
主从复制实现：主节点将自己内存中的数据做一份快照，将快照发给从节点，从节点将数据恢复到内存中。之后再每次增加新数据的时候，主节点以类似于MySQL的二进制日志方式将语句发送给从节点，从节点拿到主节点发送过来的语句进行重放。
分片方式：
客户端分片
基于代理的分片
Twemproxy
codis
路由查询分片
Redis-cluster体身提供了自动将数据分散到RedisCluster不同节点的能力，整个数据集合的某个数据子集存储在哪个节点对于用户来说是透明的）
redis-cluster分片原理：Cluster中有一个16384长度的槽（虚拟槽），编号分别为0-16383。每个Master节点都会负责一部分的槽，当有某个key被映射到某个Master负责的槽，那么这个Master负责为这个key提供服务，至于哪个Master节点负责哪个槽，可以由用户指定，也可以在初始化的时候自动生成，只有Master才拥有槽的所有权。Master节点维护着一个16384/8字节的位序列，Master节点用bit来标识对于某个槽自己是否拥有。比如对于编号为1的槽，Master只要判断序列的第二位（索引从0开始）是不是为1即可。这种结构很容易添加或者删除节点。比如如果我想新添加个节点D，我需要从节点A、B、C中得部分槽到D上。
【相关推荐：Redis视频教程】
redis：
线程Asetnx（上锁的对象超时时的时间戳tl），如果返回true，获得锁。
线程B用get获取t1，与当前时间戳比较，判断是是否超时，没超时false，若超时执行第3步；
计算新的超时时间t2，使用getset命令返回t3（该值可能其他线程已经修改过），如果t1==t3，获得锁，如果t1!=t3说明锁被其他线程获取了。
获取锁后，处理完业务逻辑，再去判断锁是否超时，如果没超时删除锁，如果已超时，不用处理（防止删除其他线程的锁）。
zk：
客户端对某个方法加锁时，在zk上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点node1；
客户端获取该路径下所有已经创建的子节点，如果发现自己创建的node1的序号是最小的，就认为这个客户端获得了锁。
如果发现node1不是最小的，则监听比自己创建节点序号小的最大的节点，进入等待。
获取锁后，处理完逻辑，删除自己创建的node1即可。区别：zk性能差一些，开销大，实现简单。
RDB（RedisDataBase：在不同的时间点将redis的数据生成的快照同步到磁盘等介质上）：内存到硬盘的快照，定期更新。缺点：耗时，耗性能（fork+io操作），易丢失数据。
AOF（AppendOnlyFile：将redis所执行过的所有指令都记录下来，在下次redis重启时，只需要执行指令就可以了）：写日志。缺点：体积大，恢复速度慢。
bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会消耗比较长的时间，不够实时，在停机的时候会导致大量的数据丢失，需要aof来配合，在redis实例重启时，优先使用aof来恢复内存的状态，如果没有aof日志，就会使用rdb文件来恢复。Redis会定期做aof重写，压缩aof文件日志大小。Redis4.0之后有了混合持久化的功能，将bgsave的全量和aof的增量做了融合处理，这样既保证了恢复的效率又兼顾了数据的安全性。bgsave的原理，fork和cow，fork是指redis通过创建子进程来进行bgsave操作，cow指的是copyonwrite，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分囲开来。
过期策略：
定时过期（一key一定时器），惰性过期：只有使用key时才判断key是否已过期，过期则清除。定期过期：前两者折中。
LRU：newLinkedHashMap
LRU算法实现：
通过双向链表来实现，新数据插入到链表头部；
每当缓存命中（即缓存数据被访问），则将数据移到链表头部；
当链表满的时候，将链表尾部的数据丢弃。
LinkedHashMap：HashMap和双向链表合二为一即是LinkedHashMap。HashMap是无序的，LinkedHashMap通过维护一个额外的双向链表保证了迭代顺序。该迭代顺序可以是插入顺序（默认），也可以是访问顺序。
**缓存穿透：**指查询一个一定不存在的数据，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到DB去查询，可能导致DB挂掉。
解决方案：
查询返回的数据为空，仍把这个空结果进行缓存，但过期时间会比较短；
布隆过滤器：将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对DB的查询。
**缓存击穿：**对于设置了过期时间的key，缓存在某个时间点过期的时候，恰好这时间点对这个Key有大量的并发请求过来，这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把DB压垮。
解决方案：
使用互斥锁：当缓存失效时，不立即去Ioaddb，先使用如Redis的setnx去设置一个互斥锁，当操作成功返回时再进行Ioaddb的操作并回设缓存，否则重试get缓存的方法。
永远不过期：物理不过期，但逻辑过期（后台异步线程去刷新）。缓存雪崩：设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。与缓存击穿的区别：雪崩是很多key，击穿是某一个key缓存。
解决方案：
将缓存失效时间分散开，比如可以在原有的失效时间基础上增加一个随机值，比如1-5分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。
选择redis的情况：
复杂数据结构，value的数据是哈希，列表，集合，有序集合等这种情况下，会选择redis，因为memcache无法满足这些数据结构，最典型的的使用场景是，用户订单列表，用户消息，帖子评论等。
需要进行数据的持久化功能，但是注意，不要把redis当成数据库使用，如果redis挂了，内存能够快速恢复热数据，不会将压力瞬间压在数据库上，没有cache预热的过程。对于只读和数据一致性要求不高的场景可以采用持久化存储
高可用，redis支持集群，可以实现主动复制，读写分离，而对于memcache如果想要实现高可用，需要进行二次开发。
存储的内容比较大，memcache存储的value最大为1M。
选择memcache的场景：
纯KV，数据量非常大的业务，使用memcache更合适，原因是：
memcache的内存分配采用的是预分配内存池的管理方式，能够省去内存分配的时间，redis是临时申请空间，可能导致碎片化。
虚拟内存使用，memcache将所有的数据存储在物理内存里，redis有自己的vm机制，理论上能够存储比物理内存更多的数据，当数据超量时，引发swap，把冷数据刷新到磁盘上，从这点上，数据量大时，memcache更快
网络模型，memcache使用非阻塞的10复用模型，redis也是使用非阻塞的I。复用模型，但是redis还提供了一些非KV存储之外的排序，聚合功能，复杂的CPU计算，会阻塞整个I0调度，从这点上由于redis提供的功能较多，memcache更快些
线程模型，memcache使用多线程，主线程监听，worker子线程接受请求，执行读写，这个过程可能存在锁冲突。redis使用的单线程，虽然无锁冲突，但是难以利用多核的特性提升吞吐量。
假设采用的主存分离，读写分离的数据库，
如果一个线程A先删除缓存数据，然后将数据写入到主库当中，这个时候，主库和从库同步没有完成，线程B从缓存当中读取数据失败，从从库当中读取到旧数据，然后更新至缓存，这个时候，缓存当中的就是旧的数据。
发生上述不一致的原因在于，主从库数据不一致问题，加入了缓存之后，主从不一致的时间被拉长了。
处理思路：在从库有数据更新之后，将缓存当中的数据也同时进行更新，即当从库发生了数据更新之后，向缓存发出删除，淘汰这段时间写入的旧数据。
场景描述，对于主从库，读写分离，如果主从库更新同步有时差，就会导致主从库数据的不一致
忽略这个数据不一致，在数据一致性要求不高的业务下，未必需要时时一致性
强制读主库，使用一个高可用的主库，数据库读写都在主库，添加一个缓存，提升数据读取的性能。
选择性读主库，添加一个缓存，用来记录必须读主库的数据，将哪个库，哪个表，哪个主键，作为缓存的key，设置缓存失效的时间为主从库同步的时间，如果缓存当中有这个数据，直接读取主库，如果缓存当中没有这个主键，就到对应的从库中读取。
master最好不要做持久化工作，如RDB内存快照和AOF日志文件
如果数据比较重要，某个slave开启AOF备份，策略设置成每秒同步一次
为了主从复制的速度和连接的稳定性，master和Slave最好在一个局域网内
尽量避免在压力大得主库上增加从库
主从复制不要米用网状结构，尽量是线性结构，Master<–Slave1<—Slave2…
voltile-lru从已经设置过期时间的数据集中挑选最近最少使用的数据淘汰
voltile-ttl从已经设置过期时间的数据库集当中挑选将要过期的数据
voltile-random从已经设置过期时间的数据集任意选择淘汰数据
allkeys-lru从数据集中挑选最近最少使用的数据淘汰
allkeys-random从数据集中任意选择淘汰的数据
no-eviction禁止驱逐数据
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。如果是咼级用户，那么还会有，如果你是Redis中高级用户，还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。
使用keys指令可以扫出指定模式的key列表。
对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。
使用list类型保存数据信息，rpush生产消息，lpop消费消息，当lpop没有消息时，可以sleep一段时间，然后再检查有没有信息，如果不想sleep的话，可以使用blpop，在没有信息的时候，会一直阻塞，直到信息的到来。redis可以通过pub/sub主题订阅模式实现一个生产者，多个消费者，当然也存在一定的缺点，当消费者下线时，生产的消息会丢失。
使用sortedset，使用时间戳做score，消息内容作为key，调用zadd来生产消息，消费者使用zrangbyscore获取n秒之前的数据做轮询处理。
Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。
因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是已知性能最快的Key-ValueDB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据
结构，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能。
比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。
另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
memcached所有的值均是简单的字符串，redis作为其替代者，支持更为丰富数据类型
Redis的速度比memcached快很多
redis可以持久化其数据
String、List、Set、SortedSet、hashes
内存。
Remote Dictionary Server
noeviction：返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令(大部分的写入指令，但DEL和几个例外)
allkeys-lru：尝试回收最少使用的键(LRU)，使得新添加的数据有空间存放。
volatile-lru：尝试回收最少使用的键(LRU)，但仅限于在过期集合的键，使得新添加的数据有空间存放。
allkeys-random：回收随机的键使得新添加的数据有空间存放。
volatile-random：回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。
volatile-ttl：回收在过期集合的键，并且优先回收存活时间(TTL)较短的键，使得新添加的数据有空间存放。
因为目前Linux版本已经相当稳定，而且用户量很大，无需开发windows版本，反而会带来兼容性等问题。
512M
Redis为了达到最快的读写速度将数据都读到内存中，并通过异步的方式将数据写入磁盘。
所以redis具有快速和数据持久化的特征。如果不将数据放在内存中，磁盘I/O速度为严重影响redis的性能。
在内存越来越便宜的今天，redis将会越来越受欢迎。如果设置了最大使用的内存，则数据已有记录数达到内存限值后不能继续插入新值。
codis。
目前用的最多的集群方案，基本和twemproxy一致的效果，但它支持在节点数量改变情况下，旧节点数据可恢复到新hash节点。
rediscluster3.0自带的集群，特点在于他的分布式算法不是一致性hash，而是hash槽的概念，以及自身支持节点设置从节点。具体看官方文档介绍。
在业务代码层实现，起几个毫无关联的redis实例，在代码层，对key进行hash计算，然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高，考虑部分包括，节点失效后的替代算法方案，数据震荡后的自动脚本恢复，实例的监控，等等。
有A，B，C三个节点的集群，在没有复制模型的情况下，如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。
redis内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。
会话缓存(SessionCache)
最常用的一种使用Redis的情景是会话缓存(sessioncache)。用Redis缓存会话比其他存储(如Memcached)的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着Redis这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。
全页缓存(FPC)
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。
队列
Reids在内存存储引擎领域的一大优点是提供list和set操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言(如Python)对list的push/pop操作。
如果你快速的在Google中搜索"Redisqueues"，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从这里去查看。
排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合(Set)和有序集合(SortedSet)也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户-我们称之为“user_scores”，我们只需要像下面一样执行即可：
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：
ZRANGEuser_scores010WITHSCORES
AgoraGames就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在这里看到。
发布/订阅
最后(但肯定不是最不重要的)是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！
Redisson、Jedis、lettuce等等，官方推荐使用Redisson。
Redisson是一个高级的分布式协调Redis客服端，能帮助用户在分布式环境中轻松实现一些Java的对象(Bloomfilter，BitSet，Set，SetMultimap，ScoredSortedSet，SortedSet，Map，ConcurrentMap，List，ListMultimap，Queue，BlockingQueue，Deque，BlockingDeque，Semaphore，Lock，ReadWriteLock，AtomicLong，CountDownLatch，Publish/Subscribe，HyperLogLog)。
Jedis是Redis的Java实现的客户端，其API提供了比较全面的Redis命令的支持；
Redisson实现了分布式和可扩展的Java数据结构，和Jedis相比，功能较为简单，不支持字符串操作，不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离，从而让使用者能够将精力更集中地放在处理业务逻辑上。
设置密码：config set require pass 123456 授权密码：auth223456
Redis集群没有使用一致性hash，而是引入了哈希槽的概念，Redis集群有16384个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责一部分hash槽。
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型，每个节点都会有N-1个复制品.
Redis并不能保证数据的强一致性，这意味这在实际中集群在特定的条件下可能会丢失写操作。
异步复制
16384个。
Redis集群目前无法做数据库选择，默认在0数据库。
ping
一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应。这样就可以将多个命令发送到服务器，而不用等待回复，最后在一个步骤中读取该答复。
这就是管道(pipelining)，是一种几十年来广泛使用的技术。例如许多POP3协议已经实现支持这个功能，大大加快了从服务器下载新邮件的过程。
事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。
MULTI、EXEC、DISCARD、WATCH
EXPIRE和PERSIST命令。
尽可能使用散列表(hashes)，散列表(是说散列表里面存储的数少)使用的内存非常小，所以你应该尽可能的将你的数据模型抽象到一个散列表里面。比如你的web系统中有一个用户对象，不要为这个用户的名称，姓氏，邮箱，密码设置单独的key，而是应该把这个用户的所有信息存储到一张散列表里面。
一个客户端运行了新的命令，添加了新的数据。
Redi检查内存使用情况，如果大于maxmemory的限制，则根据设定好的策略进行回收。一个新的命令被执行，等等。
所以我们不断地穿越内存限制的边界，通过不断达到边界然后不断地回收回到边界以下。
如果一个命令的结果导致大量内存被使用(例如很大的集合的交集保存到一个新的键)，不用多久内存限制就会被这个内存使用量超越。
关于“关于redis缓存的面试题有哪些”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
