一、热点key问题
1、商品秒杀、热点新闻、热点评论等读多写少的场景，可能会造成一个较大的请求Redis量，这种情况下就会造成热点Key问题。
2、请求分片集中，超过单台Redis服务器的性能极限。
手动分片或者custer分片切分，刚好一致性hash落入同一台redis服务器，数据倾斜，如果瞬间访问量过大，超过机器瓶颈。缓存击穿，压垮redis服务器，导致大量请求直接发往后端服务，进一步导致后端服务雪崩。
二、识别热Key
1、凭借个人经验，结合业务场景，判断哪些是热Key。
比如华为新机发售，那么我们可以判断华为手机这个sku就是热Key。
2、架构或者redis封装，代码记录上报ELK。
架构层负责上报，定时把收集到的数据上报到统一的服务进行聚合计算，这样我们就可以找到那些热点Key。
3、服务代理层上报。
如果是在redis前面有一个代理层，那么我们可以在代理层进行收集上报，也是可以找到热点Key。
4、使用redis自带的命令。
例如monitor、redis-cli加上--hotkeys选项等，不过这种方式执行起来很慢，可能会降低redis的处理请求的性能，慎用。
monitor命令：可以实时抓取出redis服务器接收到的命令，然后写代码统计出热Key，也有现成的分析工具可以使用。
5、redis节点抓包分析。
抓包redis的端口和协议，然后写代码进行上报统计。
三、如何解决热Key问题？
1、Redis集群扩容：增加分片副本，分摊客户端发过来的读请求；数据倾斜则需要重新设计key。
2、使用二级缓存，即JVM本地缓存，减少Redis的读请求。
例如使用Caffeine+redis 实现二级缓存，先从本地缓存中取，取不到再去redis中去取。当然也可以使用其它框架，如ehcache、甚至一个HashMap都可以。
四、大key问题
标签：key,Redis,redis,Key,分片,上报,热点 From： https://www.cnblogs.com/rcsy/p/18181080