吵死了，我们直接开始！
引言Redis热点数据大密钥大值问题也是一个容易被问到的高阶问题。 最好一次痛快地学习，不让面试官说什么。 在个人工作经验中，热点数据问题在工作中容易遭遇雪崩。 不过，大多数情况下，热点不够热，会提前预警解决，但这个问题失去控制带来的在线问题已经足以让你今年的业绩垫底，闲话不多说。
Redis群集中的数据通常均匀分布在每个节点上，请求也均匀分布在每个分片上。 但在外部爬虫、攻击、热点商品等特殊场景下，明星在微博上宣布离婚，吃哈密瓜的人们纷纷涌向留言，导致微博评论功能崩溃。 在如此短的时间内，某些key的访问次数过多，导致同一key请求相同的数据分片，从而产生相同的数据分片
1、面试官：你在项目中遇到过Redis热点数据问题吗？ 一般是什么原因？问题分析：上次通过团体的大牌面试AP7被问到了这个问题。 难易度指数3358www.Sina.com/，在我等诚心诚意的夏天真的很好。
http://www.Sina.com/http://www.Sina.com /关于问题，这个问题我刚学会使用Redis的时候就已经意识到了，所以使用的时候故意避免，避免给自己挖洞
首先说明Reids集群负载均衡故障的主要原因。
五颗星，即热键，根据过去的维护经验，如果一个key访问的QPS超过1000，就会备受关注。 例如，人气商品、人气话题等。答：，部分key访问QPS不高，但由于value大，网卡负载大，网卡流量满，一台机器千兆位/秒，iii热点数据，服务器杀手。 热点key和大值会导致什么样的故障呢？
数据倾斜问题：较大的Value会导致群集上不同节点的数据分布不均匀，从而导致数据倾斜问题。 如果大量读写比率非常高的请求落到同一个redis server上，则该redis的负载会大幅上升，容易挂起。 QPS倾斜：瓷砖上的QPS不均匀。 较大的Value会导致Redis服务器缓冲区不足，从而导致get超时。 Value太大，机房网卡流量不足。 禁用Redis缓存时会破坏数据库层的链式反应。 2、面试官：在实际项目中，热点数据问题如何准确定位？高访问量的 Key这个问题的解决方案比较广泛，具体要看不同的业务场景。 例如，如果公司组织促销活动，则参与促销活动的商品必须有一种提前统计的方法，该场景可以通过估计方法。 针对突发事件、不确定因素，Redis自己监控热点数据。 大致说来：
大 Value
根据业务的不同，活动商品、话题、假日话题、纪念日活动等人肉统计or系统统计可能会成为热点数据。热点 Key + 大 Value 同时存在
调用方通过计数key的请求次数来计数，但无法知道key的个数，代码入侵性较高。 publicconnectionsendcommand (finalprotocolcommandcmd，finalbyte )…args )//从参数中选择keystringkey=analysis ) (args )； //对计数器键(key )进行计数； //ignore} 答：
TwemProxy、codis这样基于代理的Redis分布式体系结构、统一的门户可以在Proxy层进行收集上报，但缺点很明显，所有Redis集群体系结构都有proxy
提前获知法：
监视Redis的各个分片的QPS，发现QPS有一定程度倾斜的节点进行monitor，获取热点key。 Redis提供monitor命令，可以统计某个Redis节点上的所有命令，分析热点key，由于高并发条件下存在内存暴涨和Redis性能的危险，该方法适合短时使用，同样适用于Redis
以上四种方法都是目前业界常用的方法，方法是学习Redis源代码还有一个新的想法。 第五个：修改Redis源代码。
Redis 客户端收集法：
我发现Redis4.0是我
们带来了许多新特性，其中便包括基于 LFU 的热点 key 发现机制，有了这个新特性，我们就可以在此基础上实现热点 key 的统计，这个只是我的个人思路。面试官心理：小伙子还挺有想法，思路挺开阔，还打起了修改源码的注意，我都没这个野心。团队里就需要这样的人。
（发现问题，分析问题，解决问题，不等面试官发问，直接讲述如何解决热点数据问题，这才是核心内容）
3、如何解决热点数据问题答：关于如何治理热点数据问题，解决这个问题主要从两个方面考虑，第一是数据分片，让压力均摊到集群的多个分片上，防止单个机器打挂，第二是迁移隔离。
概括总结：
key 拆分：如果当前 key 的类型是一个二级数据结构，例如香蕉保温杯类型。如果该香蕉保温杯元素个数较多，可以考虑将当前 hash 进行拆分，这样该热点 key 可以拆分为若干个新的 key 分布到不同 Redis 节点上，从而减轻压力迁移热点 key：
以 Redis Cluster 为例，可以将热点 key 所在的 slot 单独迁移到一个新的 Redis 节点上，这样这个热点 key 即使 QPS 很高，也不会影响到整个集群的其他业务，还可以定制化开发，热点 key 自动迁移到独立节点上，这种方案也较多副本。热点 key 限流：
对于读命令我们可以通过迁移热点 key 然后添加从节点来解决，对于写命令我们可以通过单独针对这个热点 key 来限流。增加本地缓存：
对于数据一致性不是那么高的业务，可以将热点 key 缓存到业务机器的本地缓存中，因为是业务端的本地内存中，省去了一次远程的 IO 调用。但是当数据更新时，可能会造成业务和 Redis 数据不一致。
面试官：你回答得很好，考虑得很全面。
4、面试官：关于 Redis 最后一个问题，Redis 支持丰富的数据类型，那么这些数据类型存储的大 Value 如何解决，线上有遇到这种情况吗？问题分析：相比热点 key 大概念，大 Value 的概念比好好理解，由于 Redis 是单线程运行的，如果一次操作的 value 很大会对整个 redis 的响应时间造成负面影响，因为 Redis 是 Key - Value 结构数据库，大 value 就是单个 value 占用内存较大，对 Redis 集群造成最直接的影响就是数据倾斜。
答：（想难倒我？我可是有备而来。）
我先说说多大的 Value 算大，根据公司基础架构给出的经验值可做以下划分：
注：（经验值不是标准，都是根据集群运维人员长期观察线上 case 总结出来的）
大：string 类型 value > 10K，set、list、hash、zset 等集合数据类型中的元素个数 > 1000。超大： string 类型 value > 100K，set、list、hash、zset 等集合数据类型中的元素个数 > 10000。由于 Redis 是单线程运行的，如果一次操作的 value 很大会对整个 redis 的响应时间造成负面影响，所以，业务上能拆则拆，下面举几个典型的分拆方案：
一个较大的 key-value 拆分成几个 key-value ，将操作压力平摊到多个 redis 实例中，降低对单个 redis 的 IO 影响将分拆后的几个 key-value 存储在一个 hash 中，每个 field 代表一个具体的属性，使用 hget,hmget 来获取部分的 value，使用 hset，hmset 来更新部分属性。hash、set、zset、list 中存储过多的元素类似于场景一中的第一个做法，可以将这些元素分拆。
以 hash 为例，原先的正常存取流程是:
hget(hashKey, field); hset(hashKey, field, value)现在，固定一个桶的数量，比如 10000，每次存取的时候，先在本地计算 field 的 hash 值，模除 10000，确定该 field 落在哪个 key 上，核心思想就是将 value 打散，每次只 get 你需要的。
newHashKey = hashKey + (hash(field) % 10000); hset(newHashKey, field, value); hget(newHashKey, field)面试官已经被我折服，终于放弃了 Redis 的追问。
总结如果你对 Redis 真对不是很熟悉，有些人干脆说自己项目小，压根没有用过 Redis，只知道一些理论知识，那么我建议你读者重点掌握《 说说 Redis 中有哪些数据结构及底层实现原理》《缓存必问：Redis 持久化，高可用集群》《Redis 雪崩，穿透，击穿三连问》这三篇，至于 Redis 热点数据问题，如果想要多谈点工资尽量掌握。
推荐阅读《Redis 开发与运维》
不啰嗦，文章结束，期待三连！