本文 的 原文 地址
原始的内容，请参考 本文 的 原文 地址
本文 的 原文 地址
尼恩说在前面：
在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、shein 希音、shopee、百度、网易的面试资格，遇到很多很重要的面试题：
MySQL的慢查询、如何监控、如何排查？
你知道如何排查慢sql嘛?
你知道如何对mysql进行优化嘛?
mysql慢查询如何定位分析？哪些情况会导致慢查询？
没开sql慢查询日志，怎么发现慢 sql？
前几天 小伙伴面试 哈罗，遇到了这个问题。但是由于 没有回答好，导致面试挂了。
小伙伴面试完了之后，来求助尼恩。
那么，遇到 这个问题，该如何才能回答得很漂亮，才能 让面试官刮目相看、口水直流。
所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现”offer直提”。
当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典》V145版本PDF集群，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。
最新《尼恩 架构笔记》《尼恩高并发三部曲》《尼恩Java面试宝典》的PDF，请关注本公众号【技术自由圈】获取，后台回复：领电子书
一、什么是Big Key?
通俗易懂的讲，Big Key就是某个key对应的value很大，占用的redis空间很大，本质上是大value问题。
key往往是程序可以自行设置的，value往往不受程序控制，因此可能导致value很大。
redis中这些Big Key对应的value值很大，在序列化/反序列化过程中花费的时间很大，因此当我们操作Big Key时，通常比较耗时，这就可能导致redis发生阻塞，从而降低redis性能。
BigKey指以Key的大小和Key中成员的数量来综合判定。
下面，尼恩 用几个实际的例子对大Key的特征进行描述：
- Key本身的数据量过大：一个String类型的Key，它的值为5MB
- Key中的成员数过多：一个ZSET类型的Key，它的成员数量为10000个
- Key中成员的数据量过大：一个Hash类型的Key，它的成员数量虽然只有1000个但这些成员的Value值总大小为100MB
尼恩提示：在实际业务中，大Key的判定仍然需要根据Redis的实际使用场景、业务场景来进行综合判断。通常都会以数据大小与成员数量来判定。
二、Big Key产生的场景？
1、redis数据结构使用不恰当
将Redis用在并不适合其能力的场景，造成Key的value过大，如使用String类型的Key存放大体积二进制文件型数据。
2、未及时清理垃圾数据
没有对无效数据进行定期清理，造成如HASH类型Key中的成员持续不断的增加。即一直往value塞数据，却没有删除机制，value只会越来越大。
3、对业务预估不准确
业务上线前规划设计考虑不足没有对Key中的成员进行合理的拆分，造成个别Key中的成员数量过多。
4、明星、网红的粉丝列表、某条热点新闻的评论列表
假设我们使用List数据结构保存某个明星/网红的粉丝，或者保存热点新闻的评论列表，因为粉丝数量巨大，热点新闻因为点击率、评论数会很多，这样List集合中存放的元素就会很多，可能导致value过大，进而产生Big Key问题。
三、Big Key的危害？
危害1：阻塞请求
Big Key对应的value较大，我们对其进行读写的时候，需要耗费较长的时间，这样就可能阻塞后续的请求处理。
Redis的核心线程是单线程，单线程中请求任务的处理是串行的，前面的任务完不成，后面的任务就处理不了。
危害2：内存增大
读取Big Key耗费的内存比正常Key会有所增大，如果不断变大，可能会引发OOM（内存溢出），
内存增大 达到redis的最大内存maxmemory设置值， 会 引发写阻塞， 或导致 重要Key被逐出。
危害3：阻塞网络
单value较大时， 读取 会占用服务器网卡较多带宽，
自身变慢的同时， 可能会影响该服务器上的其他Redis实例或者应用。
危害4：影响主从同步、主从切换
删除一个大Key， 造成主库较长时间的阻塞并引发同步中断或主从切换。
四、生产场景的bigkey 扫描
结合scan + 定时任务的方式， 在 吞吐量的低峰期，进行扫描
发现了bigkey， 可以及时的进行 运维 告警， 发送 邮件通知或者 钉钉企业信息
参见下面的文章：
滴滴一面：BigKey问题很致命，如何排查和处理？
五、在线优化
...................由于平台篇幅限制， 剩下的内容(5000字+)，请参参见原文地址
原始的内容，请参考 本文 的 原文 地址
本文 的 原文 地址