✅什么是热Key问题，如何解决热key问题

典型回答

当我们使用Redis作为存储时，如果发生一些特殊情况，比如明星官宣的突发事件，世界杯等重大活动，双十一的活动秒杀等等，就会出现特别大的流量，并且会导致某些热词、商品等被频繁的查询和访问。

如果在同一个时间点上，Redis中的同一个key被大量访问，就会导致流量过于集中，使得很多物理资源无法支撑，如网络带宽、物理存储空间、数据库连接等。

这也是为什么某某明星官宣之后，微博上面就会出现宕机的情况。有时候这种宕机发生后，其他功能都是可以使用的，只是和这个热点有关的内容会无法访问，这其实就和热点数据有关系了。

对于热key的处理，主要在于事前预测和事中解决。

对于事前预测就是根据一些根据经验，提前的识别出可能成为热key的Key，比如大促秒杀活动等。

在事中解决方面，主要可以考虑，热点key拆分、多级缓存、热key备份、限流等方案来解决。

到底"多热算热"，这个其实需要根据实际的业务情况以及你自己的缓存服务器的整体存储情况而定的。

JD有一个框架叫做hotkey，他就是专门做热key检测的，他的热key定义是在单位时间内访问超过设定的阈值频次就是热key，这个阈值需要业务自己设定，并不断的调整和优化。

热key的定义，通常以其接收到的Key被请求频率来判定，例如：

想要解决热key的问题，首先要想办法识别出哪些key是热key。主要由以下几个方案：

这种方法在大多数情况下还是比较奏效的。比较常见的就是电商系统中，会在做秒杀、抢购等业务开始前就能预测出热key。

但是，这种方式的局限性也很大，就是有些热key是完全没办法预测的，比如明星什么时候要官宣这种事情就无法预测。

还有一种热点数据的发现机制，那就是实时的做收集，比如在客户端、服务端或者在代理层，都可以对实时数据进行采集，然后进行统计汇总。

达到一定的数量之后，就会被识别为热key。

具体的收集方式也有很多种，可以在客户端进行收集、也可以在统一代理层进行收集、还可以通过redis的自带命令进行收集。redis 4.0.3中提供了redis-cli的热点key发现功能，执行redis-cli时加上–hotkeys选项即可。

解决热key问题最主要的方式就是加缓存。通过缓存的方式尽量减少系统交互，使得用户请求可以提前返回。

这样即能提升用户体验，也能减少系统压力。

缓存的方式有很多，有些数据可以缓存在客户的客户端浏览器中，有些数据可以缓存在距离用户就近的CDN中，有些数据可以通过Redis等这类缓存框架进行缓存，还有些数据可以通过服务器本地缓存进行。

这种使用多个缓存的情况，就组成了二级缓存、三级缓存等多级缓存了。总之，通过缓存的方式尽量减少用户的访问链路的长度。

有了缓存之后，还会带来一个问题，那就是热点数据如果都被缓存在同一个缓存服务器上，那么这个服务器也可能被打挂。

所以，很多人在加了缓存之后，还可能同时部署多个缓存服务器，如Redis同时部署多个服务器集群。并且实时的将热点数据同步分发到多个缓存服务器集群中，一旦有的集群扛不住了，立刻做切换。

将一个热key拆分成多个key，在每一个Key后面加一个后缀名，然后把这些key分散到多个实例中。

这样在客户端请求的时候，可以根据一定的规则计算得出一个固定的Key，这样多次请求就会被分散到不同的节点上了。

比如 <淄博烧烤> 是个热点key，

把他拆分成淄博烧烤0001、淄博烧烤0002、淄博烧烤0003、淄博烧烤0004，然后把它们分别存储在cluster中的不同节点上，这样用户在查询<淄博烧烤>的时候，先根据用户ID算出一个下标，然后就访问其中一个节点就行了

有人问了，这不是意味着一个用户只能拿到部分数据了吗？确实是，但是有时候我们并不一定就需要全部的数据。

比如说，同样的两个用户在刷抖音，都想看<淄博烧烤>这个热点相关的视频，但是我们并不一定要给所有用户都推送同样的内容，完全可以把这个词条下面的无数个视频分散存储在不同的节点上，然后给不同的用户推送在不同的节点上的数据就行了。

然后在这个热点key没那么热了之后，再把数据做一下汇总，挑选出一下好的视频在重新推送给没推送到的用户就行了

原文: https://www.yuque.com/hollis666/xkm7k3/lysd3t