面试官：你知道Redis的热key问题吗？给出几个解决方案，详细点？

目录

一、简单概括

二、多热算热？

三、 解决方案

3.1、根据经验，提前预测

3.2、实时收集

3.3、多级缓存

3.4、热key备份

3.5、热key拆分 

---

一、简单概括

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

• 如果在同一时间点上，Redis中的同一个key被大量访问，就会导致流量过于集中，使得很多物理资源无法支撑，如网络带宽、物理存储空间、数据库连接等。
• 这也是为什么某某明星官宣之后，微博上面就会出现宕机的情况。有时候这种宕机发生后，其他功能都是可以使用的，只是和这个热点有关的内容会无法访问，这其实就和热点数据有关系了。
• 对于热key的处理，主要在于事前预测和事中解决。对于事前预测就是根据一些经验，提前识别出可能成为热key的key，比如秒杀；事中解决方面，主要可以考虑：热点key的拆分、多级缓存、热key备份、限流等方案来解决。

二、多热算热？

• 到底“多热算热”呢，这个其实现需要根据实际的业务情况以及你自己的缓存服务器的整体存储情况而定。
• JD有一个框架叫做hotkey，他就是专门做热key检测的，他的热key定义是在单位时间内访问超过设定的阈值频次就是热key，这个阈值需要业务自己设定，并不断的调整和优化。
•  一般来说，如果一个key在1秒内被访问次数达到上千次，就可以认为是热key了。

三、 解决方案

3.1、根据经验，提前预测

• 这种方法在大多数情况下还是比较有效的。比较常见的就是电商系统中，会在秒杀、抢购等业务开始前就能预测出热key。
• 但是，这种方法局限性也很大，就是有些热key是完全没办法预测的，比如明星什么时候要官宣这种事情就无法预测。

3.2、实时收集

• 还有一种热点数据的发现机制，那就是实时收集，比如客户端、服务端或者在代理层，都可以对实时数据进行采集，然后进行统计汇总，达到一定数量之后，就会被识别为热key。
• 具体的收集方式也有很多种，可以在客户端收集、也可以统一在代理层收集、还可以通过redis的自带命令进行收集：redis4.0.3中提供了redis-cli的热点key发现功能，执行redis-cli时加上-hotkeys选项即可。

3.3、 多级缓存

• 解决热key问题最主要的方式就是加缓存。通过缓存的方式尽量减少系统交互，使得用户请求可以提前返回，这样既能提升用户体验，也能减少系统压力。
• 缓存的方式由很多，有些数据可以缓存在客户端浏览器中，有些数据可以缓存在距离用户就近的CDN中，有些数据可以通过Redis等这类缓存框架进行缓存，还有一些可以通过服务器本地缓存进行。
• 这种使用多个缓存的情况，就组成了二级缓存、三级缓存等多级缓存了。总之，通过缓存的方式尽量减少用户的访问链路的长度。

3.4、热key备份

• 有了缓存之后，还会带来一个问题，那就是热点数据如果都被缓存在同一个缓存服务器上，那么这个服务器也可能被打挂。
• 所以，很多人在加了缓存之后，还可能同时部署多个缓存服务器，如Redis同时部署多个服务器集群。并且实时的将热点数据同步分发到多个缓存服务器集群中，一旦有的集群扛不住了，立即做切换。
• 单纯的对于Redis热key缓存来说，Redis是有分片机制的，同一个热key可能会都保存在同一个分片中，所以还可以在多个分片中都把热key同步一份，使得查询可以同时从多个分片进行，减少某一个分片的压力。
• 因为有分片，还有一种情况，就是可能多个热key都会分到同一个分片中，为了减少这种情况的发生，可以增加更多的分片来分担流量。

3.5、热key拆分 

• 热key拆分成多个key，在每一个key后面加一个后缀名，然后把这些key分散到多个阶段中。
• 这样在客户端请求的时候，可以根据一定的规则计算得出一个固定的key，这样多次请求就会被分散到不同的节点上了。