排查与处置指南-Redis大Key危害 (排查与处置指的是什么)
这是一位同窗往年秋招参与得物一面遇到的疑问,完整面经如下:
这个疑问在面试中还是比拟容易遇到的,尤其是在调查性能优化相关常识点的时刻。
通常状况下,问了bigkey(大Key)还会继续问hotkey(热Key)。即使不预备面试也倡导看看,实践开发中也能够用到。
什么是bigkey?
便捷来说,假设一个key对应的value所占用的内存比拟大,那这个key就可以看作是bigkey。详细多大才算大呢?有一个不是特意准确的参考规范:
bigkey判定规范
bigkey是怎样发生的?有什么危害?
bigkey通常是由于上方这些要素发生的:
bigkey除了会消耗更多的内存空间和带宽,还会对性能形成比拟大的影响。
在 Redis经常出现阻塞要素总结[1] 这篇文章中咱们提到:大key还会形成阻塞疑问。详细来说,重要体如今上方三个方面:
大key形成的阻塞疑问还会进一步影响到主从同步和集群扩容。
综上,大key带来的潜在疑问是十分多的,咱们应该尽量防止Redis中存在bigkey。
如何发现bigkey?
1、经常使用Redis自带的--bigkeys参数来查找。
#redis-cli-p6379--bigkeys#Scanningtheentirekeyspacetofindbiggestkeysaswellas#averagesizesperkeytype.Youcanuse-i0.1tosleep0.1sec#per100SCANcommands(notusuallyneeded).[00.00%]Biggeststringfoundsofar'"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20"'with4437bytes[00.00%]Biggestlistfoundsofar'"my-list"'with17items--------summary-------Sampled5keysinthekeyspace!Totalkeylengthinbytesis264(avglen52.80)Biggestlistfound'"my-list"'has17itemsBiggeststringfound'"ballcat:oauth:refresh_auth:f6cdb384-9a9d-4f2f-af01-dc3f28057c20"'has4437bytes1listswith17items(20.00%ofkeys,avgsize17.00)0hashswith0fields(00.00%ofkeys,avgsize0.00)4stringswith4831bytes(80.00%ofkeys,avgsize1207.75)0streamswith0entries(00.00%ofkeys,avgsize0.00)0setswith0members(00.00%ofkeys,avgsize0.00)0zsetswith0members(00.00%ofkeys,avgsize0.00
从这个命令的运转结果,咱们可以看出:这个命令会扫描(Scan)Redis中的一切key,会对Redis的性能有一点影响。并且,这种形式只能找出每种数据结构top1bigkey(占用内存最大的String数据类型,蕴含元素最多的复合数据类型)。但是,一个key的元素多并不代表占用内存也多,须要咱们依据详细的业务状况来进一步判别。
在线上口头该命令时,为了降落对Redis的影响,须要指定-i参数管理扫描的频率。redis-cli-p6379--bigkeys-i3示意扫描环节中每次扫描后劳动的时时期隔为3秒。
2、经常使用Redis自带的SCAN命令
SCAN命令可以依照必定的形式和数量前往婚配的key。失掉了key之后,可以应用STRLEN、HLEN、LLEN等命令前往其长度或成员数量。
数据结构命令复杂度结果(对应key)StringSTRLENO(1)字符串值的长度HashHLENO(1)哈希表中字段的数量ListLLENO(1)列表元素数量SetSCARDO(1)汇合元素数量SortedSetZCARDO(1)有序汇合的元素数量
关于汇合类型还可以经常使用MEMORYUSAGE命令(Redis4.0+),这个命令会前往键值对占用的内存空间。
3、借助开源工具剖析RDB文件。
经过火析RDB文件来找出bigkey。这种打算的前提是你的Redis驳回的是RDB耐久化。
网上有现成的代码/工具可以间接拿来经常使用:
4、借助私有云的Redis剖析服务。
假设你用的是私有云的Redis服务的话,可以看看其能否提供了key剖析配置(普通都提供了)。
这里以阿里云Redis为例说明,它支持bigkey实时剖析、发现,文档地址:。
阿里云Key剖析
如何处置bigkey?
bigkey的经常出现处置以及优化方法如下(这些方法可以配合起来经常使用):
Redis数据的过期与淘汰
懒惰处理 Redis在get操作时遇到过期的key会进行删除操作。
集中处理 Redis会将设置了过期时间的key放到一个独立的字典里,默认每秒10次过期扫描。扫描方式:
为防止扫描时间过长,扫描时间限制为25ms,开发时应尽量避免大量key同时过期。 从库不会进行过期扫描,主库删除时,会在AOF文件里增加一条del指令,同步到所有从库,从库通过此指令来删除。由于指令的同步存在异步,所以会出现主从数据不一致的情况。
当Redis内存超出物理内存限制时,内存数据会开始和磁盘产生频繁的交换,使得性能急剧下降。为了限制内存的使用,Redis提供参数 maxmemory 来限制最大内存,当内存超出后,会有以下策略( maxmemory-policy )来淘汰key以腾出空间:
由于LRU算法需要消耗大量的额外内存,redis采用一种近似的LRU算法。它给每个 key 增加了一个额外的小字段(24bit),也就是最后一次被访问的时间戳。每次执行写操作时,如果发现内存超出 maxmemory ,就随机采样5个(参数 maxmemory_samples 配置)key,然后淘汰最旧的。如果淘汰之后还是超出,那就继续随机淘汰,直到不超出为止。如果 maxmemory-policy 是volatile-xxx,就从设置过期时间的key里采样,否则就从所有key里采样。 Redis3.0里增加了一个淘汰池,就是一个大小为 maxmemory_samples 的数组。每次淘汰时会将随机出来的key和数组里的key融合,淘汰掉最旧的一个,然后将剩下的较旧的key放到淘汰池里给下个循环用。
redis的删除del在删除一个大对象的时候有可能造成卡顿。为了解决这个问题Redis4.0引入了unlink指令,将这个key的对象引用从Redis内存数据里删除,将删除操作封装成一个任务丢到一个异步队列里。然后有个异步线程会从这个队列里取出任务并执行。 清空操作 flushdb 和 flushall ,在Redis4.0后,在指令后面增加 async ,就也可以像上面一样异步执行。
《Redis深度历险:核心原理和应用实践》
![排查与处置指的是什么](https://tyye.cn/zb_users/theme/tpure/style/images/lazyload.png)
redis 线上问题排查思路总结
日常我们使用redis 缓存时,经常会遇到各种各样的问题,其中redis 偶发性连接超时,是经常遇到的一个问题,下面介绍一下我们之前是如何处理的这个问题。 1、redis 服务监控通过监控工具,首先排查一下redis 服务端是否是超时,可以从服务器cpu ,内存使用情况,qps等判断server 端是否超时。 如果server 侧没有问题,就需要排查客户端。 如果server 侧存在问题,就需要排查服务器哪里出了问题,单机性能使用率太高是否可以升级成哨兵模式或者高可用集群模式。 2、redis 客户端排查 首先查看业务日志,查看一下redis 使用情况是否是存在连接数占满或者创建失败的异常,如果存在,在客户端服务器,使用top 指令,查看使用率高的线程,然后jstack pid,查看当前线程的使用情况。 如果出现大量的线程状态显示time_waiting 或者waiting 。 则表示连接数一直没有释放,可以通过调整客户端配置的redis 连接池参数,比如配置max连接数和min连接数,time_out超时时间等等。 3、redis 热key排查 排查redis 热key,腾讯云或者阿里云服务器可以使用监控热key的工具。 redis 4.0 以后,提供了—hotkey 指令,可以通过热key 指令来监控热key。 如果发现异常热key,比如spring-redis-session的热key,存储的是一段时间戳,并且访问率非常高,qps 几十万/s。 这时候需要考虑热key是否对业务产生影响,可以通过配置-type=none,关闭存储redis.这时候热key访问量下降,业务key 可以正常访问。 通过以上方式,排查生产中遇到的redis 连接问题,可以排查线上遇到的问题,基本都可以解决掉。
免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。