这是一位同窗往年秋招参与得物一面遇到的疑问，完整面经如下：

这个疑问在面试中还是比拟容易遇到的，尤其是在调查性能优化相关常识点的时刻。

通常状况下，问了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深度历险：核心原理和应用实践》

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 连接问题，可以排查线上遇到的问题，基本都可以解决掉。