1.Redis报内存不足怎么处理
Redis内存不足的集中处理方式:
- 修改配置文件redis.cof的maxmemory参数,增加Redis的可用内存
- 通过命令修改set maxmemory动态设置内存上限
- 修改内存淘汰策略,及时释放内存
- 使用Redis集群,及时进行扩容
2.Redis的过期回收策略
- 惰性删除: 惰性删除是指当我们查询key的时候才对key进行检测,如果已经达到过期时间,则删除,显然有一个缺点就是如果过期的key没有被访问,那么就会一直不被删除,而一直占用内存。
- 定期删除:定期删除是指Redis每隔一段时间对数据库做一次检查,删除里面的过期key,由于不可能做轮询key,所以Redis是每次随机抽取一下key做检查
3.Redis有哪些内存溢出控制策略
内存达到maxmemory上限时候会触发响应的控制策略,Redis支持6种策略
- noeviction: 默认策略,不会删除任何数据,拒绝写入任何数据并且返回错误信息,此时Redis只响应读操作
- volatile-lru:根据lru算法设置了超时属性的值,知道腾出足够的空间为止,如果没有可删除的健对象,回退到noeviction策略。
- allkeys-lru:根据LRU算法删除健,不管数据有没有设置超时属性,直到特腾出足够空间为止
- allkeys-random:随机删除所有的健,直到腾出空间为止。
- volatile-random:随机删除过期的健,直到腾出足够的空间
- volatile-ttl:根据键值属性,删除最近将要过期的数据,如果没有回退到noeviction策略。
4.Redis阻塞?怎么解决
-
API或者数据结构不合理
通常Redis执行命令速度非常快,但是不合理的使用命令,可能会导致执行速度变慢,导致阻塞,特别在高并发的时候,应该尽量避免在大对象执行算法复杂度超过O(n)的。
对慢查询的处理分为两步
1.使用查询show log get{n}命令可以获取最近的n条慢查询命令
2.发现慢查询后可从以下两个方向优化
- 修改为低算法的复杂度的命令,如hgetall改为hmget等,禁用keys,sort命令等
- 调整大对象:缩短大对象数据或者把大对象进行拆分为多个小对象,防止一次命令操作过多的数据。 -
CPU饱和问题
单线程的Redis处理命令时候只使用一个CPU,CPU饱和是指Redis单核CPU使用率接近100%。
处理步骤如下:
1.判断当前Redis并发量是否已经到达极限
2.如果当前并发QPs是已经几万+,那么可能已经到极限,可能需要做集群的水平化扩容来分担压力。
3.如果QPS只有几十,几百那么可能就要排查命令和内存的使用。 -
持久化相关的阻塞
对于开起了持久化功能的Redis节点,需要排查是否是持久化导致的阻塞。
1.fork阻塞:fork发生在RDB和AOF重写的时,Redis主线程调用fork操作产生共享,由子进程完成持久化文件重写工作,如果fork操作本身耗时长,必然会导致主线程的阻塞。
2.AOF刷盘阻塞:当我们开启AoF持久化的时候,文件的刷盘方式一般采用每秒一次,后台线程每秒对AOF文件做fsync操作,当硬盘压力过大,fsync需要等待直到写入完成,如果主线程发现距离上一次的fsync成功超过两秒,为了安全性它会阻塞直到后台线程完成fsync操作。
3.Hugepage写操作阻塞:对于开启Transparent HugePages的 操作系统,每次写命令引起的复制内存页单位由4K变为2MB,放大了512 倍,会拖慢写操作的执行时间,导致大量写操作慢查询
5.大key问题
大key情况:
- 单个key存储的value很大,超过10KB
- hash,set,zset,list储存过多的元素(以万为单位)
大key会造成什么情况
- 客户端耗时增加,甚至超时
- 对大key进行IO操作时,会严重占用带宽和CPU造成Redis集群中数据倾斜。
- 主动删除,被动删除可能会造成阻塞。
如何找到大key
- bigkeys命令:使用bigkeys命令以遍历的方式分析Redis实例中的所有key,并返回整体统计信息并返回每个数据类型中Top1的大key
- redis-db-tools::redis-rdb-tools是由Python写的用来分析Redis的rdb快照文件用的工具,它可以把rdb快照文件生
成json文件或者生成报表用来分析Redis的使用详情
如何处理大key
删除大key
- 当Redis版本大于4.0时,可使用UNLINK命令安全地删除大Key,该命令能够以非阻塞的方式,逐步地清理
传入的Key。 - 当Redis版本小于4.0时,避免使用阻塞式命令KEYS,而是建议通过SCAN命令执行增量迭代扫描key,然后判
断进行删除。
压缩和拆分key - 当vaule是string时,比较难拆分,则使用序列化、压缩算法将key的大小控制在合理范围内,但是序列化和
反序列化都会带来更多时间上的消耗。 - 当value是string,压缩之后仍然是大key,则需要进行拆分,一个大key分为不同的部分,记录每个部分的
key,使用multiget等操作实现事务读取。 - 当value是list/set等集合类型时,根据预估的数据规模来进行分片,不同的元素计算后分到不同的片。
6.使用Redis如何实现异步队列
- 使用list作为消息队列,lpush生产消息,rpop消费消息
这种方式,消费者死循环rpop从队列中消费消息,即使队列里面没有消息,也会进行rpop,导致redis的CPU消耗;可以通过让消费者休眠的方式来处理,但是这样又会有消息延迟的问题。
- 使用list作为消息队列,lpush生产消息,brpop进行消费消息
brpop是rpop的阻塞版本,list为空的时候,他会一直阻塞,直到list中有消息或者超时,但这种方式只能进行一对一的消息队列。
- 使用Redis的pub/sub来进行消息的发布/订阅
发布/订阅模式可以1:N的消息发布/订阅,发布者将消息发布到指定的频道,订阅响应频道的客户端都能收到消息。
但是这种消息是不可靠的,不保证订阅者一定能收到消息,也不进行消息的存储,所以一般的异步消息队列还是交给专业的消息队列。
7.Redis支持事务吗
Redis提供了简单的事务,但是它对事务ACID的支持并不完备。
multi命令表示事务的开始,exec命令表示事务结束。Redis事务的原理,是所有的指令在 exec 之前不执行,而是缓存在
服务器的一个事务队列中,服务器一旦收到 exec 指令,才开执行整个事务队列,执行完毕后一次性返回所有指令的运
行结果
Redis事务为什么不支持回滚
Redis的事务不支持回滚
如果执行的命令有语法错误,Redis 会执行失败,这些问题可以从程序层面捕获并解决。但是如果出现其他问题,则
依然会继续执行余下的命令。
这样做的原因是因为回滚需要增加很多工作,而不支持回滚则可以保持简单、快速的特性。
8.Redis实现分布式了解吗
Redis是分布式锁本质上要实现的目标就是在 Redis 里面占一个“茅坑”,当别的进程也要来占时,发现已经有人蹲
在那里了,就只好放弃或者稍后再试。
-
V1:setnx命令
占坑一般使用的是setnx(set if not exists)指令,只允许被一个客户端占,用完了在调用对del指令释放。
但是有个问题如果逻辑执行到中间出现了异常,可能会导致del指令没有被调用,陷入了死锁。 -
V2锁超时释放
所以在拿到锁之后,再给锁加上一个过期时间,比如5秒,这样即使服务中间出现异常也可以保证5秒之后锁会自动释放。 -
V3:set指令
这个问题在Redis 2.8版本中得到了解决,这个版本加入了set 指令的扩展参数,使得 setnx和expire指令可以一起执
行
9.假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如何将它们全部找出来
使用 keys 指令可以扫出指定模式的 key 列表。但是要注意 keys 指令会导致线程阻塞一段时间,线上服务会停
顿,直到指令执行完毕,服务才能恢复。这个时候可以使用 scan 指令, scan 指令可以无阻塞的提取出指定模式
的 key 列表,但是会有一定的重复概率,在客户端做一次去重就可以了,但是整体所花费的时间会比直接用指
keys 令长。