-
SDS是什么?
Redis中字符串的实现,Simple Dynamic String简单动态字符串。 -
为什么 Redis要用SDS实现字符串?
因为C语言本身没有字符串类型,只能用字符数组char[]实现。
1、使用字符数组必须先给目标变量分配足够的空间,否则可能会溢出。
2、如果要获取字符长度,必须遍历字符数组,时间复杂度是O(n)
3、C字符串长度的变更会对字符数组做内存重分配。
4、通过从字符串开始到结尾碰到的第一个’\0’来标记字符串的结束,因此不能保存图片、音频、视频、压缩文件等二进制(bytes)保存的内容,二进制不安全。
SDS的特点:
1、不用担心内存溢出问题,如果需要会对SDS进行扩容。
2、获取字符串长度时间复杂度为O(1),因为定义了len属性。
3、通过"空间预分配"(sdsMakeRoomFor)和"惰性空间释放",防止多次重分配内存。
4、判断是否结束的标志是len属性,可以包含’\0’(它同样以0结尾是因为这样就可以使用C语言中函数库操作字符串的函数了)。 -
embstr和raw编码的区别?为什么要为不同大小设计不同编码?
embstr的使用只分配一次内存空间(因为RedisObject和SDS是连续的),而raw需要分配两次内存空间(分别为RedisObject和SDS分配空间)。因此与raw相比,embstr的好处在于创建时少分配一次空间,删除时少释放一次空间,以及对象的所有数据连在一起,寻找方便。而embstr的坏处也很明显,如果字符串的长度增加需要重新分配内存时,整个RedisObject和SDS都需要重新分配空间,因此Redis中的embstr实现为只读(这种编码的内容是不能修改的) -
int和embstr什么时候转化为raw?
1,int数据不再是整数——raw
2,int大小超过了long的范围(2^63-1)——embstr
3,embstr长度超过了44个字节——raw -
embstr明明没有超过44个字节,为什么变成raw了?
对于embstr,由于它的实现是只读的,因此在对embstr对象进行修改时,都会先转化为raw再进行修改。因此,只要是修改embstr对象,修改后的对象一定是raw的,无论是否达到了44个字节。 -
当长度小于阈值时,会还原吗?
关于Redis内部编码的转换,都符合以下规律:编码转换在Redis写入数据时完成,且转换过程不可逆,只能从小内存编码向大内存编码转换(但是不包括重新set) -
为什么要对底层的数据结构使用redisObject进行一层包装呢?
其实无论是设计redisObject,还是对存储字符设计这么多的SDS,都是为了根据存储的不同内容选择不同的存储方式,这样可以实现尽量地节省内存空间和提升查询速度的目的。 -
什么时候使用ziplist存储?
当hash对象同时满足以下两个条件的时候,使用ziplist编码:
1)哈希对象保存的键值对数量<512个;
2)所有的键值对的健和值的字符串长度都<64byte(一个英文字母一个字节)
src/redis.conf配置hash-max-ziplist-value 64//ziplist 中最大能存放的值长度 hash-max-ziplist-entries 512//ziplist 最多能存放t entry 节 数量
如果超过这两个阈值的任何一个,存储结构就会转换成hashtable.
-
为什么要定义两个哈希表,其中一个不用呢?
redis的hash默认使用的是ht[0],ht[1]不会初始化和分配空间。哈希表dictht是用链地址法来解决碰撞问题的。在这种情况下,哈希表的性能取决于它的大小(size属性)和它所保存的节点的数量(used属性)之间的比率:
1)比率在1:1时(一个哈希表ht只存储一个节点entry),哈希表的性能最好;
2)如果节点数量比哈希表的大小要大很多的话(这个比例用ratio表示,5表示平均一个ht存储5个entry),那么哈希表就会退化成多个链表,哈希表本身的性能优势就不再存在。
如果单个哈希表的节点数量过多,哈希表的大小需要扩容。Redis里面的这种操作叫做rehash。
rehash的步骤:
1)为字符ht[1]哈希表分配空间。ht[1]的大小为第一个大于等于ht[0].used*2的2的N次方幂。比如已经使用了10000,那就是16384。
2)将所有的ht[0]上的节点rehash到ht[1]上,重新计算hash值和索引,然后放入指定的位置。
3)当ht[0]全部迁移到了ht[1]之后,释放ht[0]的空间,将ht[1]设置为ht[0]表,并创建新的ht[1],为下次rehash做准备。 -
AOF文件越来越大,怎么办?
由于AOF持久化是Redis不断将写命令记录到AOF文件中,随着Redis不断的进行,AOF的文件会越来越大,文件越大,占用服务器内存越大以及AOF恢复要求时间越长。例如计数器增加100万次,100万个命令都记录进去了,但是结果只有1个。为了解决这个问题,Redis新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof来重写。AOF文件重写并不是对原文件进行重新整理,而是直接读取服务器现有的键值对,然后用一条命令去代替之前记录这个键值对的多条命令,生成一个新的文件后去替换原来的AOF文件。 -
什么是Redis?简述它的优缺点?
Redis的全称是:Remote Dictionary.Server,本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库统统加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存
因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过10万次读写操作,是已知性能最快的Key-Value DB.
Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存多种数据结构,此外单个value的最大限制是1GB,不像memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能。比方说用他的List来做FIFO双向链表,实现一个轻量级的高性能消息队列服务,用他的Set可以做高性能的tag系统等等
另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一个功能加强版的memcached来用。Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。 -
Redis与memcached相比有哪些优势?
1.memcached所有的值均是简单的字符串,redis作为其替代者,支持更为丰富的数据类型
2.redis的速度比memcached快很多redis的速度比memcached快很多
3.redis可以持久化其数据redis可以持久化其数据 -
Redis支持哪几种数据类型?
String.List,Set,Sorted Set,hashes -
Redis主要消耗什么物理资源?
内存 -
Redis有哪几种数据淘汰策略?
1.noeviction:返回错误当内存限制达到,并且客户端尝试执行会让更多内存被使用的命令。
2.allkeys-lru:尝试回收最少使用的键(LRU),使得新添加的数据有空间存放。
3.volatile-lru:尝试回收最少使用的键(LRU),但仅限于在过期集合的键,使得新添加的数据有空间存放。
4.allkeys-random:回收随机的键使得新添加的数据有空间存放。
5.volatile-random:回收随机的键使得新添加的数据有空间存放,但仅限于在过期集合的键。
6.volatile-ttl:回收在过期集合的键,并且优先回收存活时间(TTL)较短的键,使得新添加的数据有空间存放。 -
Redis官方为什么不提供Windows版本?
因为目前Linux版本已经相当稳定,而且用户量很大,无需开发windows版本,反而会带来兼容性等问题。 -
一个字符串类型的值能存储最大容量是多少?
512M -
为什么Redis需要把所有数据放到内存中?
Redis为了达到最快的读写速度将数据都读到内存中,并通过异步的方式将数据写入磁盘。
所以redis具有快速和数据持久化的特征,如果不将数据放在内存中,磁盘1/0速度为严重影响redis的性能。
在内存越来越便宜的今天,redis将会越来越受欢迎,如果设置了最大使用的内存,则数据已有记录数达到内存限值后不能继续插入新值。 -
Redis集群方案应该怎么做?都有哪些方案?
1.codis
2目前用的最多的集群方案,基本和twemproxy一致的效果,但它支持在节点数量改变情况下,旧节点数据可恢复到新hash节点。
redis cluster3.0自带的集群,特点在于他的分布式算法不是一致性hash,而是hash槽的概念,以及自身支持节点设置从节点。具体看官方文档介绍。
3在业务代码层实现,起几个毫无关联的redis实例,在代码层,对key进行hash计算,然后去对应的redis实例操作数据。这种方式对hash层代码要求比较高,考虑部分包括,节点失效后的替代算法方案,数据震荡后的自动脚本恢复,实例的监控,等等。 -
Redis集群方案什么情况下会导致整个集群不可用?
有A,B,c三个节点的集群,在没有复制模型的情况下,如果节点B失败了,那么整个集群就会以为缺少5501-11000这个范围的槽而不可用。 -
MySQL里有2000w数据redis 中只存 20w 的数据,如何保证redis中的数据都是热点数据?
redis内存数据集大小上升到一定大小的时候,就会施行数据淘汰策略。 -
Redis有哪些适合的场景?
(1)会话缓存(Session Cache)
最常用的一种使用Redis的情景是会话缓存(sessioncache),用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,你可以从这里去查看。 -
Redis支持的Java客户端都有哪些?官方推荐用哪个?
Redisson,Jedis,lettuce等等,官方推荐使用Redisson。 -
Jedis与Redisson对比有什么优缺点?
Jedis是Redis的Java实现的客户端,其API提供了比较全面的Redis命令的支持;Redisson实现了分布式和可扩展的Java数据结构,和Jedis相比,功能较为简单,不支持字符串操作不支持排序、事务、管道、分区等Redis特性。Redisson的宗旨是促进使用者对Redis的关注分离,从而让使用者能够将精力更集中地放在处理业务逻辑上。 -
说说Redis哈希槽的概念?
Redis集群没有使用一致性hash,而是引入了哈希槽的概念,Redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽,集群的每个节点负责一部分hash槽。 -
Redis集群的主从复制模型是怎样的?
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用,所以集群使用了主从复制模型,每个节点都会有N-1个复制品 -
Redis集群会有写操作丢失吗?为什么?
Redis并不能保证数据的强一致性,这意味这在实际中集群在特定的条件下可能会丢失写操作。 -
Redis集群之间是如何复制 ?
异步复制 -
Redis集群最大节点个数是多少?
16384个 -
Redis集群如何选择数据库?
Redis集群目前无法做数据库选择,默认在0数据库。 -
Redis中的管道有什么用?
一次请求/响应服务器能实现处理新的请求即使旧的请求还未被响应,这样就可以将多个命令发送到服务器,而不用等待回复,最后在一个步骤中读取该答复。
这就是管道(pipelining),是一种几十年来广泛使用的技术。例如许多POP3协议已经实现支持这个功能,大大加快了从服务器下载新邮件的过程。 -
怎么理解Redis事务?
事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行,事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。 -
Redis事务相关的命令有哪几个?
MULTI, EXEC, DISCARD, WATCH -
Redis key的过期时间和永久有效分别怎么设置?
EXPIRE和PERSIST命令 -
Redis如何做内存优化?
尽可能使用散列表(hashes),散列表(是说散列表里面存储的数少)使用的内存非常小,所以你应该尽可能的将你的数据模型抽象到一个散列表里面。
比如你的web系统中有一个用户对象,不要为这个用户的名称,姓氏,邮箱,密码设置单独的key,而是应该把这个用户的所有信息存储到一张散列表里面。 -
Redis回收进程如何工作的?
一个客户端运行了新的命令,添加了新的数据。
Redi检查内存使用情况,如果大于maxmemory的限制,则根据设定好的策略进行回收。
一个新的命令被执行,等等。
所以我们不断地穿越内存限制的边界,通过不断达到边界然后不断地回收回到边界以下。
如果一个命令的结果导致大量内存被使用(例如很大的集合的交集保存到一个新的键),不用多久内存限制就会被这个内存使用量超越。 -
使用过Redis分布式锁么,它是怎么实现的?
先拿setnx来争抢锁,抢到之后,再用expire给锁加一个过期时间防止锁忘记了释放。果在setnx之后执行expire之前进程意外crash或者要重启维护了,那会怎么样?
set指令有非常复杂的参数,这个应该是可以同时把setnx和expire合成-条指令来用的! -
使用过Redis做异步队列么,你是怎么用的?有什么缺点?
一般使用list结构作为队列,rpush生产消息,lpop消费消息。当lpop没有消息的时候,要适当sleer一会再重试。
缺点:在消费者下线的情况下,生产的消息会丢失,得使用专业的消息队列如rabbitmq等。
能不能生产一次消费多次呢?
使用pub/sub主题订阅者模式,可以实现1:N的消息队列。 -
什么是缓存穿透?如何避免?什么是缓存雪崩?何如避免?
缓存穿透
一般的缓存系统,都是按照key去缓存查询,如果不存在对应的value,就应该去后端系统查找(比如DB)。一些恶意的请求会故意查询不存在的key,请求量很大,就会对后端系统造成很大的压力。这就叫做缓存穿透。如何避免?
1:对查询结果为空的情况也进行缓存,缓存时间设置短一点,或者该key对应的数据insert了之后清理缓存。
2:对一定不存在的key进行过滤。可以把所有的可能存在的key放到一个大的Bitmap中,查询时通过该bitmap 过滤。
缓存雪崩
当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,会给后端系统带来很大压力。导致系统崩溃。
如何避免?
1:在缓存失效后,通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存,其他线程等待。
2:做二级缓存,A1为原始缓存,A2为拷贝缓存,A1失效时,可以访问A2,A1缓存失效时间设置为短期,A2设置为长期
3:不同的key,设置不同的过期时间,让缓存失效的时间点尽量均匀 -
redis和memcached什么区别?为什么高并发下有时单线程的redis 比多 程的memcached效率要高?
区别
1.mc可缓存图片和视频。rd支持除k/v更多的数据结构;
2.rd可以使用虚拟内存,rd可持久化和aof灾难恢复,rd通过主从支持数据备份;
3.rd可以做消息队列。
原因:mc多线程模型引入了缓存一致性和锁,加锁带来了性能耗。 -
redis主从复制如何实现的?redis的集群模式如何实现?redis的key是如何寻址的?
主从复制实现:主节点将自己内存中的数据做一份快照,将快照发给从节点,从节点将数据恢复到内存中。之后再每次增加新数据的时候,主节点以类似于mysql的二进制日志方式将语句发送给从节点,从节点拿到主节点发送过来的语句进行重放
分片方式:
客户端分片
基于代理的分片
Twemproxy
codis
路由查询分片
Redis-cluster(本身提供了自动将数据分散到Redis Cluster不同节点的能力,整个数据集合的某个数据子集存储在哪个节点对于用户来说是透明的)
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如何设计分布式锁?说一下实现思路?使用zk可以吗?如何实现?这两种有什么区别?
redis:
1.线程A setnx(上锁的对象,超时时的时间戳t1),如果返回true,获得锁。
2线程B用get获取t1,与当前时间戳比较,判断是是否超时,没超时false,若超时执行第3步;
3·计算新的超时时间t2,使用getset命令返回t3(该值可能其他线程已经修改过),如果t1==t3,获得锁,如果t1!-t3说明锁被其他线程获取了。
4.获取锁后,处理完业务逻辑,再去判断锁是否超时,如果没超时删除锁,如果已超时不用处理(防止删除其他线程的锁)。
zk:
1.客户端对某个方法加锁时,在zk上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点node1,
2.客户端获取该路径下所有已经创建的子节点,如果发现自己创建的node1的序号是最小1的,就认为这个客户端获得了锁。
3.如果发现node1不是最小的,则监听比自己创建节点序号小的最大的节点,进入等待。
4.获取锁后,处理完逻辑,删除自己创建的nodel即可。
区别zk性能差一些,开销大,实现简单。 -
知道redis的持久化吗?底层如何实现的?有什么优点缺点?
RDB(Redis DataBase:在不同的时间点将redis的数据生成的快照同步到磁盘等介质上):内存到硬盘的快照,定期更新。缺点:耗时,耗性能(fork+io操作),易丢失数据。
AOF(Append Only File:将redis所执行过的所有指令都记录下来,在下次redis重启时,只需要执行指令就可以了):写日志。缺点:体积大,恢复速度慢。
bgsave做镜像全量持久化,aof做增量持久化。因为bgsave会消耗比较长的时间,不够实时,在停机的时候会导致大量的数据丢失,需要aof来配合,在redis实例重启时,优先使用aof来恢复内存的状态,如果没有aof日志,就会使用rdb文件来恢复。Redis会定期做aof重写,压缩aof文件日志大小。Redis4.0之后有了混合持久化的功能,将bgsave的全量和aof的增量做了融合处理,这样既保证了恢复的效率又兼顾了数据的安全性。bgsave的原理,fork和cow,fork是指redis通过创建子进程来进行bgsave操作,cow指的是copy on write,子进程创建后,父子进程共享数据段,父进程继续提供读写服务,写脏的页面数据会逐渐和子进程分离开来。 -
redis过期策略都有哪些?LRU算法知道吗?写一下java代码实现?
过期策略:定时过期(-key一定时器),惰性过期:只有使用key时才判断key是否已过期,过期则清除。定期过期:前两者折中。
RU:new LinkedHashMap<K,V>(capacity,DEFAULT LOAD FACTORY,true);
//第三个参数置为true,代表linkedlist按访问顺序排序,可作为LRU缓存;设为false代表按插入顺序排序,可作为FIFO缓存
LRU算法实现:1.通过双向链表来实现,新数据插入到链表头部;2.每当缓存命中(即缓存数据被访问),则将数据移到链表头部;3当链表满的时候,将链表尾部的数据丢弃。
LinkedHashMap:HashMap和双向链表合二为一即是LinkedHashMap,HashMap是无序的,LinkedHashMap通过维护一个额外的双向链表保证了迭代顺序。该迭代顺序可以是插顺序(默认),也可以是访问顺序。 -
缓存穿透、缓存击穿、缓存雪崩解决方案?
|缓存穿透:指查询一个一定不存在的数据,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到DB去查询,可能导致DB挂掉。
解决方案:1查询返回的数据为空,仍把这个空结果进行缓存,但过期时间会比较短;2.布隆过滤器:将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对DB的查询。
缓存击穿:对于设置了过期时间的key,缓存在某个时间点过期的时候,恰好这时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把DB压垮。
解决方案:1使用互斥锁:当缓存失效时,不立即去load db,先使用如Redis的setnx去设置一个互斥锁,当操作成功返回时再进行load db的操作并回设缓存,否则重试get缓存的
方法。2.永远不过期:物理不过期,但逻辑过期(后台异步线程去刷新)。
缓存雪崩:设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部1转发到DB,DB瞬时压力过重雪崩。与缓存击穿的区别:雪崩是很多key,击穿是某一个key缓存。
解决方案:将缓存失效时间分散开,比如可以在原有的失效时间基础上增加一个随机值比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件。 -
在选择缓存时,什么时候选择redis,什么时候选择memcached?
选择redis的情况:
1、复杂数据结构,value的数据是哈希,列表,集合,有序集合等这种情况下,会选择redis,因为memcache无法满足这些数据结构,最典型的的使用场景是,用户订单列表用户消息,帖子评论等。
2、需要进行数据的持久化功能,但是注意,不要把redis当成数据库使用,如果redis挂了,内存能够快速恢复热数据,不会将压力瞬间压在数据库上,没有cache预热的过程。对于只读和数据一致性要求不高的场景可以采用持久化存储3、高可用,redis支持集群,可以实现主动复制,读写分离,而对于memcache如果想要实现高可用,需要进行二次开发。
4、存储的内容比较大,memcache存储的value最大为1M.
选择memcache的场景:
1、纯KV,数据量非常大的业务,使用memcache更合适,原因是,a)memcache的内存分配采用的是预分配内存池的管理方式,能够省去内存分配的时间,redis是临时申请空间,可能导致碎片化。
b)虚拟内存使用,memcache将所有的数据存储在物理内存里,redis有自己的vm机制,理论上能够存储比物理内存更多的数据,当数据超量时,引发swap,把冷数据刷新到磁盘上,从这点上,数据量大时,memcache更快c)网络模型,memcache使用非阻塞的10复用模型,redis也是使用非阻塞的10复用模型,但是redis还提供了一些非KV存储之外的排序,聚合功能,复杂的CPU计算,会阻塞整个10调度,从这点上由于redis提供的功能较多,memcache更快些 -
缓存与数据库不一致怎么办?
假设采用的主存分离,读写分离的数据库
如果一个线程A先删除缓存数据,然后将数据写入到主库当中,这个时候,主库和从库同步没有完成,线程B从缓存当中读取数据失败,从从库当中读取到旧数据,然后更新至缓存,这个时候,缓存当中的就是旧的数据。
发生上述不一致的原因在于,主从库数据不一致问题,加入了缓存之后,主从不一致的时间被拉长了
处理思路:在从库有数据更新之后,将缓存当中的数据也同时进行更新,即当从库发生了数据更新之后,向缓存发出删除,淘汰这段时间写入的旧数据。 -
主从数据库不一致如何解决
场景描述,对于主从库,读写分离,如果主从库更新同步有时差,就会导致主从库数据的不一致
1、忽略这个数据不一致,在数据一致性要求不高的业务下,未必需要时时一致性2、强制读主库,使用一个高可用的主库,数据库读写都在主库,添加一个缓存,提升数据读取的性能。
3、选择性读主库,添加一个缓存,用来记录必须读主库的数据,将哪个库,哪个表,哪个主键,作为缓存的key,设置缓存失效的时间为主从库同步的时间,如果缓存当中有这个数据,直接读取主库,如果缓存当中没有这个主键,就到对应的从库中读取。 -
Redis常见的性能问题和解决方案
1,master最好不要做持久化工作,如RDB内存快照和AOF日志文件
2、如果数据比较重要,某个slave开启AOF备份,策略设置成每秒同步一次
3、为了主从复制的速度和连接的稳定性,master和Slave最好在一个局域网内
4、尽量避免在压力大得主库上增加从库
5、主从复制不要采用网状结构,尽量是线性结构,Master<–Slavel<—Slave2… -
Redis的数据淘汰策略有哪些?
voltile-lru从已经设置过期时间的数据集中挑选最近最少使用的数据淘汰
voltile-ttl从已经设置过期时间的数据库集当中挑选将要过期的数据
voltile-random从已经设置过期时间的数据集任意选择淘汰数据
allkeys-ru从数据集中挑选最近最少使用的数据淘汰
allkeys-random从数据集中任意选择淘汰的数据
no-eviction禁止驱逐数据 -
Redis当中有哪些数据结构?
字符串String、字典Hash、列表List,集合Set、有序集合SortedSet,如果是高级用户,那么还会有,如果你是Redis中高级用户,还需要加上下面几种数据结构HyperLogLog,Geo,Pub/sub -
假如 Redis里面有1亿个 key,其中有10w个key是以某个固定的已知的前缀开头的,如果将它们全部找出来?
使用keys指令可以扫出指定模式的key列表。
对方接着追问:如果这个redis正在给线上的业务提供服务,那使用keys指令会有什么问题?
这个时候你要回答redis关键的一个特性:redis的单线程的。keys指令会导致线程阻塞-
段时间,线上服务会停顿,直到指令执行完毕,服务才能恢复。这个时候可以使用scan指令,scan指令可以无阻塞的提取出指定模式的key列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用keys指令长。 -
使用Redis做过异步队列吗,是如何实现的?
使用list类型保存数据信息,rpush生产消息,lpop消费消息,当lpop没有消息时,可以sleep一段时间,然后再检查有没有信息,如果不想sleep的话,可以使用blpop,在没有信息的时候,会一直阻塞,直到信息的到来。redis可以通过pub/sub主题订阅模式实现一个生产者,多个消费者,当然也存在一定的缺点,当消费者下线时,生产的消息会丢失。 -
Redis如何实现延时队列
使用sortedset,使用时间戳做score,消息内容作为key,调用zadd来生产消息,消费者使用zrangbyscore获取n秒之前的数据做轮询处理。
吊打面试官——redis
最新推荐文章于 2022-05-11 23:30:58 发布